18 Mar
2016
18 Mar
'16
12:48 a.m.
It's a bit off-topic, but what were non-Unix filesystems like around 1969-1970?
The PDP-7 filesystem has i-nodes (file metadata) and filenames separate
from the i-nodes. This allows hard links and thus a non-tree structured
filesystem.
This has always struck me to be one of the most important features of
the Unix filesystem: names separated from the rest of the file metadata,
and arbitrary hard links so that there is no preferred filename.
Were these features in other contemporaneous filesystems?
As a side note, the PDP-7 kernel knows about the top-level directory ("dd")
but it is agnostic to the concept of "." and "..". What that means is
that you can build a filesystem with "." and ".." links and the
kernel
will deal with them as per all other links. But you can also build a
filesystem without "." or ".." and the kernel doesn't care.
There's not enough evidence (source code, papers, anecdotes) to confirm
or deny the presence of "." in the PDP-7 code that Norman scanned for us.
".." does seem to exist as it is mentioned in one source file, ds.s.
It's an intruiging mystery.
Cheers, Warren
18 Mar
18 Mar
2:49 a.m.
On Friday, 18 March 2016 at 10:48:32 +1000, Warren Toomey wrote:
It's a bit off-topic, but what were non-Unix
filesystems like around
1969-1970?
A year or two earlier, maybe: the Master File Directory of UNIVAC
EXEC-8. It's an amazingly complex and quite versatile system that
makes the Unix file system look simple. There's some documentation at
http://bitsavers.trailing-edge.com/pdf/univac/1100, though right now I
can't find the references I'm looking for.
The PDP-7 filesystem has i-nodes (file metadata) and
filenames
separate from the i-nodes. This allows hard links and thus a
non-tree structured filesystem.
This has always struck me to be one of the most important features
of the Unix filesystem: names separated from the rest of the file
metadata,
Agreed. In fact, I'd go as far as to say that it's one of the most
important features of Unix. And I'm pretty sure that the MFD didn't
have anything as straightforward and powerful. But I'll research and
see if I can comeup with something interesting.
Greg
--
Sent from my desktop computer.
Finger grog(a)FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
3:59 a.m.
Warren Toomey scripsit:
It's a bit off-topic, but what were non-Unix
filesystems like around
1969-1970? The PDP-7 filesystem has i-nodes (file metadata) and
filenames separate from the i-nodes. This allows hard links and thus
a non-tree structured filesystem.
Not only that, but a non-tree-structured directory system: the directories
themselves were a general directed graph, and it was possible to have any
number of arbitrary hard links to a directory. This was simplified in
later Unices to the tree-structured directory system we have today, where
the only hard links to a directory are the named link from the parent,
the "." link from self, and the ".." links from the child
directories.
There was also no concept of pathnames in PDP-7 Unix, neither relative
nor absolute. The link syscall was link("foo", "bar",
"baz"), meaning
to cause entry "baz" in directory "bar" in the working directory to
be the same file or directory as entry "foo" in the working directory.
So for example, each home directory had a hard link to the main binaries
directory, conventionally named "bin", and the shell could not execute
commands out of a directory that did not contain a "bin" link. With no
reliable ".." entry, there was also no way to recover from a chdir, and
traversal had to be done as digraph traversal rather than tree traversal.
In particular, incautious use of unlink could cause the directory graph
to become partitioned, requiring low-level disk surgery to recover.
An interesting property of the ODS-1 (RSX) file system was that the
root directory contained the i-node table as a file named INDEXF.SYS.
This allowed ordinary programs to inspect the i-node table without messing
about with raw disks. It also contained a self-entry named 000000.DIR,
but other directories did not contain self-links.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
The internet is a web of tiny tyrannies giving an illusion of anarchy.
--David Rush
5:11 a.m.
On Thu, Mar 17, 2016 at 11:59:36PM -0400, John Cowan wrote:
There was also no concept of pathnames in PDP-7 Unix,
neither relative
nor absolute. ...
directory, conventionally named "bin", and the shell could not execute
commands out of a directory that did not contain a "bin" link.
Are you sure it was called "bin"? The PDP-7 team are working on the
assumption that it was called "system" because init links the shell
from "system" into a user's home directory:
sys setuid " Set the user's user-id,
sys chdir; dd " change into the "dd" directory
sys chdir; dir " and then into the user's directory
...
sys link; system; sh; sh " Link sh in system dir to this dir
system:
...
<sy>;<st>;<em>; 040040
https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/init.s
There's no mention of the directory's name in the kernel, but i-node 3
has to contain init (we assume "system" again) and i-node 4 is the
directory that holds users' home directories ("dd").
Cheers, Warren
5:45 p.m.
Warren Toomey scripsit:
Are you sure it was called "bin"? The PDP-7
team are working on the
assumption that it was called "system" because init links the shell
from "system" into a user's home directory:
Probably an incorrect memory. Of course, in an edge-labeled general
graph, directories don't have names any more than files do in modern
Unix filesystems, so it isn't "what's its name?", it is
"what's its
name in some directory?"
I assume you know about
https://www.bell-labs.com/usr/dmr/www/hist.html , which is an essential
resource on Ancientest Unix. Note especially the absence of any way to
create directories while the system is running.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
Please leave your values at the front desk.
--sign in Paris hotel
Check your assumptions. In fact, check your assumptions at the door.
--Cordelia Vorkosigan
8:42 a.m.
On 2016-Mar-18 19:00:00 +1100, Dave Horsfall <dave(a)horsfall.org> wrote:
On Fri, 18 Mar 2016, Warren Toomey wrote:
That's being unfair to filesystems. You can't call what you got with
OS/360 a "filesystem". IMHO, a filesystem needs more than a way to
associate a name with a manually-allocated region of DASD.
--
Peter Jeremy
It's a bit off-topic, but what were non-Unix
filesystems like around
1969-1970?
With my IBM/360 experience, "horrible". 
1:04 p.m.
FYI: To be fair to the IBM systems of the time, TSS and MTS had a naming
scheme that used dots (.) as the path separators in their pathnames and
they too supported a directory/subdirectory idea. While ugly in my
opinion compared to UNIX, not really much worse than later schemes that DEC
would use for TOPS, RSX, VMS et al (I once got into a "discussion" with
Cutler about VMS's #$%%^ filenames but that's a different story).
The key point is that around this time the idea of "sub-directories" began
to become important. The file cabinet metaphor was beginning to come into
age as people recognized the systems using "soft files" had the same issues
that "paper files" and they needed some way to build up similar "filing
mechanisms" with cabinets, drawers, file folder etc....
That said, I agree that OS/360 was primitive but being batch oriented, I
think did not consider the "human factors" the way the time sharing system
required started to do.
Anyway back to Warren's questions -- the idea of a disk "catalog" for the
meta-data was not new to UNIX. Tannenbaum's books (starting with the
Minux book) describes the history and the idea reasonably well. What
UNIX did was create a user file type called a directory (eventually user
create-able) and was able to separated the human name for the bag of bit
(i.e. the data itself) from the catalog or system name for those same bits.
As AST puts it, UNIX has a two level file system, one for the OS which is
numerical in nature (the i-node) and then layered on top of it was
something humans liked better.
Again, by breaking the idea/metaphor of a files and file cabinets into two
pieces - higher level (human oriented) and lower level (system specific),
like the splitting the command system of the shell out of the OS
fork/exec/wait primitives, UNIX ended up with something more more flexible
and scalable.
Clem
On Fri, Mar 18, 2016 at 4:42 AM, Peter Jeremy <peter(a)rulingia.com> wrote:
On 2016-Mar-18 19:00:00 +1100, Dave Horsfall
<dave(a)horsfall.org> wrote:
On Fri, 18 Mar 2016, Warren Toomey wrote:
That's being unfair to filesystems. You can't call what you got with
OS/360 a "filesystem". IMHO, a filesystem needs more than a way to
associate a name with a manually-allocated region of DASD.
--
Peter Jeremy
It's a bit off-topic, but what were non-Unix
filesystems like around
1969-1970?
With my IBM/360 experience, "horrible". 
5:12 p.m.
It may seem strange to us today, but in the context of the day, one of the
most radical ideas in Unix was the concept of a file as an array of bytes,
with lines separated by newline characters. Most mainframes had file
systems that were more or less decks of cards on disk (at one point, the
Bell Labs computing centers estimated that 2/3 of the disc was taken up
with trailing blanks. Layered on top of this was a bit of cruft that
also made the file look like a magnetic tape holding punch card images.
So files had "blocking factors" (how many cards in a contiguous block of
disc).
In the GE (later Honeywell) time sharing system, to create a file, you
entered a subsystem which asked you nearly a dozen questions (name,
initial size, maximum size, device, permissions, etc.) and stored up your
answers and finally did a system call to create the file. The usual
result was that something was wrong in your answer to question 5 and you
had to do the whole dance over again from the top. If you managed to
create a file, the subsystem congratulated you by printing:
Successful!
In this world, typing
echo hello Joe >foo
in Unix, and thereby creating a file, seemed like a miracle -- typically a
first-timer's jaw would drop when I said we had created a file named foo
and showed them that it had contents. Their response was typically about
30 seconds of "But... but.... but... but..." followed by a blinding grin
when they "got it".
Steve
That's
being unfair to filesystems. You can't call what you got with
OS/360 a "filesystem". IMHO, a filesystem needs more than a way to
associate a name with a manually-allocated region of DASD.
--
Peter Jeremy
5:45 p.m.
On Fri, Mar 18, 2016, at 13:12, scj(a)yaccman.com wrote:
It may seem strange to us today, but in the context of
the day, one of
the most radical ideas in Unix was the concept of a file as an array of
bytes, with lines separated by newline characters. Most mainframes had file
systems that were more or less decks of cards on disk
Of course, I assume the answer to the question of why everyone didn't do
that is that there's a trade-off: We take for granted today that you
can't change a line in the middle of a text file without moving
everything after it, either by reading the whole thing into memory and
writing back the changed version, or creating a copy of the file with
the changes and replacing the original with it afterwards, but I assume
these "deck of cards" style files had provisions for editing one in the
middle. You also can't seek to a given line number in a file.
6:02 p.m.
On Fri, Mar 18, 2016, at 13:12, scj(a)yaccman.com
wrote:
At least in my experience, editing the "deck of cards" (and certainly,
editing anything on magnetic tape) was really painful -- there was no way
to move blocks of text around -- you started at the beginning of the file
and had to edit lines in order (one shot per line) until you got to the
end. You could add lines or delete them, but only when you came to them.
The editor copied the edited file into an output file, and then you had to
do another step to copy the new version back over the original one.
Shortly after we had a user-writable disc in the Murray Hill computation
center, I (working there as a summer intern) was delighted to copy the
2000 card file I had been lugging around onto disc, and dump the cards.
As it turns out, my boss also dumped his copy of the card deck.
The first time I tried to edit the deck on disc, I specified the output
file to be equal to the input file. The program did not check this, and I
ended by nuking about 20% of the card images! Luckily I had a listing...
I punched out the trash on the disc and spent an entire weekend
rearranging and repunching the cards to get back to where I had been...
It just goes to show that I should have taken my mother's advice -- before
you throw out a deck of cards, put a rubber band around it!
It may seem strange to us today, but in the
context of the day, one of
the most radical ideas in Unix was the concept of a file as an array of
bytes, with lines separated by newline characters. Most mainframes had
file
systems that were more or less decks of cards on disk
Of course, I assume the answer to the question of why everyone didn't do
that is that there's a trade-off: We take for granted today that you
can't change a line in the middle of a text file without moving
everything after it, either by reading the whole thing into memory and
writing back the changed version, or creating a copy of the file with
the changes and replacing the original with it afterwards, but I assume
these "deck of cards" style files had provisions for editing one in the
middle. You also can't seek to a given line number in a file.
21 Mar
21 Mar
2:11 p.m.
On Fri, 18 Mar 2016, scj(a)yaccman.com wrote:
At least in my experience, editing the "deck of
cards" (and certainly,
editing anything on magnetic tape) was really painful -- there was no
way to move blocks of text around -- you started at the beginning of the
file and had to edit lines in order (one shot per line) until you got to
the end. You could add lines or delete them, but only when you came to
them. The editor copied the edited file into an output file, and then
you had to do another step to copy the new version back over the
original one.
Memories of IEBUPDTE come to me... A very useful program, when it came to
doing things, ahem, not allowed by the computer centre, by us Comp Sci
kiddies...
Ah, the time I got SPITBOL to work beyond its use-by date, for example;
the thing was riddled with date checks (the first one was obvious, but the
rest not so much; its endearing habit was to jump to whatever was in R0 at
the time). I wrote something that searched for that particular date
string, and after inspecting the surrounding binary code I patched it...
The first time I tried to edit the deck on disc, I
specified the output
file to be equal to the input file. The program did not check this, and I
ended by nuking about 20% of the card images! Luckily I had a listing...
I punched out the trash on the disc and spent an entire weekend
rearranging and repunching the cards to get back to where I had been...
[...]
And who here hasn't done "cat file ... > file"?
It just goes to show that I should have taken my
mother's advice --
before you throw out a deck of cards, put a rubber band around it!
Walking down the corridors of Comp Sci, a student in front of me dropped
his entire deck of approx 2000 cards, all over the floor... I have no
idea whether he got them sorted, but I sure as hell used rubber bands
after that!
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
9:43 p.m.
On Tuesday, 22 March 2016 at 1:11:07 +1100, Dave Horsfall wrote:
Walking down the corridors of Comp Sci, a student in front of me
dropped his entire deck of approx 2000 cards, all over the floor...
I have no idea whether he got them sorted, but I sure as hell used
rubber bands after that!
But that's what the sequence numbers in columns 73 to 80 are for!
Greg
--
Sent from my desktop computer.
Finger grog(a)FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
10:57 p.m.
On Tuesday, 22 March 2016 at 1:11:07 +1100, Dave
Horsfall wrote:
Actually, a Magic Marker drawing a diagonal stripe down the top of the
cards worked almost as well, and didn't require repunching the deck with
every change...
Hmm. I recall walking into the computing center to see an amazing cascade
of cards arcing 20 feet across the room. The operator hadn't set up the
card reader correctly.... Panic ensued...
In another case, I had written a FORTRAN program that produced a page
header on the printer with a page number. The first time I tried to print
200 pages, when I hit 100 the printer decided that I wanted one line per
page! The printer was not a happy camper. Neither were the operators.
But the closest I came to being murdered was when I submitted a job before
lunch, and the sign said the turnaround time was an hour. When I got
back, the job was not done, and the wait was 2 hours. Each hour, the wait
grew by an hour. At about 4:30, four extremely angry operators and
managers came into my office with murder in their eyes and accused me of
trying to "be funny" (sic) with the computer. I had no idea what they
were talking about. It turns out that the operating system had been
upgraded, so that it automatically started pending jobs when it came up
after a crash. It also turned out that I had made a common FORTRAN
error--I had "called" a labeled common region instead of a similarly-named
function. And it turned out that the first data value was a -.25
floating-point value. And it also turned out that the computer's idea of
instruction decode was to pick up the first few bits of the word and use
it as an index into the microcode. And it also turned out that when -.25
was so "executed", it took the CPU into the power down sequence, and it
turned the machine off! And, thanks to the software upgrade, when they
rebooted, it turned itself off again. And again... I was happy to escape
with my skin...
Steve
Steve
Walking down the corridors of Comp Sci, a student in front of me
dropped his entire deck of approx 2000 cards, all over the floor...
I have no idea whether he got them sorted, but I sure as hell used
rubber bands after that!
But that's what the sequence numbers in columns 73 to 80 are for!
Greg 
22 Mar
22 Mar
12:27 a.m.
On Monday, 21 March 2016 at 15:57:24 -0700, scj(a)yaccman.com wrote:
But the closest I came to being murdered was ... it also turned out
that when -.25 was so "executed", it took the CPU into the power
down sequence, and it turned the machine off!
Not that I haven't done that sort of thing myself, but my favourite
one was a Tandem customer whose programmers had come from a different
system, and they knew that the correct way to terminate a program was
to jump to absolute location 0. And how about that, it worked!
One day we received a problem report that CPU 4 of their system would
reliably fail at 16:04 every day. We spent a long time puzzling over
it: there was kernel data corruption of a kind we had never seen
before. TL;DR: it seems that the jump to 0, in combination with a
kernel library bug, had interpreted the "instruction" at location 0 to
modify this particular location in kernel memory. More details at
http://www.lemis.com/grog/warstories/CPU-4-at-16-04.php
Greg
--
Sent from my desktop computer.
Finger grog(a)FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
23 Mar
23 Mar
10:46 p.m.
On Mon, 21 Mar 2016, scj(a)yaccman.com wrote:
Actually, a Magic Marker drawing a diagonal stripe
down the top of the
cards worked almost as well, and didn't require repunching the deck with
every change...
Yep, an old trick. Trouble is, whenever I rearranged the cards I had to
use another colour, and then had to remember which...
Hmm. I recall walking into the computing center to
see an amazing
cascade of cards arcing 20 feet across the room. The operator hadn't
set up the card reader correctly.... Panic ensued...
I've seen something like that; it involved a high-speed CDC reader/punch,
as I recall. Cards everywhere :-) Seems that the deck wasn't
straightened before inserting by the trainee operator. Pity the poor
user.
In another case, I had written a FORTRAN program that
produced a page
header on the printer with a page number. The first time I tried to
print 200 pages, when I hit 100 the printer decided that I wanted one
line per page! The printer was not a happy camper. Neither were the
operators.
Have you any idea how fast the IBM 1403 printer can slew blank pages?
Cough cough... It chewed through a box in an instant, and I got to
re-pack it afterwards. You also learned to not place your coffee cup on
it (I was doing the midnight shift at the time), because when it ran out
of paper then the door would open automatically...
I think it was because of an undefined format control character, and the
printer's control tape went hunting for it.
But the closest I came to being murdered was when I
submitted a job
before lunch, and the sign said the turnaround time was an hour. When I
got back, the job was not done, and the wait was 2 hours. Each hour,
the wait grew by an hour. At about 4:30, four extremely angry operators
and managers came into my office with murder in their eyes and accused
me of trying to "be funny" (sic) with the computer. I had no idea what
they were talking about. It turns out that the operating system had
been upgraded, so that it automatically started pending jobs when it
came up after a crash. It also turned out that I had made a common
FORTRAN error--I had "called" a labeled common region instead of a
similarly-named function. And it turned out that the first data value
was a -.25 floating-point value. And it also turned out that the
computer's idea of instruction decode was to pick up the first few bits
of the word and use it as an index into the microcode. And it also
turned out that when -.25 was so "executed", it took the CPU into the
power down sequence, and it turned the machine off! And, thanks to the
software upgrade, when they rebooted, it turned itself off again. And
again... I was happy to escape with my skin...
Closest I've ever been murdered was when I "accidentally" filled the local
11/70 with an uninterruptible instruction sequence. And who here hasn't
"tried out" that self-reproducing program? The only way to recover was to
switch it off, as the HALT key was implemented as an interrupt, and guess
what it wasn't doing at the time?
Try writing a self-reproducing program some time i.e. one that creates an
exact copy of itself; it's an exercise in computer science, and is not as
easy as it sounds.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
24 Mar
24 Mar
12:32 a.m.
Closest I've ever been murdered was when I
"accidentally" filled the local
11/70 with an uninterruptible instruction sequence."
SPL instruction. The PDP-11 was odd that while SPL was a "privileged"
instruction, rather that trapping if you did it in user mode, it just
"ignored" it.
Well, what it ignored was the actual change of the processor level. What
it still implemented was the side effect was that interrupts were locked out
until the next instruction fetch.
If you filled your instruction space up with SPLs you could lock up the
computer so that even the HALT key didn't work (you had to do a bus RESET).
In an attempt to do this in user mode in our hybrid-V6 system I tripped
across another bug. I did it during the day when there was a high load on
the system and my process got swapped out.
When it got swapped in, it rounded up the BRK to the next higher 64 bit
chunk. Of course this rolled around to zero. It allocated zero bytes of
memory getting zero and then did a DMA from our swap device to it.
That was a bit more flamboyant.
Fortunately , my mentor Mike Muuss tolerated these fiascos as long as I went
and fixed the bug I had just exploited afterwards.
12:43 a.m.
On Mar 23, 2016, at 7:32 PM, Ron Natalie
<ron(a)ronnatalie.com> wrote:
This is of course a fairly well known bug in the pdp11. I wonder if this was fixable with
a hardware mod, like the “there’s this NAND gate here” sort of fix to the MTPx/MFPx
instructions or if it required a change to the microcode, that presumably DEC wasn’t
interested in.
Closest I've ever been murdered was when I
"accidentally" filled the local
11/70 with an uninterruptible instruction sequence."
SPL instruction. The PDP-11 was odd that while SPL was a "privileged"
instruction, rather that trapping if you did it in user mode, it just
"ignored" it.
Well, what it ignored was the actual change of the processor level. What
it still implemented was the side effect was that interrupts were locked out
until the next instruction fetch.
If you filled your instruction space up with SPLs you could lock up the
computer so that even the HALT key didn't work (you had to do a bus RESET). [snip]
12:47 a.m.
The nand gate fix wasn't to fix a bug in MTPI but rather to allow access to the
user-I from the program itself, primarily to make the *abomination* nargs() function
work.
I don't believe DEC ever worried about "fixing" this as none of the DEC
OS's and not even the stock UNIXes could even implement such a problem. You could
chew up some processor time, but you couldn't absolutely lock things out.
1:05 a.m.
On Wed, Mar 23, 2016 at 6:46 PM, Dave Horsfall <dave(a)horsfall.org> wrote:
Have you any idea how fast the IBM 1403 printer can
slew blank pages?
Cough cough...
yep
It chewed through a box in an instant, and I got to
re-pack it afterwards. You also learned to not place your coffee cup on
it (I was doing the midnight shift at the time), because when it ran out
of paper then the door would open automatically...
What's coffee - try beer glass/plastic cup.
Once nice thing about raised floors is they kept your beer cold. On
weekend if we were having a party, I would bring a gallon milk jug fresh
from the tap's at my fraternity and put it under the floor.
I could usually bribe another operator to stay over for an unpaid hour or
so when the backups first ran. Then we would finish our beers and if I
was lucky, the "console bell" was a fire alarm. So with a patch to the TSS
kernel you could get it ring the console bell when the system needed human
attention. I could then go into the printer paper room where there was an
Tek 4010 graphics tube. Thus I could either go off to hack for a while
knowing that I would be called if the system needed me.
Clem
23 Mar
23 Mar
1:28 a.m.
On Tue, 22 Mar 2016, Greg 'groggy' Lehey wrote:
Yeah, but it would have cost him too much beer to bribe the comp ops into
sorting them...
I can show the exact place; it was just down the hall from Ken Robinson's
old office, in Elec Eng (Comp Sci floor).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
Walking down
the corridors of Comp Sci, a student in front of me
dropped his entire deck of approx 2000 cards, all over the floor... I
have no idea whether he got them sorted, but I sure as hell used
rubber bands after that!
But that's what the sequence numbers in columns 73 to 80 are for!
1:51 a.m.
On Mar 22, 2016, at 8:28 PM, Dave Horsfall
<dave(a)horsfall.org> wrote:
On Tue, 22 Mar 2016, Greg 'groggy' Lehey wrote:
Yeah, but it would have cost him too much beer to bribe the comp ops into
sorting them…
What? No model 82 offline sorter available?
Walking
down the corridors of Comp Sci, a student in front of me
dropped his entire deck of approx 2000 cards, all over the floor... I
have no idea whether he got them sorted, but I sure as hell used
rubber bands after that!
But that's what the sequence numbers in columns 73 to 80 are for!
6:49 a.m.
On Wednesday, 23 March 2016 at 12:28:41 +1100, Dave Horsfall wrote:
On Tue, 22 Mar 2016, Greg 'groggy' Lehey
wrote:
Yeah, but it would have cost him too much beer to bribe the comp ops
into sorting them...
They used to have big, mechanical machines for sorting cards. What
did they call them? Collators?
Greg
--
Sent from my desktop computer.
Finger grog(a)FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
Walking
down the corridors of Comp Sci, a student in front of me
dropped his entire deck of approx 2000 cards, all over the floor... I
have no idea whether he got them sorted, but I sure as hell used
rubber bands after that!
But that's what the sequence numbers in columns 73 to 80 are for!
7:02 a.m.
On 2016-Mar-23 17:49:19 +1100, Greg 'groggy' Lehey <grog(a)lemis.com>
wrote:
They used to have big, mechanical machines for sorting
cards. What
did they call them? Collators?
Sorters:
http://www.columbia.edu/cu/computinghistory/sorter.html
You select a column and it sorts the cards into bins by the value of that
column. You then stack the cards out of all the bins back into the feed
hopper and sort by the next column. You'd need 8 passes to do a full sort
(given sequence numbers in 73-80).
--
Peter Jeremy
7:12 a.m.
On Wednesday, 23 March 2016 at 18:02:29 +1100, Peter Jeremy wrote:
On 2016-Mar-23 17:49:19 +1100, Greg 'groggy'
Lehey <grog(a)lemis.com> wrote:
Ah, that's what Milo was referring to.
Greg
--
Sent from my desktop computer.
Finger grog(a)FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
They used to have big, mechanical machines for
sorting cards. What
did they call them? Collators?
Sorters:
http://www.columbia.edu/cu/computinghistory/sorter.html
You select a column and it sorts the cards into bins by the value of that
column. You then stack the cards out of all the bins back into the feed
hopper and sort by the next column. You'd need 8 passes to do a full sort
(given sequence numbers in 73-80).
1:54 p.m.
Yes, the model 82 SORTER could sort into 13 bins based on a single column
on the card (there are 12 rows in each column, the 13th is the reject bin).
A special selector deals with two holes punched in the column (letters and
symbols).
The collator (Typically a model 85) had fewer bins (4) but it could make
more intelligent decisions (based on the wiring of a plug board) on how to
distribute to those bins. In addition, it had two card hoppers that
allowed you to merge two files of cards together.
The 514 Reproducing Punch allowed you to copy info from one deck onto other
cards in a programmed fashion. It could also be connected via a mongo
cable to the 402 Accounting machine that could read cards, do some math, and
either print or punch (via the 514) the results.
Even at the time I learned all this, it was rapidly becoming obsolete.
Our high school still used these monsters to do the attendance records.
In college, our registration procedure used those. I could tell by the way
they did it that they were using my old friend the "Interspersed master gang
punching).
Once out of college two of my subsequent jobs (one at BRL and one at
Rutgers) was to deep six all the card processing equipment.
4:28 p.m.
Ron Natalie scripsit:
Once out of college two of my subsequent jobs (one at
BRL and one at
Rutgers) was to deep six all the card processing equipment.
Virtually, however, unit-record processing is still with us in the
form of flow-based programming, of which Unix pipelines constitute a
degenerate case.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
Original line from The Warrior's Apprentice by Lois McMaster Bujold:
"Only on Barrayar would pulling a loaded needler start a stampede toward one."
English-to-Russian-to-English mangling thereof: "Only on Barrayar you risk to
lose support instead of finding it when you threat with the charged weapon."
8:20 a.m.
On Wed, 23 Mar 2016, Greg 'groggy' Lehey wrote:
They used to have big, mechanical machines for sorting cards. What did
they call them? Collators?
Yeah, but in those days they cost departmental funny money; it was easier
to just bribe the ops (and I've been both a briber and a bribee).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
But that's what the sequence numbers in columns
73 to 80 are for!
Yeah, but it would have cost him too much beer to bribe the comp ops
into sorting them... 
21 Mar
21 Mar
11:07 a.m.
Random832 <random832(a)fastmail.com> wrote:
You also can't seek to a given line number in a file.
I was slightly startled by the coolness of the idea when I found out that
nvi uses Berkeley DB as its storage layer; its recno access method
makes a text file look like a random-access array of strings.
Tony.
--
f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/ - I xn--zr8h punycode
Dover: Variable 3 or 4. Slight. Fair. Moderate or good.
12:06 p.m.
Tony Finch scripsit:
I was slightly startled by the coolness of the idea
when I found out that
nvi uses Berkeley DB as its storage layer; its recno access method
makes a text file look like a random-access array of strings.
Classical sequential files, however, were simply random-access files
such that seeking to line n was just a matter of seeking to byte
n * MAXCHARSLINE. The last time I actually used such a thing was
on an early Tandem system when I was implementing the Software Tools.
Editable source used a different format, so I set things up so that
the Tools could either read source format or sequential format and
then wrote sequential format.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
At the end of the Metatarsal Age, the dinosaurs abruptly vanished.
The theory that a single catastrophic event may have been responsible
has been strengthened by the recent discovery of a worldwide layer of
whipped cream marking the Creosote-Tutelary boundary. --Science Made Stupid
22 Mar
22 Mar
12:13 a.m.
On Monday, 21 March 2016 at 8:06:34 -0400, John Cowan wrote:
Tony Finch scripsit:
You're presumably not talking about a Tandem format here. Were you
working with Denis Winn?
I was slightly startled by the coolness of the
idea when I found out that
nvi uses Berkeley DB as its storage layer; its recno access method
makes a text file look like a random-access array of strings.
Classical sequential files, however, were simply random-access files
such that seeking to line n was just a matter of seeking to byte
n * MAXCHARSLINE. The last time I actually used such a thing was
on an early Tandem system when I was implementing the Software
Tools. Editable source used a different format, ...
Presumably you *are* talking about Tandem's format here. I always
looked at it as an indication of how badly optimization attempts could
go wrong. The format limited line length to something less than 256
bytes (exact length was content dependent). The lines were split into
groups of up to 30 bytes, 15 bytes content and up to 15 bytes trailing
spaces. And this was the reason: it was a piss-poor attempt at
efficient storage. The only way to access it was with a special
library with procedures like EDITREAD and EDITWRITE. I still have a
number of these files, and there's no easy way to convert them.
Greg
--
Sent from my desktop computer.
Finger grog(a)FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
12:48 a.m.
Greg 'groggy' Lehey scripsit:
I assumed that was the byte structure, but perhaps it wasn't. It was the
format used for Fortran formatted sequential files and Cobol ORGANIZATION
IS SEQUENTIAL files. So yes, a Tandem format.
Classical
sequential files, however, were simply random-access files
such that seeking to line n was just a matter of seeking to byte
n * MAXCHARSLINE. The last time I actually used such a thing was
on an early Tandem system when I was implementing the Software
Tools.
You're presumably not talking about a Tandem format here. Were you working with Denis Winn?
I wasn't at Tandem, but at a Tandem customer, Kidder Peabody.
Presumably you *are* talking about Tandem's
format here. I always
looked at it as an indication of how badly optimization attempts could
go wrong. The format limited line length to something less than 256
bytes (exact length was content dependent). The lines were split into
groups of up to 30 bytes, 15 bytes content and up to 15 bytes trailing
spaces. And this was the reason: it was a piss-poor attempt at
efficient storage. The only way to access it was with a special
library with procedures like EDITREAD and EDITWRITE. I still have a
number of these files, and there's no easy way to convert them.
Right. Our implementation of getchar for the Software Tools (Ratfor
version) checked the file format and either did sequential reads or
EDITREADs. As I remember, though, you could only update existing files
with the library, you couldn't create new ones from scratch, which was
why we needed to use both formats -- all output files were sequential.
Of course, you could edit files with the Software Tools editor rather
than the Tandem editor, and then they'd come out as sequential files.
We also wrote a shell to complement the Software Tools, and a event-driven
pipe server that kept a table of all the pipes in the system. If you
opened $PIPE.#new, it would allocate a new pipe named $PIPE.Pnnnnn,
and then you could open that for reading or writing. Each pipe had a
one-line buffer, reads would hang if the buffer was empty and writes
would hang if it was full. The shell was more or less a Bourne shell,
though not 100% compatible: I remember that the standard prompt was ::,
pronounced "quadpoint".
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
The first thing you learn in a lawin' family is that there ain't
no definite answers to anything. --Calpurnia in To Kill A Mockingbird
18 Mar
18 Mar
5:01 p.m.
On 3/17/2016 8:48 PM, Warren Toomey wrote:
As a side note, the PDP-7 kernel knows about the
top-level directory ("dd")
but it is agnostic to the concept of "." and "..". What that means
is
that you can build a filesystem with "." and ".." links and the
kernel
will deal with them as per all other links. But you can also build a
filesystem without "." or ".." and the kernel doesn't care.
There's not enough evidence (source code, papers, anecdotes) to confirm
or deny the presence of "." in the PDP-7 code that Norman scanned for us.
".." does seem to exist as it is mentioned in one source file, ds.s.
It's an intruiging mystery.
So, I'm trying to figure out - at what point did "." and ".."
really
become part of the filesystem? Even as late as V7, "." and ".." were
not automatically added to directories when created - the "mkdir"
program used mknod() to create the directory, and then created the links
for "." and ".." by itself. I see code in the kernel that has special
handling of "." in unlink(), and also some in "namei()" - but I
don't
see anywhere where ".." is obviously handled at all. Though I figure it
has to be, somehow, because when mkdir makes the directory and creates
the links for "." and "..", it doesn't have to figure out the
inode
number or anything - that part just seems to happen behind the scenes.
I just can't figure out where or how....
The first place I saw where mkdir() became a system call, and the system
call handled "." and ".." by itself, was in 4.1BSD....
--Pat.
22 Mar
22 Mar
5:21 a.m.
On Mar 18, 2016 1:02 PM, "Pat Barron" <patbarron(a)acm.org> wrote:
Even as late as V7, "." and ".."
were not automatically added to
directories when created - the "mkdir"
program used mknod() to create the
directory, and then created the links for "." and ".." by itself.
Is that the last Unix that had a major number for file system objects? I
hadn't run into this but, thinking about it, it's kinda smart (probably
slower than specific execve kernel calls but still cool).
23 Mar
23 Mar
12:54 a.m.
On Tue, Mar 22, 2016 at 1:21 AM, shawn wilson <ag4ve.us(a)gmail.com> wrote:
Is that the last Unix that had a major number for file
system objects? I
hadn't run into this but, thinking about it, it's kinda smart (probably
slower than specific execve kernel calls but still cool).
I'm trying to parse your question a little and I think you may not quite
understand how “pre-BSD 4.2” UNIX systems worked.
In V7 the file system call works such that mknod(2) is used to create
special files and directories, it does it a little different than you
realize. Generally, there is no need to use it to create a regular file,
although you could. To wit the man page says:
SYNOPSIS
mknod(name, mode, addr)
char *name;
DESCRIPTION
*Mknod* creates a new file whose name is the null-terminated string pointed
to by name. The mode of the new file (including directory and special file
bits) is initialized from mode. (The protection part of the mode is
modified by the process's mode mask; see umask(2)
<http://www.unix.com/man-page/v7/2/umask/>). The first block pointer of the
i-node is initialized from add. For ordinary files and directories addr is
normally zero. In the case of a special file, addr specifies which special
file.
If you look at the code in mkdir.c (V7 mkdir.c source
<http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/mkdir.c>) you
see that what is being done is a mknod with addr=0 is being called and then
the two links.
. . .
if ((mknod(d, 040777, 0)) < 0) { fprintf(stderr,"mkdir: cannot make
directory %s\n", d);
++Errors;
return;
}
chown(d, getuid(), getgid());
strcpy(dname, d);
strcat(dname, "/.");
if((link(d, dname)) < 0) {
fprintf(stderr, "mkdir: cannot link %s\n", dname);
unlink(d);
++Errors;
return;
}
strcat(dname, ".");
if((link(pname, dname)) < 0) { fprintf(stderr, "mkdir: cannot link
%s\n",dname);
dname[strlen(dname)] = '\0'; unlink(dname);
unlink(d);
++Errors;
}
Where as creating special files did mess with the “special file” bits in
the mode.
If you look at the code in mknod.c (V7 mknod.c source
<http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/mknod.c>):
. . .
if(*argv[2] == 'b')
m = 060666; else
if(*argv[2] == 'c')
m = 020666; else
goto usage;
a = number(argv[3]);
if(a < 0)
goto usage;
b = number(argv[4]);
if(b < 0)
goto usage;
if(mknod(argv[1], m, (a<<8)|b) < 0)
perror("mknod");
1:07 a.m.
Arrrgh hit send too soon... sorry about that...
If you look at the two code snippets...look at the second parameter to
mknod. Note how for mkdir.c they are setting the directory bits (040777) and
in the mknod command they are setting special type (060666 for blocked) and
( 020666 for character) and also then adding in the 3rd parameter the value
to be placed in the special file. That is to say, directories do not have
major/minor numbers. They only differ from regular files in having the
040000 bit turned on, but when that is turned on, the kernel can interprets
contents. However if you open and read them, they look like regular files,
and you are just not allowed to write them.
Clem
On Tue, Mar 22, 2016 at 8:54 PM, Clem Cole <clemc(a)ccc.com> wrote:
On Tue, Mar 22, 2016 at 1:21 AM, shawn wilson <ag4ve.us(a)gmail.com> wrote:
Is that the last Unix that had a major number for
file system objects? I
hadn't run into this but, thinking about it, it's kinda smart (probably
slower than specific execve kernel calls but still cool).
I'm trying to parse your question a little and I think you may not quite
understand how “pre-BSD 4.2” UNIX systems worked.
In V7 the file system call works such that mknod(2) is used to create
special files and directories, it does it a little different than you
realize. Generally, there is no need to use it to create a regular file,
although you could. To wit the man page says:
SYNOPSIS
mknod(name, mode, addr)
char *name;
DESCRIPTION
*Mknod* creates a new file whose name is the null-terminated string
pointed to by name. The mode of the new file (including directory and
special file bits) is initialized from mode. (The protection part of the
mode is modified by the process's mode mask; see umask(2)
<http://www.unix.com/man-page/v7/2/umask/>). The first block pointer of
the i-node is initialized from add. For ordinary files and directories addr
is normally zero. In the case of a special file, addr specifies which
special file.
If you look at the code in mkdir.c (V7 mkdir.c source
<http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/mkdir.c>)
you see that what is being done is a mknod with addr=0 is being called and
then the two links.
. . .
if ((mknod(d, 040777, 0)) < 0) { fprintf(stderr,"mkdir: cannot make
directory %s\n", d);
++Errors;
return;
}
chown(d, getuid(), getgid());
strcpy(dname, d);
strcat(dname, "/.");
if((link(d, dname)) < 0) {
fprintf(stderr, "mkdir: cannot link %s\n", dname);
unlink(d);
++Errors;
return;
}
strcat(dname, ".");
if((link(pname, dname)) < 0) { fprintf(stderr, "mkdir: cannot link
%s\n",dname);
dname[strlen(dname)] = '\0'; unlink(dname);
unlink(d);
++Errors;
}
Where as creating special files did mess with the “special file” bits in
the mode.
If you look at the code in mknod.c (V7 mknod.c source
<http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/mknod.c>):
. . .
if(*argv[2] == 'b')
m = 060666; else
if(*argv[2] == 'c')
m = 020666; else
goto usage;
a = number(argv[3]);
if(a < 0)
goto usage;
b = number(argv[4]);
if(b < 0)
goto usage;
if(mknod(argv[1], m, (a<<8)|b) < 0)
perror("mknod");
2953
days inactive
2959
days old
36 comments
14 participants
participants (14)
-
Clem Cole -
Dave Horsfall -
Greg 'groggy' Lehey -
John Cowan -
Lyndon Nerenberg -
Milo Velimirovic -
Pat Barron -
Peter Jeremy -
Random832 -
Ron Natalie -
scj＠yaccman.com -
shawn wilson -
Tony Finch -
Warren Toomey