> From: Rik Farrow <rik(a)rikfarrow.com>
> Was the brevity typical of Unix command names a function of the tiny
> disk and memory available? Or more a function of having a Teletype 33
> for input?
I'm not sure the answer was ever written down (e.g. in a memo); we will
probably have to rely on memory - and memories that far back are now fairly
thin on the ground by now. Perhaps Mr. McIlroy (or Mr. Thompson, if we're
_really_ lucky) will humor us? :-)
I have the impression that some of the names are _possibly_ inherited from
Multics (which the early Unicians all used before Unix existed) - but maybe
not. The command to list a directory, on Multics, is 'ls' (but see below) -
but the Multics qcommand to remove a file is 'del' (not 'rm'); and change working
directory is 'cwd'. So maybe ls' is just chance?
Multics had a 'feature' where a segment (file) could have additional names (to
the main name), and this is used to add short aliases to many commands, so the
'base name'' for the directory list command is 'list'; 'ls' is a short
alias. A list of Multics commands (with short forms) is available here:
https://www.multicians.org/multics-commands.html
I'm not sure how early that alias mechanism came in, though; my copy of
"Introduction to Multics" (February, 1974) doesn't have short names (or, at
least, it doesn't use them).
It won't have anything to do with disk and memory. Having used a Teletype, it
would take noticeably longer to type in a longer name! It's also more effort
and time. I would expect those are the reasons for the short names.
Noel
> I wonder what happened to the amazing library at Murray Hill.
Last I knew, the Bell Labs archives were intact under supervision of a
professional archivist. Formally speaking, the archives and the library
were distinct entities. The library, which was open to self service 24
hours a day, declined rapidly after the bean counters decreed that it
should henceforth support itself on rental fees. Departments immediately
turned to buying books rather than borrowing them. It's very likely that
this was bad for the Labs' bottom line, but the cost (both monetary and
intellectual) was not visible as a budgetary line item.
The 24-hour library contributed to one of Ken's programming feats. Spurred
by a lunchtime remark that it would be nice to have a unit-conversion
program, Ken announced units(1) the next morning. Right from the start, the
program knew more than 200 units, thanks to a book Ken grabbed from the
library in the middle of the night.
Doug
> That CSTR number 1 is nicely formatted, is that troff?
The archive's CSTR 1 is ersatz. It's a 1973 journal article obtained from
JSTOR. I imagine the manuscript was largely copied from the CSTR, but the
printed paper certainly differs in meta-content and in layout, say nothing
of font. Having gone through the usual route of journal submission and
revision, the body text is probably not word-for-word identical to the CSTR
either.
Doug
Clem Cole:
Interesting -- 'Jason' had always been a Pascal hacker when the strip was
first created. As I recall, Berkeley Breathed had Wendell (his hacker
character) comment on that during the time of Pascal/C Wars.
====
But Jason later was revealed to be wearing Unix underpants:
https://www.gocomics.com/foxtrot/2002/02/25
Norman Wilson
Toronto ON
Hello everyone, I've found myself in the exceptionally fortunate circumstance of securing ownership of a MAC-TUTOR BELLMAC-8 SBC unit. It is still in shipment so I can't assess its operation yet, but I was wondering if anyone is aware of any surviving assemblers, linkers, etc. for this architecture? If not, I'm prepared to roll my own based on available documentation, but figured I'd ask to see if there's anything I can start with. From what I can tell, the main development environment was PWB, specifically the Bell System internal varieties, with the BTL edition of Release 5.0 literature describing things like m8as(1), m8cc(1), etc. as Division 452 Computer Center standard commands.
There is a bit of information here as well: http://ferretronix.com/march/sbc/mactutor/
Thanks for any tips! Regardless of how much I can manage to do with it, I'll be sure to get some good pictures and take some notes on what I am able to figure out with the thing. I presume the Gunkies wiki would be a good place to document that sort of thing?
- Matt G.
P.S. Pardon if this belongs on COFF, I figured since UNIX was the canonical development system and it is also a Bell Labs thing, I'd ask here first.
I noticed there are kexec talks this year at Linux Plumbers. Kexec, kernel
boots kernel, has had a 25 year gestation in Linux, but it looks like it's
finally coming together, driven by need.
Thereby hangs a tale.
in 1977, I was working at udel with Ed Szurkowski, the first sysadmin of
the Unix systems we got in 1976 (first machine was an 11/70). Ed was a
gifted engineer and did all kinds of neat work on v6. He later went to the
Labs once he got his PhD and I lost track of him.
Ed got tired of watching the bootstrap slowness, and wrote a system call
that did the following:
1. load kernel in memory from system call argument
2. put special signature in low memory telling bootstrap "look in memory"
3. reboot via reset.
Now, this works, because back then, ROM boot code did not zero memory.
Memory was unchanged across reset. So the bootstrap could find the magic
bits and start the kernel.
I've lost the code, I carried the listings for decades but finally dumped
them. A shame.
But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel" or
was there something before?
> The array size} limit that I found through trial and error is (2^15)-1.
> Declaring an array that is [larger] results in an error of "Constant
required",
On its face, it states that anything bigger cannot be an integer constant,
which is reasonable because that's the largest (signed) integer value. Does
that version of C support unsigned constants?
Doug
It's a bit off-topic but Warren OK'd it: I'm trying to tidy the absolute
dragon's hoard I call an office, so I'm looking to give away some books
I haven't touched in years. These are free for the taking for anybody
who wants to drive to SF and get them. I'd really prefer for somebody to
take them all at once, of course.
- DEC PDP11/70 Processor Handbook
- DEC VAX11 Architecture Handbook
- DEC PDP11 Peripherals and Interfacing Handbook
- DEC Introduction to Programming (PDP-8)
- Programming Languages: History and Fundamentals (Sammet)
- Computer Networks, 1st ed (Tanenbaum)
- Modern Operating Systems, 2nd ed (Tanenbaum)
- Operating Systems Design and Implementation, 1st ed (Tanenbaum)
- Advanced Programming in the UNIX Environment (Stevens)
- Computer Architecture and Organization, 2nd ed (Hayes)
- Compilers: Principles, Techniques, and Tools (Aho, Sethi, Ullman)
- The Undocumented PC, 2nd ed (van Gilluwe)
- Cybernetics (Wiener)
If you want these, please email me *off-list* to set it up.
John
> From: Ron Minnich
> Ed got tired of watching the bootstrap slowness
This may be a dumb question (in which case, my apologies), but which part of
booting a PDP-11 UNIX was slow? And thus, which parts did he bypass in a
'quick reboot'? (I'm having a bit of a hard time working it out.) I can think
of the following stages as potentially being 'slow':
1 - reading in the kernel image from disk
2 - sizing/clearing main memory
3 - loading running /etc/init
3A - creating all the 'loqin's
3B - starting all the daemons/etc with /etc/rc
(There's obviously a conflict between 2 and 3*; one can't avoid 3* if one
does 2.)
Which ones did he want to avoid?
Avoiding 3* puts some limitations on the system, obviously, because it means
one has to keep running processes around; the process table has to have the
same format (and be in the same location - or it has to be moved before the
new system is started). (Technically, I guess one would have to save the
inode and file tables, too; there isn't enough saved data in the kernel to
re-open files, plus there are file read/write ocation pointers, etc.)
One could sort of do 2 also, if one were prepared to 1) swap all processes
out to secondary storage before 'rebooting', and ii) saving the process table.
> But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel"
> or was there something before?
Are you talking about for UNIX, or across all operating systems? I don't have
that broad a memory any more, to know - did TWENEX have something like that?
Noel
