TUHS

tuhs@tuhs.org

28 participants
6556 discussions

by jnc＠mercury.lcs.mit.edu

On Dec 22, 2015, at 5:44 PM, Norman Wilson <norman(a)oclsc.org> wrote: > If that's the quality of reference they accept, there is simply no > reason to take anything they publish as gospel. You're mistaking Wikipedia for an information source you can rely on. It's not. It's more akin to an attempt to prove that an infinite number of monkeys, with an infinite number of typewriters, and an infinite amount of time, can produce a reliable encyclopaedia. (Yes, yes, spare me the surveys that show that Wikipedia's error rates aren't that bad, when compared with other encyclopaedias, etc.) Don't get me wrong, Wikipedia is quite useful as a place for an _introduction_ to any topic, but anyone who really wants to _reliably_ know anything about a topic needs to look at the references, not the articles. There was an attempt to do a Wikipedia-like online encyclopaedia that one could rely on - Citizendium - but alas it doesn't seem to have taken off (or hadn't when I got distracted from working on it). And I know whereof I speak; those who wish to be amused may want to read: http://en.wikipedia.org/wiki/User:Jnc/Astronomer_vs_Amateur And apologies for continuing the off-topic (this group certainly can't fix Wikipedia, people have been complaining about this problem for many years now), but some buttons, you just have to respond when they are pushed... Noel

9 years, 8 months

Re: [TUHS] etymology of cron

by Johnny Billquist

On 2015-12-23 17:04, norman(a)oclsc.org (Norman Wilson) wrote: > John Cowan: > > Wikipedia is by nature a*summary of the published literature*. If you > want to get some folklore, like what "cron" stands for, into Wikipedia, > then publish a folklore article in a journal, book, or similar reputable > publication. Random uncontrolled mailing lists simply do not count. > > ====== > > That sounds fair enough on the surface. > > But if you follow the references cited to support the cron > acronyms, you find that random unsupported assertions in > conference papers do count. That's not a lot better. I've had similar experiences with Wikipedia in the past. At one point I was trying to get the PDP-11 article corrected, as it said that the PDP-11 was an architecture that disappeared in the 80s (paraphrasing). I pointed out that the last *new* PDP-11 model from DEC itself was released in 1990, and that others are still making new PDP-11 CPUs. My corrections were reverted, and I was asked for citations. I went through a silly loop of requests for sources for my claims, while there seems to have been no demand for citation for the original claims, more than the "knowledge" of someone. It wasn't until I dug up the system manuals and documentation from DEC about the PDP-11/93 and PDP-11/94 (which have actual time of original publishing date printed) that my claims were (somewhat) accepted. I've also had numerous fights about the Wikipedia articles about virtual memory, where the original authors on the article clearly had not understood the difference between virtual memory and demand paged memory. The articles are better today, but when I last looked, they still had some details wrong in there. And getting anything corrected is hell, as any silly statement that is already in is almost regarded as gospel, and anything you try to correct is questioned to hell and back before anyone will accept it. (Hey, according to Wikipedia, a PDP-11 do not have virtual memory... I wonder what it has then. Fake memory? Although, the article might now actually accept that a PDP-11 do have virtual memory, although no OS I know of implements demand paging, but that could be done as well, if anyone wanted to.) Nowadays, I use Wikipedia to find information, but just take everything in there with a large grain of salt when it comes to details. There are just too many ignorant people who are writing stuff, and who seem to get anything accepted, and too much hassle to get anything corrected when you actually knows the subject. 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

9 years, 8 months

Re: [TUHS] etymology of cron

by norman＠oclsc.org

Perhaps Wikipedia would be satisfied if we could get Ken to write a letter to some current published journal, saying that he's the one who named cron, he's heard people are interested in how it got that name, here's how. We could then cite that as a reference. On the other hand, this may be an example of the degree to which one should trust Wikipedia. The `command run on notice' acronym claim is backed up by an article from the AUUG (Hi Warren!) Proceedings, 1994, in which the first reference to cron gives that explanation with no further reference. If that's the quality of reference they accept, there is simply no reason to take anything they publish as gospel. Sorry. Norman Wilson Toronto ON Proud that no one has yet made a spurious Wikipedia page asserting the etymology of my personal domain name.

9 years, 8 months

Re: [TUHS] etymology of cron

by norman＠oclsc.org

Larry McVoy: As a guy who has donated money to Wikipedia this whole thread makes me not want to donate again. Just me being grumpy. ==== Me too. Perhaps we should start our own online encyclopedia. In the Ken tradition we could call it pedi. (pdia sounds better, but pdia.org is already taken.) Norman Wilson Toronto ON

9 years, 8 months

etymology of cron

by Doug McIlroy

I had never doubted that "cron" was a contraction of "chrono-". Wikipedia, however, offered several folk acronyms on a par with it. Brian asked Ken, who confirmed, "cron comes from the prefix (greek?) for time. it should have been chron, but i never could spell." I edited Wikipedia to expunge the nonsense. Amusingly that makes the article less "verifiable" because there had been literature citations for the nonsense, but there is none for the fact. Doug

9 years, 8 months

Does anybody recall how the TU10 bootstrap code actually operates?

by Will Senn

All, I am in the process of gaining a deeper understanding of PDP-11 machine instructions and how the bootstrap loader and its cousins function. As part of that process, I am analyzing the code. I am concurrently working through the DEC bootstrap loader and the bootstrap loader that is described in the v6 documentation. The DEC bootstrap loader, while fascinating and elegant, is relatively straightforward, given its enormous range and the fact that it is self-modifying. I wrote up my preliminary notes here: http://decuser.blogspot.com/2015/12/analysis-of-pdp-11-bootloader-code.html The code that is in the v6 documentation on the other hand is not yielding easily to reasonable interpretation and I was hoping y'all might be able to shed some light on how it works. The following is the TU10 (TM11) bootstrap code from "Setting Up Unix - Sixth Edition": TU10 012700 172526 010040 012740 060003 000777 The author's notes around the code are: The tape should move and the CPU loop. (The TU10 code is not the DEC bulk ROM for tape; it reads block 0, not block 1.) Halt and restart the CPU at 0. The tape should rewind. The console should type ‘=’. Of course, following the instructions results in a successful outcome, but understanding what is happening is difficult given that this is a virtual environment and no discernible tape movement can be detected. My attempt at interpretation is along the following lines, I manufactured the dissasembly based on my reading of the PDP-11/40 handbook and the machine codes: 012700 MOV #172526, R0 ; moves the TM11 Current Memory Address Register (MTCMA) address into R0 172526 ; the immediate operand 010040 MOV R0,-(R0) ; moves the contents of R0, 172526, into memory location 172524, the TM11 Byte Record Counter (MTBRC) 012740 MOV #60003,-(R0); moves 60003 into memory location 172522, the TM11 Command Register (MTC) 060003 ; immediate data 000777 HALT This seems like gobbledegook to me. It moves the MTCMA (Magtape Current Memory Address) into R0, then it moves the MTCMA into the MTBRC (Magtape Byte Record Count), then it moves 60003 into the MTC (Magtape control register), which causes a read operation with 800BPI 9 Channel density. 172526 is -5252 in 2's complement. Am I misinterpreting the byte codes or is this some idiosyncratic way to get the Magnetic tape to rewind or something (the TM11 has a control function to rewind, so it seems unlikely that this is the case, but I'm mystified)? I single stepped through the code in the simulator, and the TM11 registers appear to be pretty unobservable (examining these three registers always displays 0's, but if I change from referencing the TM11 registers to another area of memory, say 100500 I see the values I would expect to see as they are being moved from the registers into memory). Thanks, Will

9 years, 8 months

2.11BSD mirror

by Warren Toomey

Hi all, I've been in contact with Steven Schultz and I've set up a mirror of his 2.11BSD patches at: http://www.tuhs.org/Archive/PDP-11/Distributions/ucb/2.11BSD/Patches/ I have no "git fu", but it would be nice to have a Git repository with all the sources fully patched. Oh, and new boot tapes :-) I should ask Santa for it. Cheers, Warren

9 years, 8 months

ed.c on Unix v5

by Mark Longridge

Ok, not sure if anyone will want to do this but I've just compiled ed.c from Unix v6 on Unix v5. It's not much bigger than the assembled ed, with 1314 lines of C code the compiled executable is only 6518 bytes vs 4292 for the original. I was looking at the source code and didn't see anything that the v5 cc couldn't handle. I trimmed the source a bit, there's a function at the end called getpid() which is commented out. The comment says: /* Get process ID routine if system call is unavailable. */ but my version of v5 does have that system call so it's all good. It's been run a few times and it seems to work just fine. It may even have a few more features than the v5 ed, I'm not sure yet :) Mark

9 years, 8 months

Re: [TUHS] ed.c on Unix v5

by jnc＠mercury.lcs.mit.edu

> From: Random832 > Not quite. On a stock V6 kernel, system call 30 (smdate/utime) maps to > nullsys rather than nosys. Oh, right. (Hadn't checked the number, assumed they used a new one for utime.) Noel

9 years, 8 months

Re: [TUHS] ed.c on Unix v5

by jnc＠mercury.lcs.mit.edu

> From: Random832 > Non-existent syscalls map to nosys, which sets u_error to 100 ... which > causes the process to be sent a signal SIGSYS. Oh, right, I'd forgotten that. So, getting back to v6tar, I'll bet that if you try and use it to _read_ a TAR file file under V6 (i.e. write files into the V6 filesystem), it will bomb out (because of the call to utime). Noel

9 years, 8 months

Re: [TUHS] ed.c on Unix v5

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge > Not too sure about reversing getpid.o, but maybe possible with db? Well, me, I'd just use 'od' - but then again, I have ucode for disassembling PDP-11 octal! :-) (OK, OK, so a lot of the less common instructions I have to look up! :-) But, seriously, yeah, 'db' is probably the way to go. FWIW, it's possible to get 'adb' running under V6 without much (any?) work, too. Although maybe it needs the 'phototypesetter' C compiler? I'd have to check... There's also a 'cdb' running around (I found a copy on the 'Shoppa disks'), which is basically 'db' but augmented with a few useful commands - maybe stack backtrace, I don't recall the details, the documentation in on my V6, and I don't feel like spinning it up just to look for that. Noel

9 years, 8 months

Re: [TUHS] v6tar from v7 on v6, too large?

by jnc＠mercury.lcs.mit.edu

So, speaking of system calls that are missing in earlier versions of Unix, that tickled a memory: > From: Will Senn > ... a special version of tar must be prepared to run on V6. > The document goes on to describe a reasonable method to make v6tar on > v7 and copy the binary over to the v6 system. When I got tar running on my V6, I didn't know about this, and I took a V7 tar and got it running myself, see here: http://mercury.lcs.mit.edu/~jnc/tech/ImprovingV6.html#tar One thing I found out while doing that is that tar uses the 'utime' system call on V7 to set the file date, but i) V6 doesn't have utime() (although it has smdate(), albeit commented out in the standard distro), and ii) on now looking in src/cmd/tar and src/libc/v6 in the V7 distro, I don't see a replacement version of utime(). As near as I can make out, 'v6tar' must be using the standard V7 version of utime(), which I assume turns into a call to nosys() on V6 (returns an error); tar doesn't check the return value, so the call fails (silently). So v6tar won't correctly set the file date when moving a file _to_ V6. Noel

9 years, 8 months

Re: [TUHS] ed.c on Unix v5

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge <cubexyz(a)gmail.com> > if one looks at /lib/libc.a via 'ar t getpid.o' you can see the object > file getpid.o Library, schlibrary! The important question is 'is it in the kernel source'? (Although now that I think about it, if the library routine tries to use a non-existent system call, it should return an error. It would be interested to disassemble the library routine, and see what it thinks it is doing.) Noel

9 years, 8 months

Re: [TUHS] Pre-v6 images and 2.11BSD patches

by Johnny Billquist

On 2015-12-12 06:31, Peter Jeremy<peter(a)rulingia.com> wrote: > Also, I've seen suggestions that there's a 2.11BSD patch later than > 447 but I can't find anything "official" andwww.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)? Yes, I did 448. Various bits and pieces that were fixed there, but unfortunately I haven't managed to reach Steve to get it officially sanctioned. I've passed it out a few times, but there is no canonical place for it. You can find it at ftp://ftp.update.uu.se/pub/pdp11/2.11bsd/ Feel free to pass that information around. Things fixed in there: . Added a timeout to boot prompt for automatic boot . Made console 8-bit clean . Changed gethnamadr to fall back to /etc/hosts if dns fails. . Fixed kernel build process to get version and date properly into kernel. . Fixed raboot to work on non-DEC mscp controllers . Fixed tmac macro to work correctly after 2009. . Fixed a couple of documentation errors. Essentially small issues that bothered me as I was running on an 11/84 with a CMD controller a few years ago. A system on which I also booted other OSes, which is why the 8-bit clean issue also bothered me. (Also was really surprised at the ugly Y2K fix someone had done with tmac, which failed again in 2010). 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

9 years, 8 months

OT: Happy birthday, Ken Iverson!

by Dave Horsfall

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."

9 years, 8 months

Pre-v6 images and 2.11BSD patches

by Peter Jeremy

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

9 years, 8 months

Re: [TUHS] Testing, testing..

by Dave Horsfall

> 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."

9 years, 8 months

Testing, testing..

by Dave Horsfall

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."

9 years, 8 months

Broken TUHS mirror: li1202-53.members.linode.com

by Dave Horsfall

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."

9 years, 8 months

TUHS Mail Archive is now searchable

by Warren Toomey

All, I've finally set up a search system for the mailing list. It's at http://minnie.tuhs.org/cgi-bin/mailman/tuhs.cgi and it's also hyperlinked on the main list page at http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs I've not yet set up a cron job to keep it updated, and yes the interface is ugly but it works. Cheers, Warren

9 years, 8 months

tar on v6 not creating directories on v6

by Will Senn

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

9 years, 8 months

Re: [TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

by norman＠oclsc.org

/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

9 years, 8 months

Re: [TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

by Doug McIlroy

> 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

9 years, 8 months

Re: [TUHS] TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

by Doug McIlroy

Forget that I said, "I think that tar was written by Chuck Haley or Greg Chesson". Ken confirms that he wrote it, for dectape. Doug

9 years, 8 months

Re: [TUHS] Pre-v6 images and 2.11BSD patches

by Johnny Billquist

On 2015-12-12 07:16, William Pechter<pechter(a)gmail.com> wrote: > > Warren Toomey wrote: >> >On Sat, Dec 12, 2015 at 03:54:16PM +1100, Peter Jeremy wrote: >>> >>Also, I've seen suggestions that there's a 2.11BSD patch later than >>> >>447 but I can't find anything "official" andwww.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)? >> >[ Back to a real keyboard ]. Yes I'd be very happy to mirror 2bsd.com. >> >Does anybody know what's happened to Steven Schultz? >> > >> >Cheers, Warren >> >_______________________________________________ >> >TUHS mailing list >> >TUHS(a)minnie.tuhs.org >> >http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs > Last patch is 447 from June 2012. Uh. No. 447 is from December 31, 2008. See /VERSION in the patch set, which holds the patch version and date for the patch. And I did an unofficial 448 in 2010, which I have tried to spread, and which I suspect is the patch referred to above... > I can get to the site just fine... pasted the patch below if it helps > anyone. > I haven't heard anything about him. Haven't worked at the same company > since the early 1990's... I used to talk with him a lot in the past, but have not been able to raise him, and haven't seen anything from him in over 5 years... No idea what he is up to nowadays... 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

9 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS