- TUHS - www.tuhs.org

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > Weren't V5/6/7/etc distributed as bootable tapes? Set the switch register > to point to the tape instead of the disk... Yes. See here: https://gunkies.org/wiki/Installing_UNIX_Sixth_Edition https://gunkies.org/wiki/Installing_Unix_Seventh_Edition for the details of how it works. Noel

4 years, 11 months

2
1
0 0

Re: [TUHS] V6 Console IO

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole <clemc(a)ccc.com> > another old V6 trick is the use file redirection from the different > terminal to unlock a hosed tty. 'stty {mumble} > /dev/ttyX', in case that wasn't clear. Note that this only works if you have a working shell on _another_ terminal, so if you're e.g. working with an emulation which has only one working terminal, and your raw-mode program on it has gone berserk, 'See Figure 1'. It really is advised to have another working terminal if you want to play with raw-mode programs. Noel

4 years, 11 months

1
0
0 0

Diff and Patch on v7

by Will Senn

I got a diff for adding actual backspace and delete to v7, linked off of gunkies... Anyhow, I can manually edit the referenced files and rebuild, but I would rather do it canonically. I don't see patch anywhere, so did v7 users use diffs to patch source and if so what's the magic? Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

4 years, 11 months

5
5
0 0

Re: [TUHS] Groff on Windows (for PDF output)?

by Doug McIlroy

Echoing other answers, I regularly use groff in Cygwin. If you're into Unix/Linux, Cygwin is a great tool with a remarkably clean installation process. I use default PostScript output by choice, because I can tinker with PostScript but not with PDF. ps2pdf (available from Cygwin) has always worked when I need PDF. I must admit, tough, that this approach will be pretty onerous if you do not want Cygwin for any other reason. And I should add that PoscScript requires a special viewer; I use gsview. Doug

4 years, 11 months

4
5
0 0

Traditional method of dealing with embedded shar files

by Will Senn

As y'all know, I'm a relative latecomer to the world of Unix, but I do try to figure out how y'all did it back when. So, sometimes, as in this case, I can figure out how to do something, but I'm curious how it was done back in the day, moreso than how I can get it done today. I'm looking at the patching of my shiny new 2.11 BSD pl 431 system running on my speedy little virtual PDP-11/70, so I grabbed patch 432 (here's a portion of the patch): ... To install the update cut where indicated below and save to a file (/tmp/432) and then: cd /tmp sh 432 ./432.sh ./432.rm sh 432.shar patch -p0 < 432.patch Watch carefully for any rejected parts of the patch. Failure of a patch typically means the system was not current on all preceeding updates _or_ that local modifications have been made. ... ====== cut here #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create: # 432.rm # 432.sh # 432.shar # 432.patch ... # End of shell archive This seems straightforward. Just follow the directions et voila magic happens. My questions for y'all are how would you go about doing this? Use vi to delete everything through the ==== cut here line? Use some combination of standard unix tools to chop it up? What was your workflow for patching up the system using these files? In my world, if I screw something up, it's 15 seconds to run a restore script in my simh directory and I can try again, so my level of concern for a mistake is pretty low. If I was doing this in 1980, on real hardware, I would have had many concerns, as I'm sure some of y'all can remember, how did you prepare and protect yourselves so a patch was successful. BTW, I thought .shar was an archive format, so when I saw the patch was a shar file, I was worried it would be in some binary form, lo and behold, it looks like text to me... not even b64. So much to learn, so little time. Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

4 years, 11 months

6
13
0 0

Re: [TUHS] V6 Console IO

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy > Yeah, write is unbuffered though I think Noel is correct, it's going to > a tty and the tty will buffer until \n The 'wait until newline' is on the input side. Output is buffered (in the sense that characters are held in the kernel until the output device can take them); but normally output will start to happen as soon as the device is able to take them. Only a certain amount can be buffered though, after that (the 'high water', I think it's called), the process is blocked if it tries to do output, and awakened when the buffered output level goes past the 'low water' mark. Note that getchar() and putchar() are subroutines in a library; looking at the source: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s4/getchr.s you can see how they relate to the actual read/write calls to the OS. > So you probably have to set the tty in raw mode Probably best to run such programs from something other than the main console, because if there's a bug in the program, and the terminal is in raw mode, if you're on the console, you may have to reboot the system to regain control of the system. (Interrupt characters, ^D etc won't work.) > (sorry that I'm vague, I never ran V6). Tnat's OK, I pretty much have the V6 kernel memorized, from working with it back in the day... :-) Noel

4 years, 11 months

3
2
0 0

V6 Console IO

by Paul Riley

I am using C in V6 to create a Forth compiler. I don;t have any interest in Forth as a general purpose language, however I do like it. It's satisfying to create a language from the ground up. I'm interested in it a simple and extensible interpreted language for toying with my PDP-11s, so I'll have some with it in the future. I have a very basic problem. I am simply using getchar and putchar for console IO, which is convenient indeed. I'm struggling however with how C processes the IO. It seems that when I type at the console, my typing is immediately echoed to my terminal window. When I press backspace the system responds with the character that was deleted, which is fine, as I assume it was from the paper teletype days. However, my code is receiving input and also echoing the output, but nothing appears on the terminal until I press enter, when the system displays the whole line of input, which is essentially a duplicate of what the terminal originally displayed, but with the consolidated edits. My code is reading and echoing the input character by character. Here's my question. How can I suppress the original C/Unix echo, and get my output to appear immediately? This simple sample code form the C programming manual behaves the same. int main() { int c; while ((c = getchar()) != EOF) { putchar(c); } } Paul *Paul Riley* Mo: +86 186 8227 8332 Email: paul(a)rileyriot.com

4 years, 11 months

2
4
0 0

AT&T Research

by John P. Linderman

I'm hearing that 50% of what's left of AT&T research got the axe today. I'm hoping to hear from friends about details. God's gift to google, as we have said in the past.

4 years, 11 months

9
11
0 0

Bell Labs Sysadmins

by norman＠oclsc.org

Henry Bent: Are there any former Bell Labs sysadmins on this list? My father was the sysadmin for hoh* (Crawford Hill, mostly the radio astronomy folks) in the mid-late '80s and early '90s and I would be especially interested to hear from hou* (Holmdel, what a building!) folks but also ihn* (Indian Hill) and the like. I'm very curious about what life was like on the ground, so to speak. ===== It is worth pointing out that, like many universities, Bell Labs had at least two layers of computing and therefore of sysadmins. There were official central Comp Centers, which is the world Henry asks specifically about; but there were also less-central computing facilities at the divisional and center and department level. I never worked for a comp center, but my role in 1127 was basically that of sysadmin for our center's own systems; the ones used both for our day-to-day computing (including that known to the uucp world as research!) and for OS and other experiments and research and hacking. There were also two large VAXes called alice and rabbit, which afforded general-use computing for other departments in Division 112. Us 1127 sysadmins (I wasn't the only one by any means) ran those too; I don't know the full history but I gather that happened because there was some desire to run the Research version of UNIX rather than the comp-center one for that purpose. One system I had hands in straddled the researcher/comp-center boundary: 3k, the Cray X-MP/24 bought specifically for researchers. It was physically located in the comp center, but managed jointly: it ran Cray's UNICOS but with substantial additions from the Research world, including the stream I/O system (which is rather self-contained so it was not too hard to graft into a different UNIX) and Datakit support (using a custom interface board designed and built by Alan Kaplan and debugged by me and Alan over several late-night sessions. (I remember that the string "feefoefum\n", which is an obscure cultural reference from one of my previous workplaces, was particularly effective at shaking out bugs!) Once UNICOS-a-la-Research was running stably, staff from the Murray Hill Comp Center looked after day-to-day operations, with Research involved more for software support as needed. Norman Wilson Toronto ON

4 years, 11 months

1
0
0 0

Bell Labs Sysadmins

by Henry Bent

Are there any former Bell Labs sysadmins on this list? My father was the sysadmin for hoh* (Crawford Hill, mostly the radio astronomy folks) in the mid-late '80s and early '90s and I would be especially interested to hear from hou* (Holmdel, what a building!) folks but also ihn* (Indian Hill) and the like. I'm very curious about what life was like on the ground, so to speak. I'll start off with a quick anecdote. When I started college I began working for the computing center doing menial jobs. There was an older, ex-army guy leading the networking department who extolled the virtues of the VAX up and down; I think Oberlin would have kept the VAX 6620 running VMS 5.5 forever if he had his way. Anyway, I mentioned his position to my father and he told me that the best thing he ever did was replace the VAX systems (and the endless mounting/remounting of RL02s for user data) with early generation Sun 4 systems. -Henry

4 years, 11 months

2
1
0 0

G R Emlin

by Doug McIlroy

Coming upon this dedication in W.B. Yeats's book, "Irish Folk stories and Fairy Tales", I felt a frisson of connection: "Inscribed to my mystical friend, G. R." Mystically present in the Unix room and on the 1127 org chart, G. R. Emlin took a place in our little community akin to that of fairies in Irish peasant culture. First encountered by Fred Grampp, G. R. manifested to others in various guises, ranging from Grace Emlin, whom I remember as a security guru, to a Labs-badged apparition now housed in the corporate archives (www.peteradamsphoto.com/unix-folklore/) My most memorable personal encounter was when I received from G. R. a receipt for paint for the water-tower project (spinrooot.com/pico/pjw.html) as part of a request for reimbursement. I passed the voucher up the chain of command to our executive director, Vic Vyssotsky. Unfortunately for G. R., Vic, despite his masterful ability to bypass bureaucratic obstacles, declared he wasn't authorized to approve plant improvements. Doug

4 years, 11 months

6
6
0 0

211BSD Version in the Unix Archive

by Will Senn

Hi All, I'm currently doing some work with 211BSD and the best version that I've come across for my investigations is the one put together by Andre Luvisi, based on the distro in the Unix Archive at https://tuhs.v6shell.org/UnixArchiveMirror/Distributions/UCB/2.11BSD So far as I can figure out (and I'm a little bit fuzzy around the edges), this appears to be patch level 431, at least according to https://tuhs.v6shell.org/UnixArchiveMirror/Distributions/UCB/2.11BSD/VERSION. I have a number of questions that hopefully, someone can shed some light on: 1. Is it really pl 431? 2. How can I tell? 3. Is it the latest tape image available (I've seen plenty of disk images, but those are already installed)? 4. Is there a howto bring it up to the next patch level document lying around somewhere? I've seen Warner's work on going the other direction and that's fascinating in it's own right, but I'd like to see about patching up to latest. Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

4 years, 11 months

2
2
0 0

Re: [TUHS] 211BSD Version in the Unix Archive

by Will Senn

Well, I figured out number 4, duh! 4. Is there a howto bring it up to the next patch level document lying around somewhere? Each patch is self documenting :). Just do what it says and it should work... we'll see! Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

4 years, 11 months

1
0
0 0

Re: [TUHS] A/UX

by Ed Carp

Thanks to all who responded!!

4 years, 11 months

1
0
0 0

MicroVAX architecture (was: Linux is on-topic)

by Paul Winalski

On 7/19/20, emanuel stiebler <emu(a)e-bbes.com> wrote: > > That's why DEC made also the MicroVAX. I had once a MVII/BA23 in my > samsonite. Weird look at customs, but worked ;-) > By the early 1980s it was apparent that some of the more complicated VAX instructions weren't worth the space they took up in firmware. Especially POLY and EMOD, which turned out to be both slower and less accurate than coding them up as subroutines. And the PL/I and COBOL compilers were implementing packed decimal using decimal shadowing. Chucking out those instructions and doing them by emulation in the OS freed up enough chip real estate to allow the remaining VAX architecture to be implemented on a chip. All the later VAXen supported only the MicroVAX subset architecture in hardware/firmware. I don't recall which was the last VAX to support the whole architecture in hardware/firmware. Perhaps the VAX 8200/8300 (Scorpio)? That was a single-board implementation. It could be paired with a high-end Evans & Sutherland 3D graphics monitor. DEC tried unsuccessfully to use that combination to compete with Apollo in the workstation market, but it was too little too late. One reviewer said that coupling the E&S graphics to the VAX 8200 was like turbocharging a lawn mower. Did Unix support that configuration, or was it VMS-only? -Paul W.

4 years, 11 months

2
1
0 0

Re: [TUHS] Linux is on-topic

by Alexander Voropay

IMMSMC the early Linux had problems with some old-good programs i.e. Sendmail. New-born Linux hesitated between POSIX-BSD-Solaris semantic i.e. in file-locking, pty, network interface binding e.t.c. >From the early Sendmail README: === Linux Something broke between versions 0.99.13 and 0.99.14 of Linux: the flock() system call gives errors. If you are running .14, you must not use flock. You can do this with -DHASFLOCK=0. Around the inclusion of bind-4.9.3 & linux libc-4.6.20, the initialization of the _res structure changed. If /etc/hosts.conf was configured as "hosts, bind" the resolver code could return "Name server failure" errors. This is supposedly fixed in later versions of libc (>= 4.6.29?), and later versions of sendmail (> 8.6.10) try to work around the problem. Some older versions (< 4.6.20?) of the libc/include files conflict with sendmail's version of cdefs.h. Deleting sendmail's version on those systems should be non-harmful, and new versions don't care. Sendmail assumes that libc has snprintf, which has been true since libc 4.7.0. If you are running an older version, you will need to use -DHASSNPRINTF=0 in the Makefile. If may be able to use -lbsd (which includes snprintf) instead of turning this off on versions of libc between 4.4.4 and 4.7.0 (snprintf improves security, so you want to use this if at all possible). NOTE ON LINUX & BIND: By default, the Makefiles for linux include header files in /usr/local/include and libraries in /usr/local/lib. If you've installed BIND on your system, the header files typically end up in the search path and you need to add "-lresolv" to the LIBS line in your Makefile. Really old versions may need to include "-l44bsd" as well (particularly if the link phase complains about missing strcasecmp, strncasecmp or strpbrk). Complaints about an undefined reference to `__dn_skipname' in domain.o are a sure sign that you need to add -lresolv to LIBS. Newer versions of linux are basically threaded BIND, so you may or may not see complaints if you accidentally mix BIND headers/libraries with virginal libc. If you have BIND headers in /usr/local/include (resolv.h, etc) you *should* be adding -lresolv to LIBS. Data structures may change and you'd be asking for a core dump.

4 years, 11 months

1
0
0 0

1993 book on Mach programming available for shipping

by Arnold Robbins

Hi All. I have a copy of https://www.amazon.com/Programming-Under-Mach-UNIX-systems/dp/0201527391/re… For the cost of shipping from Israel, to the first one who wants it. Let me know. Thanks, Arnold

4 years, 11 months

4
3
0 0

2.11BSD Update

by Warner Losh

I've managed to reach an important milestone in my efforts to recreate 2.11BSD pl 0 from sources. I've managed to unwind the patches, recreated some programs that were lost (the patches destroyed data and weren't modern context diffs). So I've managed to unwind back to pl 0, I've managed to bootstrap the assembler (it wouldn't build on pl 195), recreate ld, ranlib and ar. I've rebuilt the libraries and many binaries. https://bsdimp.blogspot.com/2020/07/211bsd-original-tapes-recreation.html No tapes yet, but I thought people here would like to know. Warner

4 years, 11 months

3
3
0 0

v7 uucp debugging help requested

by Adam Thornton

(if this is better suited for COFF, that'd be fine too) I've been trying to set up UUCP on my V7 system and its raspberry Pi host. This plus the "s" editor (already working) are really all that's needed to make this something pretty close to a daily driver, if all I wanted to do was write text files (which in some sense is all my job _is_, but to be fair I get a much more immediate feedback loop in my current environment). I was following https://github.com/jwbrase/pdp11-tools/blob/master/howtos/V7%20UUCP%20Insta… more or less--I had already rebuilt v7 with the DZ terminal driver and was using it for interactive sessions (albeit, before I started trying to get UUCP running, with 7-bit line discipline--but I've since changed that). I have 16 DZ lines, I've set them to 8-bit mode. They're working fine, because I can use them for terminal sessions. I've built UUCP, set a node name, and set it up on the pi. I can execute uucico to send files, and it, frustratingly, almost works. >From the Pi side, I see (with uulog): uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP) uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful (protocol 'g' sending packet/window 64/3 receiving 64/7) uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending /home/adam/git/simh/sim_scsi.h (6780 bytes) uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting for packet uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent 86, resent 6, received 1 uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0, order 0, remote rejects 0 uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds 5440 bytes 19 bps) So it's clearly logging in, and if I telnet in directly, the v7 end is starting uucico as expected: login: pi-uucp Password: Shere uulog -x on the v7 side has no output, and nothing ever appears in the spool directory, which I suspect is a direct result of the timeout waiting for packet. So my question is, what else do I do to debug this? Clearly the pi (Taylor UUCP) side is expecting something else--maybe an acknowledgement?--from the v7 side to let it know the transmission was successful. Any help would be appreciated. Adam

4 years, 11 months

11
33
0 0

Re: [TUHS] AT&T Research

by Norman Wilson

John Linderman: Every "divestiture" had an adverse effect on critical mass. The split between AT&T and Bellcore was a big hurt. The split between AT&T and Lucent was another. When I joined the Labs in 1973, it was an honor to work there. ==== Maybe I'm blinded because I wasn't there earlier, but to me, joining Bell Labs in 1984, just after the original divestiture that split off Bellcore, was still an honour. There were certainly good people I never had a chance to work with because they went to Bellcore, but in 1127 at least, morale was good, management stayed out of our way and encouraged researchers to work on whatever interested them, and a lot of good work was done even if that group was no longer the source of All UNIX Truth. (In fact I think we missed the boat on some things by being too inwardly-focussed, TCP/IP in particular, but divestiture didn't cause that.) It seemed to me that the rot didn't really begin to show until around 1990, the time I left (though not for that reason; this is hindsight). Upper management were visibly shifting focus from encouraging researchers to do what they did best to treating researchers as a source of new products to be marketed. The urge to break the company up further seems to me to have been a symptom, not a cause; the cause was a general corporate shift toward short-term profits rather than AT&T's traditional long-term view. AT&T was far from alone in making this mistake, and research in the US has suffered greatly all over as a result. I remember visiting a couple of years after I left, and chatting with my former department head. He said 1127 was having trouble convincing new researchers to join up because they'd heard (correctly) that the physics and chemistry research groups were being cut back, and feared computing science would have its own reckoning soon enough. In fact the corporate direction of the time was to cut back on the physical sciences and push to expand software research and development, but I don't blame the new researchers for being concerned (nor did my ex-DH), and in the long term they turned out to be more right than wrong. Nothing lasts forever, but the classic Bell Labs lasted a long time. We have nothing like it now. I don't think we'll have anything like it any time soon. That's sad. Norman Wilson Toronto ON

4 years, 11 months

1
0
0 0

old Unix poster available

by Deborah Scherrer

I have an old "Unix Feuds" poster (image attached). Anyone want it? I'll ship (free) to any reasonable address. Deborah

4 years, 12 months

2
2
0 0

Re: [TUHS] Topics...

by Doug McIlroy

Preferring fewer emails, but not wanting to miss out on topics that had not occurred to me, I would continue to subscribe to the digest and not switch to a topic-filtering option. Doug

4 years, 12 months

1
0
0 0

Topics...

by Grant Taylor

On 7/6/20 7:30 PM, Greg 'groggy' Lehey wrote: > People (not just Clem), when you change the topic, can you please > modify the Subject: to match? I'm not overly interested in uucp, > but editors are a completely different matter. I'm sure I'm not the > only one, so many interested parties will miss these replies. I see this type of change happen — in my not so humble opinion — /way/ /too/ /often/. So, I'm wondering if people are interested in configuring TUHS and / or COFF mailing list (Mailman) with topics. That way people could subscribe to the topics that they are interested in and not receive copies of topics they aren't interested in. I'm assuming that TUHS and COFF are still on Mailman mailing lists and that Warren would be amicable to such. To clarify, it would still be the same mailing list(s) as they exist today. They would just have the to be utilized option of picking interesting topics. Where topics would be based on keywords in the message body. I'm just trying to gauge people's interest in this idea. -- Grant. . . . unix || die

4 years, 12 months

8
8
0 0

Re: [TUHS] v7 uucp debugging help requested

by Norman Wilson

Dave Horsfall: A boss of mine insisted that we all learned "ed", because one day it might be the only editor available to you after a crash; he was right... ==== Besides which, as The Blessed Manual said in every Research edition: ed is the standard text editor. Norman Wilson Toronto ON (typing this in Toronto qed)

4 years, 12 months

3
2
0 0

Re: [TUHS] Topics...

by norman＠oclsc.org

John Cowan: Very much +1. Part of the trouble is that Gmail and similar clients don't routinely show you the Subject: line to make it easy to edit it; you have to take affirmative action when you want to change the subject matter. ==== Perhaps we should take a leaf from 1980s Rob Pike, and just automatically change every message to be Subject: The content of this message (There is an actual story behind that, but I'll leave it to Rob to tell.) Norman Wilson Toronto ON

4 years, 12 months

1
0
0 0

VFS prior to 1984

by Paul Ruizendaal

When googling for File System Switch or Virtual File System most sources mention Sun NFS and SysVr3 as the earliest implementations. Some sources mention 8th Edition. I did a (short) search on FSS/VFS in earlier, non-Unix OS’s (Tenex, Multics, CTSS, etc.), but none of those seem to have had a comparable concept. Does anybody recall prior art (prior to 1984) in this area? Paul

4 years, 12 months

21
40
0 0

Fwd: Origins and life of the pg pager

by Warren Toomey

All, I just received this e-mail from a non-TUHS list member. If you have an answer for Michael, could you reply to him and pop a cc here as well? Thanks, Warren ----- Forwarded message from Michael Siegel <msi(a)malbolge.net> ----- Date: Sun, 14 Jun 2020 16:37:59 +0200 From: Michael Siegel <msi(a)malbolge.net> To: wkt(a)tuhs.org Subject: Origins and life of the pg pager Hi there, I'm trying to find out where the pg pager originated. The research I've done so far vaguely suggests it came with one of the System V versions, though Internet claims it to be “the name of the historical utility on BSD UNIX systems” occasionally.[1] I think System V because the source code of pg.c in the util-linux package says that this utility is “a clone of the System V CRT paging utility.”[2] I'd also like to find out when pg was discarded and if it ever made it into POSIX before that. Linux still has pg to the very day, but none of the current major BSDs (Free/Net/Open) offer it. POSIX 2001, 2004 Edition lists it as an excluded utility.[3] I've not been able to get the text of any prior POSIX documents. It seems they aren't freely available. Any ideas on how to proceed? Best Michael [1] This one's from Wikipedia (https://en.wikipedia.org/wiki/Pg_(Unix)) but I've also found other sites stating the same. [2] https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/text-ut… [3] https://pubs.opengroup.org/onlinepubs/009696899/xrat/xcu_chap04.html ----- End forwarded message -----

5 years

22
33
0 0

Re: [TUHS] s editor

by Paul Palmer

Could someone point me to some information about s editor? Googling didn't help On Fri, Jul 3, 2020, 9:00 PM <tuhs-request(a)minnie.tuhs.org wrote: > Send TUHS mailing list submissions to > tuhs(a)minnie.tuhs.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs > or, via email, send a message with subject or body 'help' to > tuhs-request(a)minnie.tuhs.org > > You can reach the person managing the list at > tuhs-owner(a)minnie.tuhs.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TUHS digest..." > > > Today's Topics: > > 1. v7 uucp debugging help requested (Adam Thornton) > 2. Re: v7 uucp debugging help requested (Clem Cole) > 3. Re: v7 uucp debugging help requested (Grant Taylor) > 4. Re: v7 uucp debugging help requested (John Cowan) > 5. Re: v7 uucp debugging help requested (Clem Cole) > 6. Re: v7 uucp debugging help requested (Clem Cole) > 7. Re: v7 uucp debugging help requested (Norman Wilson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 3 Jul 2020 13:52:42 -0700 > From: Adam Thornton <athornton(a)gmail.com> > To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> > Subject: [TUHS] v7 uucp debugging help requested > Message-ID: > <CAP2nic3UNxqi-obHwB5H+Ee+x5MKsd=eBrwhVbX+Ao3AgVPx= > g(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > (if this is better suited for COFF, that'd be fine too) > > I've been trying to set up UUCP on my V7 system and its raspberry Pi host. > This plus the "s" editor (already working) are really all that's needed to > make this something pretty close to a daily driver, if all I wanted to do > was write text files (which in some sense is all my job _is_, but to be > fair I get a much more immediate feedback loop in my current environment). > > I was following > > https://github.com/jwbrase/pdp11-tools/blob/master/howtos/V7%20UUCP%20Insta… > more or less--I had already rebuilt v7 with the DZ terminal driver and was > using it for interactive sessions (albeit, before I started trying to get > UUCP running, with 7-bit line discipline--but I've since changed that). > > I have 16 DZ lines, I've set them to 8-bit mode. They're working fine, > because I can use them for terminal sessions. > > I've built UUCP, set a node name, and set it up on the pi. > > I can execute uucico to send files, and it, frustratingly, almost works. > > >From the Pi side, I see (with uulog): > > uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP) > uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful > uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful (protocol > 'g' sending packet/window 64/3 receiving 64/7) > uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending > /home/adam/git/simh/sim_scsi.h (6780 bytes) > uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting for > packet > uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent 86, > resent 6, received 1 > uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0, > order 0, remote rejects 0 > uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds 5440 > bytes 19 bps) > > So it's clearly logging in, and if I telnet in directly, the v7 end is > starting uucico as expected: > > login: pi-uucp > Password: > Shere > > uulog -x on the v7 side has no output, and nothing ever appears in the > spool directory, which I suspect is a direct result of the timeout waiting > for packet. > > So my question is, what else do I do to debug this? Clearly the pi (Taylor > UUCP) side is expecting something else--maybe an acknowledgement?--from the > v7 side to let it know the transmission was successful. > > Any help would be appreciated. > > Adam >

5 years

1
1
0 0

Re: [TUHS] v7 uucp debugging help requested

by norman＠oclsc.org

Grant Taylor: I'm a little surprised that you're trying to use the 'g' protocol to talk to v7. I thought the 'g' protocol came out later for TCP over Ethernet connections. As such I wonder if UUCP on v7 supports the 'g' protocol. ===== You're mis-remembering. g was the original protocol, intended for use over possibly-noisy serial lines (e.g. modems on POTS). It does error checking of various sorts with retransmission. I believe it is named g after the protocol's original designer, Greg Chesson. Later protocols meant to work over reliable, error- checked links like a TCP/IP circuit were t and e. Norman Wilson Toronto ON

5 years

1
0
0 0

Bill Shannon RIP

by Matt Day

David Rosenthal has written a wonderful memorial of Bill Shannon: https://blog.dshr.org/2020/06/bill-shannon-rip.html

5 years

2
1
0 0

Re: [TUHS] VFS prior to 1984

by Paul Ruizendaal

Date: Wed, 24 Jun 2020 14:31:34 -0400 (EDT) From: norman(a)oclsc.org (Norman Wilson) > Reaching outside of UNIX, RSX/11 used external supervisor-mode processes called ACPs (ancillary control processes) to implement file systems. I don't know exactly how they were plugged in, but I do know they were pluggable, so their interface must have constituted a file-system switch of some sort. RSX dates back into the 1970s. At some point in the latter part of the 1980s, Ralph Stamerjohn (a name instantly recognizable in the 16-bit DEC software world) gave a DECUS talk about implementing a remote file system through ACPs: a stub ACP on the client exporting RPCs over the network, a real one at the server end. I remember chatting with him about how that did and didn't resemble the way pjw had done it; interesting architectural comparison. > Norman Wilson Toronto ON I am still digesting all the inputs (thanks, all!) The above post made me realise that the delineation of what is a FSS/VFS or not, is not so easy. I did a little bit of reading, and the concept of an ACP arrived with RSX11D in May 1973, but only matured in RSX11M in November 1974. As I understand it, originally in RSX11 file system code was closely tied to the low-level device driver for each device. ACP’s separated the file system code from the device driver itself, and became separate processes. In essence there were two switches: one switch into abstract devices, implemented in ACP code and one kernel switch to deal with hardware interfacing. The first is indeed like a file system switch (although still tied to specific devices). Looking at this stuff made me realise that my retro machine of choice (the TI990) went through a similar evolution. In the early seventies it had a sort of abstract device switch that linked to individual ‘device service routines’ (drivers). Initially, these modelled batch oriented ‘logical units’ that tied to files at the job control level. Later (late 70’s), the ‘open’ command would carry a file name and the file system was delegated to the device service routine. Still later (say 1983) this was used for networked disks. As several people have observed in this topic, indeed there appears to be a close relationship between a device switch and a file system switch.

5 years

3
4
0 0

Okistations and OKIX?

by Aaron J. Grier

Anybody on the list know much about the provenance of SVr4 and OKIX for the Okistation 7300 model 30? http://museum.ipsj.or.jp/en/computer/work/0029.html indicates that OKIX came later on the model 75, but many years ago as a staff programmer at Oregon Graduate Institute, a surplus 7300/30 followed me home, but the sysadmins referred to it as OKIX. if anybody's interested in the hardware to do some spelunking, email me off-list. -- Aaron J. Grier | "Not your ordinary poofy goof." | agrier(a)poofygoof.com "The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay." -- Tony Hoare

5 years

3
2
0 0

Mike Hawley has died

by Deborah Scherrer

Some very sad news: http://news.mit.edu/2020/michael-hawley-former-professor-media-arts-science…

5 years

1
0
0 0

Re: [TUHS] VFS prior to 1984

by jnc＠mercury.lcs.mit.edu

> From: Rob Gingell > RSEXEC (Resource Sharing EXEC) done on TENEX earlier in the 1970s. That was associated with the National Software Works project: https://apps.dtic.mil/dtic/tr/fulltext/u2/a132320.pdf I think? (It's been four decades since I looked at NSW, so I don't recall much about it.) Neither was TENEX-specific; e.g. there were Multics implementations of RSEXEC and NSW. Noel

5 years

4
3
0 0

Re: [TUHS] VFS prior to 1984

by jnc＠mercury.lcs.mit.edu

> From: Richard Salz > A web search for "its mldev" finds several things (mostly by Lars > Brinkhoff it seems) Yeah, other than the source: https://github.com/PDP-10/its/blob/master/src/sysen2/mldev.106 there's not a lot on it. That's typical of a lot of the innovative work done at the AI Lab, LCS, etc; they built some extraordinary tools, but to them they were just tools they used to work on their research, their _real_ work. So why bother to write that stuff up? So people who actually used them remember them, but other than that... Welcome to tomorrow, where everything gets re-invented, because everyone is too busy to waste time learning about the past. Noel

5 years

1
0
0 0

Re: [TUHS] VFS prior to 1984

by jnc＠mercury.lcs.mit.edu

> From: "Greg A. Woods" > as Organick said in his 1972 book A word of warning: i) Organick describes Multics as it was planned, not as it was actually implemented; and ii) then it changed considerably during its service life. Examples of each: i) there was one linkage segment per processs, not per segment (linkage info was copied across into the shared linkage segment when a segment was dynamically added to a process' address space); ii) the New Storage System. The basic concepts (single level store, dynamic linking etc) are correct in Organick, but be wary of anything past that. Not his fault, of course; things just changed. > As far as I can remember Multics didn't really have the concept of a > "mount point". In the original design, no. In 1973-75, with the New Storage System: https://multicians.org/nss.html mountable volumes were added (see MTB 229, "Use of Demountable Logical Volumes", linked from the page above). It was released to customers in June, 1976. Noel

5 years

1
0
0 0

Re: [TUHS] VFS prior to 1984

by norman＠oclsc.org

Reaching outside of UNIX, RSX/11 used external supervisor-mode processes called ACPs (ancillary control processes) to implement file systems. I don't know exactly how they were plugged in, but I do know they were pluggable, so their interface must have constituted a file-system switch of some sort. RSX dates back into the 1970s. At some point in the latter part of the 1980s, Ralph Stamerjohn (a name instantly recognizable in the 16-bit DEC software world) gave a DECUS talk about implementing a remote file system through ACPs: a stub ACP on the client exporting RPCs over the network, a real one at the server end. I remember chatting with him about how that did and didn't resemble the way pjw had done it; interesting architectural comparison. Norman Wilson Toronto ON

5 years

2
1
0 0

Re: [TUHS] VFS prior to 1984

by jnc＠mercury.lcs.mit.edu

> From: Anthony Martin > wherein they state the following: > A virtual file system, from the viewpoint of application programs on a > computer, models the file system functions of other computers. This is > done in the same way as with virtual terminals, a virtual file system > consists of a UPP having virtual files (VF), and a UCP which executes > virtual file system protocols. > I'd be interested if you find anything earlier. MLDEV on ITS would, I think, fit under that description. I don't know if there's a paper on it; it's mid-70's. Noel

5 years

3
2
0 0

Re: [TUHS] VFS prior to 1984

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > Ioctl: the Swiss Army knife of system calls. I thought it was a neat > idea when it arrived (much better then those primitive stty/gtty calls) > but now... Like they say, when the only tool you have is a hammer... Better syntax than stty/gtty, maybe but I'm not sure the semantics are that much better. The problem is that, especially with devices, what the I/O commands do is so widely varied that it's hard to fit them all under a unified umbrella. Maybe some (e.g. asynchronous I/O), but not all. Noel

5 years

2
1
0 0

Unix 8th / 9th edition IPC paper

by Paul Ruizendaal

There is an interesting paper that Dennis Ritchie and Dave Presotto wrote, “Interprocess Communication in the Ninth Edition Unix System” (https://www.bell-labs.com/usr/dmr/www/ipcpaper.html <https://www.bell-labs.com/usr/dmr/www/ipcpaper.html>). This appears to be an update of a paper that they wrote in 1985, “Interprocess Communication in the Eighth Edition Unix System”. This earlier paper is hard to find. Anybody on this list who has it on hand?

5 years

3
2
0 0

Re: [TUHS] VFS prior to 1984

by Norman Wilson

Rob Pike: For my taste, the various Unix file system switches that I've seen are too firmly tied to the idea of blocks and disks and all that, making them less flexible than they should have been. That's why the Plan 9 version is about names and byte streams, to make it as general as possible. ===== The only file-system switch I know well is that in the later Research systems. It has nothing to do with disks or blocks. It is about names and inodes: turn name to struct inode, read arbitrary chunk of data, write arbitrary chunk of data, create file, unlink file, abominable ill-defined system call that just wouldn't die erm I mean ioctl, and so on. It was certainly a cheap hack (as its author cheerfully admitted) but it really was about I/O operations, not about simulating disks. That's why it so easily supported /proc (the one that was just about processes, not the misnamed Linux one that is really about all things in the kernel so you don't need /dev/kmem). I don't know a lot about later VFSes like those in SunOS or Linux or the BSDs. Blockiness might well have crept in in support of memory-mapped I/O or in collaboration with the buffer-cache implementation. The Research version was never used directly to support different on-disk file system formats (we did a different pjw cheap hack for the one case that mattered in the kernel, and used the idea later developed more by FUSE for other cases because speed didn't matter). Norman Wilson Toronto ON

5 years

5
5
0 0

Re: [TUHS] Fwd: Origins and life of the pg pager

by jnc＠mercury.lcs.mit.edu

> From: Michael Siegel > there's no need to write out "less" every time. You can just alias that > to "pg" without causing any harm and save two letters, which is an > improvement for a task that is performed manually rather often. It always surpised me that there wasn't more of this - abbreviating the names of the most-used commands, to minimize typing - or more specifically, run-length encoding them based on how frequently they were used, with the most-used ones given the shortest names. The MIT-DSSR PWB1 system had a pager called just 'p' (source here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/p.c if anyone wants to see it; the man page is dated Apr/77); and 'ls' was tweaked to recognize the command name 'l' as an alias for 'ls -ls'. Of course, aliases didn't exist in the shell back then, which was why the command had to be coded to recognize the short form, and act differently. (And /bin/l was linked to /bin/ls.) 'l' and 'p' are _still_ aliased in my shell,to this day! > I hope it's okay that I chose to reply just to the list address and take > all the other addresses out. 'That's not a bug, that's a feature!' I always delete other addresses when replying to a list, unless I think someone might not be subscribed to that list. Noel

5 years

1
0
0 0

Jon Bentley's DFORMAT preprocessor now available

by Arnold Robbins

Hello All. I have reconstituted Jon Bentley's DFORMAT preprocessor (troff and awk source) and made it available on GitHub. See https://github.com/arnoldrobbins/dformat. This is an awk program that reads a description of data layouts, such as registers or network packets, and generates PIC descriptions. A Makefile generates PDF from the dformat.ms file using GNU troff. Jon Bentley was helpful in the final stages, including contributing his original files. Enjoy! Arnold Robbins

5 years

3
2
0 0

Dennis's list thesis is found

by Richard Salz

https://computerhistory.org/blog/discovering-dennis-ritchies-lost-dissertat…

5 years

2
1
0 0

2.9BSD-Seismo

by Warner Losh

So in BSD family tree, there's a 2.9BSD-Seismo and a 2.9.1BSD listed. Yet I can't seem to find them in the TUHS archive. There is a 2.9-Patch directory dated 1985 the same as the date that's found in the family tree. Is that the Seismo version? And Kirk's archive has a 2.9pucc directory, which appears appears to be from Purdue dated1987. How does this relate? Thanks for any help you can provide Warner

5 years

3
2
0 0

updated: loop networks at Bell Labs

by Paul Ruizendaal

With some further reading and research (and the kind help of Heinz Lycklama and Jon Steinart) I’ve found that my understanding of early loop networks at Bell Labs confused several different systems. As far as I can currently tell there were at least 4 different loop networks developed around 1970 at Murray Hill. 1. The first one is the “Newhall Loop” (paper published in 1969). This loop used twisted pair cabling, ran at about 3Mhz and used variable sized messages. It seems to have used some sort of token to coordinate between hosts. This might have been the network that Ken Thompson recalled as having been in operation when he arrived at the labs in 1966. 2. The second one appears to have been the “Pierce Loop”, as described in 3 BSTJ papers submitted in 1970/71. This one was coax based, used T1 compatible frames and was used to connect H516 computers with various bits of equipment. It seems to have had a very short life span. Part of my confusion was that the term Pierce Loop also appears to have been used in a generic sense to denote loop networks with fixed-sized frames. 3. The third one is the “Weller Loop” (paper published in 1971). This loop used coax cabling, ran at 3.3Mhz and used fixed 35 bit frames/cells. Each cell carried one address byte and two data bytes. One participant on the loop was the controller and effectively polled the other stations. In its 1971 form it appears to have been for the H516’s only and was referred to as a “Serial I/O bus”. This is what Jon Steinhart was talking about. The Weller loop was later redesigned (memo written in 1973) to interface with PDP-11’s as well. Heinz Lycklama used this loop in 1974 to connect several systems running (rump) Unix - see his paper about peripheral Unix here: https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-… <https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-…> This Serial I/O bus remained in use for several years at least. 4. The fourth and best known one is the “Spider Loop” (memo published in 1974, but operational from 1972). Twisted pair cabling, using T1 compatible frames. In use until about 1978. Main uses appear to have been the ‘nfs’ file store and the ‘npr’ remote printing service. My conclusion from all that is that in 1974 Unix had access to two networks, Spider and the Serial I/O bus. For both, first experiments would have been in 1973. It is hard to be sure which one came first. If I had to venture a guess today, I’d say that Spider connected to Unix several months before the Weller loop (even though the 1st generation Weller loop preceded Spider). Maybe the conclusion is that both happened more or less in parallel: Weller was also one of the designers of the Spider hardware.

5 years

2
1
0 0

Interesting problem

by Gregg Levine

Hello! I normally download items from the Society FTP site rather than from the archival area on the website. And my clients kept getting bounced, claiming that I should stop trying to connect frequently. Oddly enough that was not the case a while ago. Was the archive recently updated regarding hosting software? On Windows it was FileZilla, and spun down to one rather than eight or ten. And on the WSL SLES12 SP3 arrangement it was ncftp. Now downloading the reports to go along with the one Paul made available from the location is not important for today, I can wait until tomorrow or the next day. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

5 years

1
0
0 0

Re: [TUHS] Origins and life of the pg pager

by Norman Wilson

Rob Pike: Yeah, p is all we need. I think it originated with td at UofT. I might have brought it with me to Bell Labs, or recreated it. Probably the former. ==== The former, I think. The source code in V10 is very similar to that you left behind at Caltech (where I first encountered p). Most differences have to do with using opendir and readdir rather than reading raw directories in the SPname code. A further clue is that, even in V10, p.c begins /*%cc p.c pad.o spname.o */ The tool that looked for such lines to tell it how to compile things (I forget its name; was it comp?) doesn't seem to have survived in the archival backup I have from Caltech HEP, but I'm quite sure it came from U of T as well. Norman Wilson Toronto ON

5 years

3
2
0 0

Re: [TUHS] Origins and life of the pg pager

by Doug McIlroy

> less(1) was actually an improvement Hmm. Less is my favorite whipping boy for featuritis. % less --help |wc 242 1331 12202 I am very happy with p. Doug

5 years

7
8
0 0

v7 K&R C

by Adam Thornton

The C in v7 is, canonically, the language described in K&R, right? I must be doing something dumb. I am getting Webb Miller’s “s” editor built there, and I am down to one function. /* chop_arg - chop a function's argument to a maximum length */ static chop_arg(fcn, arg, maxlen) int (*fcn)(); int maxlen; char *arg; { char save; save = arg[maxlen]; arg[maxlen] = '\0'; fcn(arg); arg[maxlen] = save; } This doesn’t like the function pointer. $ cc -c choparg.c choparg.c:11: Call of non-function So, uh, what is the obvious thing I am missing? How am I supposed to be passing function pointers in the C compiler that comes with v7? Adam

5 years

27
62
0 0

Re: [TUHS] Accessing the PDP-11/70 MMU registers and the kernel's u area

by jnc＠mercury.lcs.mit.edu

> From: Diomidis Spinellis > From the 2.11 BSD sources I understand that the PDP-11/70 MMU address > and data registers, KDSA and KDSD, start at 0172360 and 0172320 > respectively ... Expressed as 16-bit addreses, on a PDP-11 with mapping disabled, yes. > I checked this by looking at /dev/mem. I don't know about 2.11, but in other PDP-11 Unixes, /dev/mem gives access to the actual CPU memory bus (which on a /34, etc, is the 18-bit address UNIBUS; on a /70 it's a separate 22-bit address bus). In the /70 memory address space, the 'I/O page' (which is where the PxR's live) is at the top end of it, i.e. the registers are at 017772360 (KDSAR0), etc. > What am I missing? PDP-11's have a plethora of address spaces, of different sizes. You need to always be aware of which one you're working in. > My goal is to access from the console the kernel's u area. According to > mem(4) and the symbols in /unix, this should be at address 0140000. In the kernel virtual address space, yes. > Indeed, accessing it through /dev/kmem I get the expected results for > e.g. u_comm and u_uid. Because /dev/kmem gives access to kernel address space for the _current_ process. > I have been unable to find it in the machine's physical memory By far and away the easiest thing, for the _current_ process, is to use /dev/kmem, which automagally applies the correct mapping. For other processes, if the process is swapped in, there's some field in the proc structure which says where in physical memory it us. IIRC, the user struct and the kernel stack are stored in the very bottom of that. (This article: http://gunkies.org/wiki/Unix_V6_dump_analysis#Memory_layouts goes into some detail for V6. Not sure how different 2.11 is; I know it uses one block of kernel address space to map in code overlays, but I don't know all the details of how it works.) Anyway, using that, one could read the user area in /dev/mem, at the appropriate location. For swapped-out processes, a similar algorithm applies, but you'll have to look in the swap device (obviously). Noel

5 years

3
2
0 0

Re: [TUHS] v7 K&R C [really lexers]

by Doug McIlroy

Interesting. My "speak" program had a trivial lexer that recognized literal tokens, many of which were prefixes of others, by maximum-munch binary search in a list of 1600 entries. Entries gave token+translation+rewrite. The whole thing fit in 15K. Many years later I wrote a regex recognizer that special-cased alternations of lots of literals. I believe Gnu's regex.c does that, too. (My regex also supported conjunction and negation-- legitimate regular-language operations--implemented by continuation-passing to avoid huge finite-state machines.) We have here a case of imperfect communication in 1127. Had I been conscious of the lex-explosion problem, I might have thought of speak and put support for speak-like tables into lex. As it happened, I only used yacc/lex once, quite successfully, for a small domain-specific language. Doug Steve Johnson wrote: I also gave up on lex for parsing fairly early. The problem was reserved words. These looked like identifiers, but the state machine to pick out a couple of dozen reserved words out of all identifiers was too big for the PDP-11. When I wrote spell, I ran into the same problem. I had some rules that wanted to convert plurals to singular forms that would be found in the dictionary. Writing a rule to recognize .*ies and convert the "ies" to "y" blew out the memory after only a handful of patterns. My solution was to pick up words and reverse them before passing them through lex, so I looked for the pattern "sei.*", converted it to "y" and then reversed the word again. As it turned out, I only owned spell for a few weeks because Doug and others grabbed it and ran with it.

5 years

1
0
0 0

Accessing the PDP-11/70 MMU registers and the kernel's u area

by Diomidis Spinellis

From the 2.11 BSD sources I understand that the PDP-11/70 MMU address and data registers, KDSA and KDSD, start at 0172360 and 0172320 respectively [1]. Yet, when I read the register contents I don't get what I would expect to see: increasing by 0200 memory values for KDSA and the same constant value for KDSD [2]. I checked this by looking at /dev/mem. # od -o /dev/mem 0172360 | head -1 0172360 000002 000016 001403 012700 000400 000402 012700 000200 # od /dev/mem 0172320 | head -1 0172320 101016 005064 000026 005067 175456 016467 000006 175430 I get the same results when I examine the memory through SIMH: sim> examine 172360 172360: 000002 sim> examine 172362 172362: 000016 sim> examine 172364 172364: 001403 sim> examine 172320 172320: 101016 sim> examine 172322 172322: 005064 The MMU kernel instruction registers, KISA and KISD, contain similarly nonsensical values as do the registers located at a different memory location (077320, 0772360) indicated in another source [3]. What am I missing? My goal is to access from the console the kernel's u area. According to mem(4) and the symbols in /unix, this should be at address 0140000. Indeed, accessing it through /dev/kmem I get the expected results for e.g. u_comm and u_uid. However, I have been unable to find it in the machine's physical memory, hence my question regarding the MMU's operation. [1] https://github.com/RetroBSD/2.11BSD/blob/master/usr/sys/pdpstand/M.s#L346 [2] https://github.com/RetroBSD/2.11BSD/blob/master/usr/sys/pdpstand/M.s#L247 [3] https://gunkies.org/wiki/PDP-11_Memory_Management Diomidis

5 years

1
0
0 0

non-blocking IO

by Paul Ruizendaal

This time looking into non-blocking file access. I realise that the term has wider application, but right now my scope is “communication files” (tty’s, pipes, network connections). As far as I can tell, prior to 1979 non-blocking access did not appear in the Spider lineage, nor did it appear in the NCP Unix lineage. First appearance of non-blocking behaviour seems to have been with Chesson’s multiplexed files where it is marked experimental (an experiment within an experiment, so to say) in 1979. The first appearance resembling the modern form appears to have been with SysIII in 1980, where open() gains a O_NDELAY flag and appears to have had two uses: (i) when used on TTY devices it makes open() return without waiting for a carrier signal (and subsequent read() / write() calls on the descriptor return with 0, until the carrier/data is there); and (ii) on pipes and fifo’s, read() and write() will not block on an empty/full pipe, but return 0 instead. This behaviour seems to have continued into SysVR1, I’m not sure when EAGAIN came into use as a return value for this use case in the SysV lineage. Maybe with SysVR3 networking? In the Research lineage, the above SysIII approach does not seem to exist, although the V8 manual page for open() says under BUGS "It should be possible [...] to optionally call open without the possibility of hanging waiting for carrier on communication lines.” In the same location for V10 it reads "It should be possible to call open without waiting for carrier on communication lines.” The July 1981 design proposals for 4.2BSD note that SysIII non-blocking files are a useful feature and should be included in the new system. In Jan/Feb 1982 this appears to be coded up, although not all affected files are under SCCS tracking at that point in time. Non-blocking behaviour is changed from the SysIII semantics, in that EWOULDBLOCK is returned instead of 0 when progress is not possible. The non-blocking behaviour is extended beyond TTY’s and pipes to sockets, with additional errors (such as EINPROGRESS). At this time EWOULDBLOCK is not the same error number as EGAIN. It would seem that the differences between the BSD and SysV lineages in this area persisted until around 2000 or so. Is that a fair summary? - - - I’m not quite sure why the Research lineage did not include non-blocking behaviour, especially in view of the man page comments. Maybe it was seen as against the Unix philosophy, with select() offering sufficient mechanism to avoid blocking (with open() the hard corner case)? In the SysIII code base, the FNDELAY flag is stored on the file pointer (i.e. with struct file). This has the effect that the flag is shared between processes using the same pointer, but can be changed in one process (using fcntl) without the knowledge of others. It seems more logical to me to have made it a per-process flag (i.e. with struct user) instead. In this aspect the SysIII semantics carry through to today’s Unix/Linux. Was this semantic a deliberate design choice, or simply an overlooked complication?

5 years

10
12
0 0

Unix V6: Assembler Listings

by Paul Ruizendaal

> I am now writing code in assembly for the PDP-11. I remember reading > somewhere that the output from "AS" (my caps) is a bit meagre. I can't find > an option to produce a text listing. Is it possible from AS, using command > options (I can't see one) or perhaps from "LD"? > > Paul > > *Paul Riley* I had the same problem. As I was porting to a different mini I had to write a new assembler. As you have undoubtedly seen, early ‘as’ was written in assembler and not so easy to use as a base. Hence I used Richard’s Miller’s AS for the Interdata as a base (available on Tuhs): https://www.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/source/as Later I discovered that the TUHS archive has source code for the original ‘as’ rewritten in C, a work by Roger Jaeger: https://minnie.tuhs.org/Archive/Distributions/USDL/Mini-Unix/ Maybe adding a listing module to this version of ‘as’ is another possible route.

5 years

2
1
0 0

Re: [TUHS] Unix V6: Assembler Listings

by Clem Cole

below... On Thu, Jun 11, 2020 at 9:04 AM Paul Riley <pdr0663(a)icloud.com> wrote: > Clem, > > Thanks for that. So this would compile on modern machines to a cross > compiler for V6 also running on a modern machine? I note you say macro11, > so not a Unix “as” style syntax, is that right? > Yes - the AT&T syntax was much simpler/less sugar than the DEC assembler. But the differences are pretty easy to see. IIRC that assembler generates DEC style linker objects and there is a companion linker that can create DEC binary objects (*i.e.* 'obj' files) as well as traditional UNIX a.out format. The entire tool suite was created originally to move code from RT-11 to UNIX at Harvard and passed around the nascent USENIX community. IIRC that version was forked from a BSD 2.x/NetBSD source repository and folks were adding some fields/features in the DEC obj format that RSX supported that RT-11 did not. Go hunting and see what you find. My memory was that with the BSD 2.x project, somebody added a DEC obj to UNIX binary (a.out) converter tool, so that you could use ld(1) instead of using the DEC style linker that had been included in the original. It has been >>years<< since I was really familiar with any of this stuff. A question about it came up last fall/winter on the simh mailing listing, which is where I found the the URL. FWIW: I offered the modern port, assuming you might want to run some of it as a cross-systems on a newer OS with a modern compiler. But if you are content running this on V6, then you might just want to go back to the original. As I said, my memory is that's in the original USENIX Harvard tape. All that should be Warner's archives if not other places on the Internet. Just remember that a big problem with the original code is that it will be written in pre-'White Book' C (that many of us learned years ago - not even ANSI of Second edition - this used Lesk's portable C library etc.). It sometimes looks a little strange to modern eyes. Also if you go looking, IIRC, someone at Harvard ported the DEC Macro RT-11 library to UNIX v6. In the late 1970s, I remember tjk, Danny Klein, Tron McConnell and I, plus some of the folks over in the bio-med group (whose names I have forgotten) had to a number assembler codes that had been written for the earlier RT-11 systems to Unix for one of the projects we had. Some of it got re-written in C, but I do remember we managed to use the Harvard assembler somehow for parts of it. If my memory is correct, early VMS and messing with BLISS compatibility could have been mixed up in the project somehow, but I've long forgotten the details of what we were doing at the time. Have fun.

5 years

2
1
0 0

Unix V6: Assembler Listings

by Paul Riley

Team, I am now writing code in assembly for the PDP-11. I remember reading somewhere that the output from "AS" (my caps) is a bit meagre. I can't find an option to produce a text listing. Is it possible from AS, using command options (I can't see one) or perhaps from "LD"? Paul *Paul Riley*

5 years

2
1
0 0

UNESCO's Software Heritage Foundation

by Clem Cole

I'm seeding this URL to TUHS as one would expect them to be interested in the work from Warren and friends. FWIW: I tried to browse their archives and was not impressed (I couldn't find anything). https://www.softwareheritage.org/

5 years

5
6
0 0

Re: [TUHS] History of popularity of C

by Doug McIlroy

> Steve Johnson's position paper on optimising compilers may amuse you: > https://dl.acm.org/doi/abs/10.1145/567532.567542 Indeed. This passage struck a particular chord: "I contend that the class of applications that depend on, for example, loop optimization and dead code elimination for their efficient solution is of modest size, growing smaller, and often very susceptible to expression in applicative languages where the optimization is built into the individual applicative operators." I don't know whether I saw that note at the time, but since then I've come to believe, particularly in regard to C, that one case of dead-code elmination should be guaranteed. That case is if(0), where 0 is the value of a constant expression. This guarantee would take the place of many--possibly even most--ifdefs. Every ifdef is an ugly intrusion and a pain to read. Syntactically it occurs at top level completely out of sync with the indentation and flow of text. Conversion to if would be a big win. Doug

5 years

6
5
0 0

History of popularity of C

by Tyler Adams

Does anybody have any good resources on the history of the popularity of C? I'm looking for data to resolve a claim that C is so prolific and influential because it's so easy to write a C compiler. Tyler

5 years

35
83
0 0

My BSDcan talk

by Paul Ruizendaal

> It's another similar to the last two. I've uploaded a version to youtube until the conference has theirs ready. It's a private link, but should work for anybody that has it. Now that I've given my talk it's cool to share more widely. > The link at the end is wrong. https://github.com/bsdimp/bsdcan2020-demos is the proper link. > Please let me know what you think. Watched it & liked it a lot! I have one nit-pick in the section on early networking: BBN's VAX TCP did not allow the ‘/dev/net/host’ syntax. That particular semantic comes from UoI’s NCP Unix, where the 8-bit host number was encoded in the minor number of character special file ‘host’ - but it did not carry through to the BBN code. Other systems used something similar. The Chaos network code made namei() break when it recognised the Chaos driver and left the remainder of the path for the driver to fetch & parse. I’m also being told that Greg Chesson experimented with using the given name of a Datakit channel device as the connection string for the switch, but that this approach was abandoned early on. In my view, exposing the host names through integration in the Unix file name space makes a lot of conceptual sense, but it unfortunately falls down on the practicalities, with the host name set being hard to enumerate (it is large, distributed and not stable - even back then). A question mark is hard pin-pointing the start of Unix networking to V4 / 1974. Yes, that is the earliest evidence we currently have. However, Sandy Fraser says that Spider came into operation in 1972 and it must have connected to something. Maybe that something was a lab-bench test setup, but it could have been a computer - maybe even one running Unix. There is another candidate for earliest Unix networking as well. The tech memo’s from Heinz Lycklama include one on the Glance terminal. That memo includes a section on the network used, referencing a 1973 report by D.R. Weller, "A High-Speed I/O Loop Communication System for the DEC PDP-11 Computer”. That computer appears to be an 11/45 running Unix and the loop is not Spider (nor the Pierce loop discussed in 1970/71 BSTJ). I have an off-list question outstanding to better understand this.

5 years

4
4
0 0

network name space (was: My BSDcon talk)

by Paul Ruizendaal

> On 6/6/20, Paul Ruizendaal <pnr at planet.nl > > wrote: > > > > In my view, exposing the host names through integration in the Unix file > > name space makes a lot of conceptual sense, but it unfortunately falls down > > on the practicalities, with the host name set being hard to enumerate (it is > > large, distributed and not stable - even back then). > > > With a proper dynamic VFS architecture, there is no reason why a > resolver with a filesystem API has to bother supporting enumeration at > all. All it needs to be able to do is respond to open() and stat() > calls, returning ENOENT when resolution fails. That is an intriguing thought. In Research Unix terms it would be a virtual directory that was not readable or writable, but still explorable (i.e. only the x bit set). Maybe enumeration is only impractical for the networks that were designed to be ‘large’, such as Arpanet and Datakit. It would have been feasible for contemporary networks that were designed to be local only, such as Chaosnet or ARCnet. A half-way house would be to only enumerate the local network and leaving everything else merely explorable. That is conceptually very messy, though.

5 years

1
0
0 0

Re: [TUHS] non-blocking IO

by jnc＠mercury.lcs.mit.edu

> From: Peter Jeremy <peter(a)rulingia.com> > My view may be unpopular but I've always been disappointed that Unix > implemented blocking I/O only and then had to add various hacks to cover > up for the lack of asynchonous I/O. It's trivial to build blocking I/O > operations on top of asynchonous I/O operations. It's impossible to do > the opposite without additional functionality. Back when I started working on networks, I looked at other kinds of systems to see what general lessons I could learn about the evolution of systems, which might apply to the networks we were building. (I should have written all that up, never did, sigh.) One major one was that a system, when small, often collapses multiple needs onto one machanism. Only as the system grows in size do scaling effects, etc necessitate breaking them up into separate mechanisms. (There are some good examples in file systems, for example.) I/O is a perfect example of this; a small system can get away with only one kind; it's only when the system grows that one benefits from having both synchronous and asynchronous. Since the latter is more complicated, _both_ in the system and in the applications which use it, it's no surprise that synchronous was the pick. The reasons why synchronous is simpler in applications have a nice illustration in operating systems, which inevitably support both blocking (i.e. implied process switching) and non-blocking 'operation initiation' and 'operation completed notification' mechanisms. (The 'timeout/callout' mechanism is Unix is an example of the latter, albeit specialized to timers.) Prior to the Master Control Program in the Burroughs B000 (there may be older examples, but I don't know of them - I would be more than pleased to be informed of any such, if there are), the technique of having a per-process _kernel_ stack, and on a process block (and implied switch), switching stacks, was not used. This idea was picked up for Jerry Saltzer's PhD thesis, used in Multics, and then copied by almost every other OS since (including Unix). The advantage is fairly obvious: if one is deep in some call stack, one can just wait there until the thing one needs is done, and then resume without having to work one's way back to that spot - which will inevitably be complicated (perhaps more in the need to _return_ through all the places that called down - although the code to handle a 'not yet' return through all those places, after the initial call down, will not be inconsiderable either). Exactly the same reasoning applies to blocking I/O; one can sit where one is, waiting for the I/O to be done, without having to work one's way back there later. (Examples are legion, e.g. in recursive descent parsers - and can make the code _much_ simpler.) It's only when one _can't_ wait for the I/O to complete (e.g. for a packet to arrive - although others have mentioned other examples in this thread, such as 'having other stuff to do in the meanwhile') than having only blocking I/O becomes a problem... In cases where blocking would be better, one can always build a 'blocking' I/O subsystem on top of asynchronous I/O primitives. However, in a _tiny_ system (remember my -11/40 which ran Unix on a system with _48KB_ of main memory _total_- i.e. OS and application together had to be less than 48KB - no virtual memory on that machine :-), building blocking I/O on top of asynchonous I/O, for those very few cases which need it, may not be the best use of very limited space - although I agree that it's the way to go, overall. Noel

5 years, 1 month

1
0
0 0

Unix on Aprpanet

by Paul Ruizendaal

>> On 2020, Jun 3, at 1:38 AM, Lars Brinkhoff <lars at nocrew.org> wrote: >> >> Lawrence Stewart wrote: >>> I remember working on getting Arpanet access on an 11/34 running V7 >>> around 1978 or 1979. (SU-ISL). We used an 11/23 as a front end to run >>> NCP, using a variation of Rand’s code. I wrote some sort of bisync >>> driver for packet communications between the /23 and the /34, and I >>> think added an IOCTL or some hack to ask if there was a message ready. >>> So a polling variety of non-blocking I/O :) >> >> Has this, or Rand's code, been preserved? >> >> I'm only aware of one Arpanet NCP implementation for Unix that is >> online, the one from University of Illinois. > Alas I do not know. I may have some old emails from that era. I will check. I have not so far come across an NCP Unix that was not based on the UoI code base. At a time there was a “Rand Unix”, that combined the UoI code with a few other extensions. A 1978 document describes the kernel as: "UNIX version 6 with modifications some of which are: - Accounting - A system call to write end of files on pipes - A system call which checks whether a process would sleep upon doing a read on either a pipe or tty - Pseudo teletypes - The network control program NCP written at the University of Illinois - A new method of interprocess communication called ports. Ports are similar to pipes but have names and can be accessed by any process.” The system call to write EOF on pipes is eofp() and the blocking read test is empty(). Both are available in the NCP Unix source code as included on the TUHS Unix Tree page. It could well be that the hack Lawrence refers to above was a modification to empty() to also cover his bisync driver. I guess empty() is the first step on the path that includes capac()/await() and later select()/poll() as the preferred mechanism to prevent blocking on IPC files (incl. tty’s).

5 years, 1 month

1
0
0 0

My BSDcan talk

by Warner Losh

OK. Must be off my game... I forgot to tell people about my BSDcan talk earlier today. It was streamed live, and will be online in a week or three... It's another similar to the last two. I've uploaded a version to youtube until the conference has theirs ready. It's a private link, but should work for anybody that has it. Now that I've given my talk it's cool to share more widely... https://www.youtube.com/watch?v=NRq8xEvFS_g The link at the end is wrong. https://github.com/bsdimp/bsdcan2020-demos is the proper link. Please let me know what you think. Warner

5 years, 1 month

1
0
0 0

Re: [TUHS] Looking for vi files from http://alf.uib.no/pub/vi

by arnold＠skeeve.com

Hi All. I've put Clem's file up at http://www.skeeve.com/text-processing.tar.bz2. It's a little over 16 meg and includes more than just the vi stuff. Enjoy, Arnold Michael Stiller <mstiller(a)icloud.com> wrote: > Hi Clem, > > why offline? Other people are also interested. :-) > > Cheers, > > Michael > > > > On 3. Jun 2020, at 14:33, Clem Cole <clemc(a)ccc.com> wrote: > > > > I think so... I'll send you a URL off line. > > > > Clem > > > > On Wed, Jun 3, 2020 at 1:14 AM <arnold(a)skeeve.com> wrote: > > Hi. > > > > Does anyone have a mirror of the files that once upon a time were > > at http://alf.uib.no/pub/vi? They were mirrored at > > ftp://ftp.uu.net/pub/text-processing/vi also. > > > > If so, can you please send me a tarball off list (or tell me where > > I can download a copy from)? > > > > Thanks! > > > > Arnold

5 years, 1 month

1
0
0 0

Re: [TUHS] non-blocking IO

by jnc＠mercury.lcs.mit.edu

> From: Paul Winalski > I'm curious as to what the rationale was for Unix to have been designed > with basic I/O being blocking rather than asynchronous. It's a combination of two factors, I reckon. One, which is better depends a lot on the type of thing you're trying to do. For many typical thing (e.g. 'ls'), blocking is a good fit. And, as As Arnold says, asyhchronous I/O is more complicated, and Unix was (well, back then at least) all about getting the most bang for the least bucks. More complicated things do sometimes benefit from asynchronous I/O, but complicated things weren't Unix's 'target market'. E.g. even though pipes post-date the I/O decision, they too are a better match to blocking I/O. > From: Arnold Skeeve > the early Unixs were on smaller -11s, not the /45 or /70 with split I&D > space and the ability to address lost more RAM. Ahem. Lots more _core_. People keeep forgetting that we're looking at decicions made at a time when each bit in main memory was stored in a physically separate storage device, and having tons of memory was a dream of the future. E.g. the -11/40 I first ran Unix on had _48 KB_ of core memory - total! And that had to hold the resident OS, plus the application! It's no surprise that Unix was so focused on small size - and as a corollary, on high bang/buck ratio. But even in his age of lighting one's cigars with gigabytes of main memory (literally), small is still beautiful, because it's easier to understand, and complexity is bad. So it's too bad Unix has lost that extreme parsimony. > From: Dan Cross > question whether asynchrony itself remains untamed, as Doug put it, or > if rather it has proved difficult to retrofit asynchrony onto a system > designed around fundamentally synchronous primitives? I'm not sure it's 'either or'; I reckon they are both true. Noel

5 years, 1 month

7
6
0 0

2.11BSD pl 0 recovered (mostly) PRELIMINARY

by Warner Losh

OK. I've written a script to take the 2.11BSD pl 195 tape and reverse apply all the patches that we have to get back to 2.11BSD original. There's some problems. The biggest one is that ld.c was rewritten during this series and what it replaced is lost. And the 2.10.1 ld.c isn't what's in 2.11BSD and the patches to get from 2.10.1 to 2.11 don't seem to be out there. And the other patches in the series make it clear that patches are missing. 2.11BSD likely will work with 2.10.1's ld, so this isn't fatal. There's 122 other files that I recovered from 2.10.1. Almost all of those are a good guess, if not what's actually in 2.11. Many of these can be verified via other means. Some of these can be snagged from comp.bugs.2bsd (that's how as was recovered). There's a number of small cosmetic changes made via copying, some to get rid of redundant files, etc. I think these don't matter for the function of the system, but are small differences from the actual tape that shipped. I still need to try to still create a tape and try to compile. And forward apply all the patches and create a git repo from it. All things considered 99% of the files have been recovered at this point. It's early days, but I've pushed this to github for comments. http://github.com/bsdimp/mk211bsd It just assumes you have the Tuhs archive (including the new Usenet section) and that apout works on your computer. It works on FreeBSD for sure. No clue about anything else... Warner

5 years, 1 month

1
0
0 0

non-blocking IO

by Paul Ruizendaal

> At around that point in time (I don't have the very _earliest_ code, to get an exact date, but the oldest traces I see [in mapalloc(), below] are from September '78), the CSR group at MIT-LCS (which were the people in LCS doing networking) was doing a lot with asynchronous I/O (when you're working below the reliable stream level, you can't just do a blocking 'read' for a packet; it pretty much has to be asynchronous). I was working in Unix V6 - we were building an experimental 1Mbit/second ring - and there was work in Multics as well. > I don't think the wider Unix community heard about the Unix work, but our group regularly filed updates on our work for the 'Internet Monthly Reports', which was distributed to the whole TCP/IP experimental community. If you can find an archive of early issues (I'm too lazy to go look for one), we should be in there (although our report will alsocover the Multics TCP/IP work, and maybe some other stuff too). Sounds very interesting! Looked around a bit, but I did not find a source for the “Internet Monthly Reports” for the late 70’s (rfc-editor.org/museum/ has them for the 1990’s). In the 1970’s era, it seems that NCP Unix went in another direction, using newly built message and event facilities to prevent blocking. This is described in "CAC Technical Memorandum No. 84, Illinois Inter-Process Communication Facility for Unix.” - but that document appears lost as well. Ah, well, topics for another day.

5 years, 1 month

11
18
0 0

Re: [TUHS] Looking for vi files from http://alf.uib.no/pub/vi

by Clem Cole

It is too big to attach to email. On Wed, Jun 3, 2020 at 8:39 AM Michael Stiller <mstiller(a)icloud.com> wrote: > Hi Clem, > > why offline? Other people are also interested. :-) > > Cheers, > > Michael > > > > On 3. Jun 2020, at 14:33, Clem Cole <clemc(a)ccc.com> wrote: > > > > I think so... I'll send you a URL off line. > > > > Clem > > > > On Wed, Jun 3, 2020 at 1:14 AM <arnold(a)skeeve.com> wrote: > > Hi. > > > > Does anyone have a mirror of the files that once upon a time were > > at http://alf.uib.no/pub/vi? They were mirrored at > > ftp://ftp.uu.net/pub/text-processing/vi also. > > > > If so, can you please send me a tarball off list (or tell me where > > I can download a copy from)? > > > > Thanks! > > > > Arnold > >

5 years, 1 month

1
0
0 0

Looking for vi files from http://alf.uib.no/pub/vi

by arnold＠skeeve.com

Hi. Does anyone have a mirror of the files that once upon a time were at http://alf.uib.no/pub/vi? They were mirrored at ftp://ftp.uu.net/pub/text-processing/vi also. If so, can you please send me a tarball off list (or tell me where I can download a copy from)? Thanks! Arnold

5 years, 1 month

2
1
0 0

non-blocking IO (morphing to "The serial I/O loop")

by Paul Ruizendaal

> On 5/31/2020 9:46 AM, Warner Losh wrote: > > Sorry to top post, but LSX or Miniunix had non blocking I/O as well. > > It was in one of the documents that Clem scanned in the last year. It > > specifically was an experiment into how to do it. > > > > Warner > I did add a few new features to LSX to deal with contiguous files > and to handle asynchronous read/write's for real time applications. > They are described in the LSX paper in the 1978 BSTJ on the > UNIX Time-Sharing System. > > Heinz Thanks for highlighting this! The realm here is async I/O to disk, my original scope was limited to “communication” files (tty’s, pipes, network connections). Still, I find it an interesting topic. For others, the paper that you refer to can also be found here: https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/UNI… If I read correctly, the async functionality was available only in the stand alone program version of LSX. Is that correct? In any case, the source code appears lost. From another paper in that set, I get the impression that the async functionality for LSX builds on earlier work for a very early version of Unix: https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-… - - - When reading through the papers in that TUHS directory, something else caught my attention: early networking at the labs. For a while I have been puzzled by the “serial I/O loop” in use at the labs in the early seventies. Last Fall I found some 1970/1971 BSTJ papers about it, but there it stopped. I see in the memo on Glance (https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-…) that D.R. Weller continued to work on it up to 1973 at least and that it was integrated with Unix in some way. Is that correct? Did the two memo’s referred to (MM 70-1384-1 and TM 73-1356-8) survive? Then the memo on satellite processors is very interesting (https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-…) This appears to show the serial I/O loop in use as late as 1978, with a very intriguing use case involving system call forwarding over the network. Can you tell me more about the serial I/O loop and its use cases?

5 years, 1 month

2
1
0 0

Re: [TUHS] mh/hm, mmh (was: fmt(1): history, POSIX, -t, -c)

by Bakul Shah

> Would you be so kind to explain a bit about the hm version of MH. Not sure what Clem meant but I used "hm" by Jim Guyton (@Rand) on my Fortune box until I retired it. It provided a 2D interface. Later I tried xmh but didn't like it. The early history of MH is covered in some detail in Willis Ware's "RAND and the Information Evolution" book from page 128 onward. hm & Guyton get a paragraph on page 136. https://www.rand.org/content/dam/rand/pubs/corporate_pubs/2008/RAND_CP537.p…

5 years, 1 month

2
1
0 0

DEC RL01/RL02 RX01/RX02 Disk Image Creator

by Paul Riley

Team Unix, Is there a Windows or Linux utility to create a disk image in any of the above formats, from a local folder tree? Paul *Paul Riley* Mo: +86 186 8227 8332 Email: paul(a)rileyriot.com

5 years, 1 month

6
13
0 0

non-blocking IO

by Paul Ruizendaal

> > when you're working below the reliable stream level, you can't just do a > blocking 'read' for a packet; it pretty much has to be asynchronous > Oh, you should look at the early BBN TCP for V6 Unix - they would have faced the same issue, with their TCP process. They did have the capac() call (which kind of alleviates the need for non-blocking I/O), but that may have only been available for ports/pipes; I'm not sure if the ARPANET device supported it. I did. There is capac() support also for the IMP interface: https://www.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/dmr/imp11a.c (see bottom two functions) BBN took the same approach as Research: with capac() or select() one can prevent blocking on read() and write().

5 years, 1 month

1
0
0 0

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

by jnc＠mercury.lcs.mit.edu

> From: Ronald Natalie > The V6 file system was limited to 2^24 blocks No, 2^16; from filsys.h: int s_fsize; /* size in blocks of entire volume */ and of course on an -11 an int is 16 bits. Maybe you're thinking of the file size, which was 2^24 bytes (max). Noel

5 years, 1 month

2
1
0 0

Re: [TUHS] non-blocking IO

by jnc＠mercury.lcs.mit.edu

> when you're working below the reliable stream level, you can't just do a > blocking 'read' for a packet; it pretty much has to be asynchronous Oh, you should look at the early BBN TCP for V6 Unix - they would have faced the same issue, with their TCP process. They did have the capac() call (which kind of alleviates the need for non-blocking I/O), but that may have only been available for ports/pipes; I'm not sure if the ARPANET device supported it. (With the NCP as well, that did some amount of demultiplexing in the kernel, and probably had buffering there, so, if so, in theory capac() could have been done there. Of course, with the ARPANET link being only 100Kbit/sec maximum - although only to a host on the same IMP - the overhead of copying buffered data made kernel buffering more 'affordable'.) Noel

5 years, 1 month

1
0
0 0

Re: [TUHS] non-blocking IO

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > This time looking into non-blocking file access. (... right now my > scope is 'communication files' (tty's, pipes, network connections). > ... > First appearance of non-blocking behaviour seems to have been with > Chesson's multiplexed files ... in 1979. At around that point in time (I don't have the very _earliest_ code, to get an exact date, but the oldest traces I see [in mapalloc(), below] are from September '78), the CSR group at MIT-LCS (which were the people in LCS doing networking) was doing a lot with asynchronous I/O (when you're working below the reliable stream level, you can't just do a blocking 'read' for a packet; it pretty much has to be asynchronous). I was working in Unix V6 - we were building an experimental 1Mbit/second ring - and there was work in Multics as well. I don't think the wider Unix community heard about the Unix work, but our group regularly filed updates on our work for the 'Internet Monthly Reports', which was distributed to the whole TCP/IP experimental community. If you can find an archive of early issues (I'm too lazy to go look for one), we should be in there (although our report will alsocover the Multics TCP/IP work, and maybe some other stuff too). There were two main generations of code; I don't recall the second one well, and I'm too lazy to go look, but I can tell you off the top of my head a bit about how the first one worked. Open/read/write all looked standard to the user in the process (the latter two were oriented to packets, a bit like raw disks being blocks); multiple operations could be queued in each direction. (There was only one user allowed at a time for the network device; no input demultiplexing.) Whenever an I/O operation completed, the process was sent a signal. Since the read/write call had long since returned, it had to do a getty() to get info about that operation - the size of the packet, error indications, etc. One complication was that for a variety of reasons (we wanted to avoid having to copy data, and the interface did not have packet buffers) we did DMA directly to/from the user's memory; this meant the process has to be locked in place while I/O was pending. (I didn't realize it at the time, but we dodged a bullet there; a comment in xalloc(), which I only absorbed recently, explains the problem. More here: https://gunkies.org/wiki/UNIX_V6_internals#exec()_and_pure-text_images if anyone wants the gory details.) That all (the queing, signals for I/O completion, locking the process to a fixed location in memory while it continued to run) etc all worked well, as I recall (although I guess it couldn't do an sbrk() while locked), but one complication was the UNIBUS map on the -11/70. The DSSR/RTS group at LCS wanted to have a ring interface, but their machine was a /70 (ours, the one the driver was initially done on/for, was a /40), so with DMA we had to use the UNIBUS map. The stock V6 code had mapalloc(), (and mapfree(), both called on all DMA operations), but... it allocated the whole map to whatever I/O operation asked for the map. Clearly, if you're about to start a network input operation, and wait a packet to show up, you don't want the disk controller to have to sit and wait for for a packet to show up so _it_ can have the map. Luckily, mapalloc() was called with a pointer to the buffer header (which had all the info about the xfer), so I added a 'ubmap' array, and called the existing malloc() on it, to allocate only a big enough chunk of the UNIBUS map for the I/O operation defined by the header. Since there was 248KB of map space, and the largest single DMA transfer possible in V6 was about 64KB (maybe a little more, for a max-sized process with its 'user' block), there was never a problem with contention for the map, and we didn't have to touch any of the other drivers at all. That was dandy, and only a couple of lines of extra code, but I somehow made a math error in my changes, and as I recall I had to debug it with a printf() in mapalloc(). I was not popular that day! Luckily, the error was quickly obvious, a fix was applied, and we were on our way. Noel

5 years, 1 month

1
0
0 0

DEC RL01/RL02 RX01/RX02 Disk Image Creator

by Paul Ruizendaal

> Team Unix, Is there a Windows or Linux utility to create a disk image in any of the above formats, from a local folder tree? Paul *Paul Riley* It seems you are asking for two tools in the BK-UNIX toolbox, fsutil and dskutil https://github.com/sergev/bkunix/tree/master/fsutil https://github.com/sergev/bkunix/tree/master/diskutil The first generates a Unix 6th edition file system from a local directory tree. The result is a binary file with the 512 byte disk blocks stored in sequence. Maybe this is what SIMH needs, I’m not into the details of SIMH. The second appears to be a tool to take the a file generated by the fsutil tool and split that into sectors and tracks. I’m not familiar with this tool, but it looks like you might need something similar (I assume that you have some way to hook up a 8” drive to your PC?). Sector interleaving may be an issue to look out for. When preparing a LSX system disk, you will need to think carefully about the layout: Presumably the disk works with 128 byte sectors and 4 sectors are grouped together to create a 512 byte unix block. Check out the disk driver code for details: https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/decfd.c Block 0 contains bootstrap code which is loaded/called from the monitor rom (or from a short code sequence keyed in on a “blinkenpanel” console). The filesystem itself starts at block 1 and runs up to a block N (you need to tell fsutil how big the filesystem needs to be). After block N up to the end of the disk is space to contain 2 swapped out programs plus 1 block for the return code of the third (default LSX has a maximum of 3 processes). You have to figure out how many 512 blocks are on your floppy and subtract out the swap space to arrive at a figure for N. In the LSX source code ’N’ is known as the define SWPLO, see param.h for details: https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/param.h In this file, 99 blocks are reserved for swap, corresponding to processes with 24KB memory; total disk size is defined as 500 blocks, 250KB - note that this slightly exceeds the 241KB offered by the standard IBM 77 track 26 sector formatting for 8” disks. Probably you will need to tweak the values in param.h Be careful with size units in the source code. Often sizes are expressed in words (2 bytes). Where memory is concerned it is often expressed in ‘clicks’, 64 bytes.

5 years, 1 month

2
1
0 0

LSX on the PDP-11/03 (LSI-11)

by Paul Riley

I've managed to acquire a PDP-11/03 with twin floppy drives (Sykes Datatronics RX01 or RX02 equivalents, not sure yet which). I've stumbled across LSX, and I have it running on SimH. I'm quite inexperienced with Unix, but it's something I want to learn well, having brushed against it at university in the '80s, and having played with Linux somewhat. I have some interest in Forth, but I don't like the block system of early forths such as FigForth, and I plan to create a new Forth based on FigForth, but supporting external source files. Anyway, I've tried compiling Hello World on LSX, and I get "1: External definition syntax" error. Some help would be nice, but more generally, is anyone on this list more than vaguely familiar with LSX, or 6th Edition itself? void main () { printf("Hello World!"); } It seems that the 7th Edition was the beginning of the standard library in C, and that this is missing in LSX. I'm not sure if printf is an intrinsic function in (6th Edition) C, or if it's from a library. My questions are a bit random, but looking to converse with others with LSX experience. Paul *Paul Riley* Email: paul(a)rileyriot.com

5 years, 1 month

4
3
0 0

DEC RL01/RL02 RX01/RX02 Disk Image Creator

by Paul Ruizendaal

> > In this file, 99 blocks are reserved for swap, corresponding to processes with 24KB memory; total disk size is defined as 500 blocks, 250KB - note that this slightly exceeds the 241KB offered by the standard IBM 77 track 26 sector formatting for 8” disks. Probably you will need to tweak the values in param.h Oops: 77 tracks by 26 sectors of 128 bytes, makes 250.25KB, so it should work as configured.

5 years, 1 month

1
0
0 0

fmt(1): history, POSIX, -t, -c

by markus schnalke

Hoi, personally I use fmt(1) a lot for email formatting and such. Typically I only use the `-w' parameter. Now someone asked me about `-t' and `-c' of *GNU* fmt(1). I wasn't able to find good documentation on them. The manpage only tells that they have to do with different indentation for the first or first two lines. But what are the use cases? How would source text for these parameters look like? A look into the description and rationale sections of POSIX, which often provides helpful information, was not possible because fmt(1) is not part of POSIX (only fold(1) is). Why's that? Is it because fmt(1) differs so much between Unix implementations? On BSD `-c' centers text and `-t' sets tab widths. Plan 9 has none of these options. But still, `-w' could have been standardized. Or was the line filling algorithm different as well? How does fold(1) fit into the picture? Maybe you can answer some of these questions or give hints on where I could find answers myself. meillo

5 years, 1 month

13
28
0 0

LSX on the PDP-11/03 (LSI-11)

by Paul Ruizendaal

> I've stumbled across LSX, and I have it running on SimH. I'm quite inexperienced with Unix, but it's something I want to learn well, having brushed against it at university in the '80s, and having played with Linux somewhat. I think you will experience a sizeable learning curve. You will be working with Unix and C as it stood around 1975 and that is substantially different from what it was in the 80’s. That said, I know from personal experience that it is an intriguing journey and certainly not impossible to do. > Some help would be nice, but more generally, is anyone on this list more than vaguely familiar with LSX, or 6th Edition itself? Many on this list are familiar with 6th edition. The best way to learn the internals of 6th edition is the “Lions’ book”: https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980137 Coming from today’s perspective (or a 1980’s one), you will find the following key challenges: - The version of C used for 6th edition is different from the 1980’s. Amongst other things the syntax of the assignment operators changed (not += but =+), the syntax for initialisation changed (not 'int a = 3', but 'int a 3’), the ‘long’ datatype (32 bit on a PDP-11) did not exist, the ‘void’ keyword did not exist, structs could not be assigned, passed or returned (only pointers to structs), etc. - The stdio library did not exist yet, in its place there was the ‘portable i/o library’. This may be the hardest part to get used to. - The file system was 16-bit based throughout. This has implications for stat(), lseek() did not exist (its precursor seek() used additional whence values to move the file pointer in 512 byte increments), etc. When it comes to LSX, there are a few people who have experience with it on the this list (that I know of - there may be many more). First of all, Heinz Lycklama, the original creator of LSX, appears to read this list from time to time. Second, Leonid Broukhis and Serge Vakulenko (who managed to recover the LSX sources 20 years ago) might be reading the list. They took the trouble to port LSX to the Soviet BK-0010 computer, an LSI-11 type system some 15 years ago: https://github.com/sergev/bkunix You can stand on their shoulders, as they already took the trouble to convert the kernel source from 1975 C to 1980’s C and to create a stdio compatible library for it; they are using the 2.11BSD C compiler, which generates tighter code than the 1975 compiler — hence they could squeeze a bit more functionality in. Third, I found the BK-0010 port some 5 years ago and used that as base to create a version that would run on a small TI990 clone: http://www.stuartconner.me.uk/mini_cortex/mini_cortex.htm This work later evolved into a stock 6th edition kernel and is now a curious mix of stuff dating from 1975 to 1985. Your main challenge will be that neither the BK-0010 work nor my work will run on your hardware as-is. I think you have two possible paths forward. The first is to learn C and the library as it stood in 1975, the second is to take the BK-0010 code and to make it run on a stock LSI-11 again.

5 years, 1 month

1
0
0 0

Re: [TUHS] fmt(1): history, POSIX, -t, -c

by Doug McIlroy

The title of the fmt man page in v9 was "ultra-simple text formatter". Gnu dropped the "ultra" in favor of AI. Sometimes it does a pretty job. Sometimes it messes up my typing style. Always it produces a an apparently wavering right margin, as it assigns a separate "optimal" line length to each paragraph. It's hard to imagine how this command could stray from classic Unix simplicity and intelligibility, but Gnu pulled it off. Doug

5 years, 1 month

1
0
0 0

Sad Times - hopefully this is just temporary

by Clem Cole

https://www.livingcomputers.org/Closure.aspx

5 years, 1 month

1
0
0 0

main

by Steve Simon

re: main. i was surprised not to see any mention of the entry keyword reserved but, i believe, never used in early c. it is listed in k&r ed1. i always assumed this was to allow the author to choose an alternative to main() for the program’s entry point, but we all know what assumption is... -Steve

5 years, 1 month

3
2
0 0

Re: [TUHS] History of popularity of C

by jnc＠mercury.lcs.mit.edu

> From: Tyler Adams > C is so prolific and influential because it's so easy to write a C > compiler. I'm not sure the implied corollary ('it's _not_ easy to write compilers for other languages') is correct. As a datapoint, I pulled "Algol 60 Implementation" (Randell and Russell) off the shelf, and it reveals that the Algol 60 compiler discussed there (for the KDF9), using lessons from the Algol compiler for the Electrologica X1, was 3600 words (roughly 3 instructions/word). So it was small. Now, small is not necessarily equivalent to easy, but it was clearly not a mountainous job. I imagine early BCPL, etc compilers were roughly similar. The only language from that era which I can think of which was a slog, compiler-wise, was PL/I. I suspect the real reason for C's sucess was the nature of the language. When I first saw it (ca. 1976), it struck me as a quantum improvement over its contemporaries. Noel

5 years, 1 month

11
16
0 0

where did "main" come from?

by Lawrence Stewart

C main programs define “main”. This also seems to be true of B main programs, according to the Johnson/Kernighan manual The 1967 Martin Richards BCPL manual doesn’t explain how programs get started The 1974 update from Martin Richards says there should be an OS addendum that explains this. The 1974 University of Essex BCPL manual says to use START The 1979 Parc Alto BCPL manual uses Main and I think that must be unchanged from 1972. The AMSTRAD BCPL guide from 1986 uses start() So who started “main” and when? I can’t find an online copy of the Bell Laboratories BCPL manual (Canaday/Thompson) from 1969 or anything about how to use BCPL on Multics or CTSS. -L

5 years, 1 month

7
6
0 0

Re: [TUHS] TUHS] where did "main" come from?

by Nelson H. F. Beebe

Lawrence Stewart <stewart(a)serissa.com> asks on Fri, 22 May 2020 14:43:40 -0400: >> So who started "main" and when? I have just checked several PDFs of IBM mainframe and Fortran manuals going back to 1954. The early manuals did not appear to use the name "main", but in ibm-7030/C22-6578_7030_Programming_Examples_Apr61.pdf, the phrase "the main program" occurs in the context of assembly language coding. In ibm-7030/C22-6751_7030_FORTRAN_IV_May63.pdf, on page 22, which begins with Part II. FORTRAN Programming for the IBM 7030 the first paragraph ends with "the main program". In silliac/SPMpart1-ocr.pdf, titled Silliac Programming Manual The Adolph Basser Computing Laboratory School of Physics The University of Sydney and dated January 1959, on page 99, I find >> ... >> In this way a program is seen to consist of several distinct, >> self-contained blocks, namely the various subroutines and the part of >> the program (usually called the main program or master routine) which >> ^^^^^^^^^^^^^^^^ >> makes use of its subroutines by sending control to them. >> ... I have many manuals for older systems, but most have not been subjected to optical-character recognition, so it is difficult to find specific text in them. Nevertheless, I have demonstrated that by at least January 1959, the phrase "main program" was common enough to appear in computer documentation, qualified by "usually". Some day, perhaps I'll find time to do OCR conversion on my extensive PDF file archives. I'll be pleased to hear of earlier uses of "main program" from TUHS list members. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

5 years, 1 month

1
0
0 0

Re: [TUHS] BBN technical reports?

by Paul Ruizendaal

> I went looking for the three IPC reports: > > For more information about this system, see: > - "Interprocess Communication Extensions for the UNIX Operating System: I - > Design Considerations", Rand Corporation, Report R-2064/1-AF, June 1977. > - "Interprocess Communication Extensions for the UNIX Operating System: II > - Implementation", Rand Corporation, Report R-2064/2-PR, April 1977. > - "UNIX TCP User's Guide", Bolt Beranek and Newman Inc., Report No. 3724 > > > And could only find the first one online at > > https://apps.dtic.mil/dtic/tr/fulltext/u2/a044200.pdf > > Do we have the other two anywhere? Yes we do. The first two are about Rand ports. You’ve found the overview by Carl Sunshine, the implementation by Steve Zucker is the next report up on DTIC: https://apps.dtic.mil/sti/pdfs/ADA044201.pdf The TCP User guide report you refer to is about a TCP implementation done by Jack Haverty, which took an implementation in PDP-11 assembler and wrapped it in a NCP Unix shell. Jack has a listing in his attic, but it is not scanned. The problem with this implementation was that it is was all very cramped in the kernel, so he had to reduce disk buffers substantially. As pipes (and Rand ports) use disk buffers to hold pipe data, which get swapped out to disk as needed, he found that his system trashed a lot and effective TCP speeds in his first trials were barely above few dozen byte per second. The report is actually on the TUHS tree: https://www.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/doc (there is also nroff source for Steven Zucker’s report, and other interesting material in that directory - such as a report on pipe performance). The actual V6 implementation that is on that THUS page is not Jack Haverty’s version, but a version done from scratch by Mike Wingfield, using the learning’s of Jack’s work. Mike’s implementation worked quite well and won first prize in a March 1979 tongue-in-cheek TCP4 conformance & interop competition. The BBN report for that version is 4295. Craig Partridge was kind enough to dig it up from the BBN library - I can send you a copy if you like (it was cleared for public release). Although the implementation was done for research purposes (mainly Autodin II security features and simulation), it seems to have had a long life as a stop-gap to keep aging PDP-11’s connected after the switch from NCP to TCP in 1983. Paul

5 years, 1 month

1
0
0 0

BBN technical reports?

by Warner Losh

I went looking for the three IPC reports: For more information about this system, see: - "Interprocess Communication Extensions for the UNIX Operating System: I - Design Considerations", Rand Corporation, Report R-2064/1-AF, June 1977. - "Interprocess Communication Extensions for the UNIX Operating System: II - Implementation", Rand Corporation, Report R-2064/2-PR, April 1977. - "UNIX TCP User's Guide", Bolt Beranek and Newman Inc., Report No. 3724 And could only find the first one online at https://apps.dtic.mil/dtic/tr/fulltext/u2/a044200.pdf Do we have the other two anywhere? Warner

5 years, 1 month

1
0
0 0

Re: [TUHS] Chaos networking in 8th edition (and in 7th)

by Doug McIlroy

>> I don't recall any use of Chaos in 1127. Possibly one of >> the nearby groups who also used the Research system needed >> it at some point > Speculating wildly, maybe there was a Lisp machine somewhere? None that I can remember. Doug

5 years, 1 month

10
9
0 0

Re: [TUHS] algebraic syntax (was v7 K&R C)

by Doug McIlroy

> for some years I've been using the phrase "algebraic syntax" to > characterize languages such as Algol, C/C++, Fortran, Java(Script), Ruby, etc. ... > However, I can't find this usage in Wikipedia or elsewhere I think "Algol-like" is the closest term in common use, though it doesn't have the exact connotation that I think you intend. Nowadays, I think of languages like Haskell as being "algebraic" in the deeper sense of having taken much inspiration from modern algebra, and being preeminently suitable for application to algebraic domains. Vic Vyssotsky used the term "narrative language" as quite a close synonym of your "algebraic syntax", but I think his usage was equally idiosyncratic. Doug

5 years, 1 month

1
0
0 0

Re: [TUHS] v7 K&R C

by Doug McIlroy

> o operator overloading > > I never could figure out why Stroustrup implemented that "feature"; let's > see, this operator usually means this, except when you use it in that > situation in which case it means something else. Now, try debugging that. Does your antipathy extend to C++ IO and its heavily overloaded << and >>? The essence of object-oriented programming is operator overloading. If you think integer.add(integer) and matrix.add(matrix) are good, perspicuous, consistent style, then you have to think that integer+integer and matrix+matrix are even better. To put it more forcefully: the OO style is revoltingly asymmetric. If you like it why don't you do everyday arithmetic that way? I strongly encouraged Bjarne to support operator overloading, used it to write beautiful code, and do not regret a bit of it. I will agree, though, that the coercion rules that come along with operator (and method) overloading are dauntingly complicated. However, for natural uses (e.g. mixed-mode arithmetic) the rules work intuitively and well. Mathematics has prospered on operator overloading, and that's why I wanted it. My only regret is that Bjarne chose to set the vocabulary of infix operators in stone. Because there's no way to inroduce new ones, users with poor taste are tempted to recycle the old ones for incongruous purposes. C++ offers more features than C and thus more ways to write obscure code. But when it happens, blame the writer, not the tool. Doug

5 years, 1 month

17
23
0 0

Re: [TUHS] 2.11bsd boot countdown stuck at <5> on 11/73

by jnc＠mercury.lcs.mit.edu

> From: Jacob Ritorto > I had a suspicion that maybe the clock isn't working on the 11/73. > Would that make sense? Would definitely explain the symptoms. > Maybe I have to check jumpers on the 11/73 to be sure its clock is > enabled? There is a jumper on the KFJ11-A that enables/disables the clock&register; W9 (closest to the handles) should be removed to enable the clock. (I really need to add the jumpers to the KDJ11-A page on the Computer History Wiki, mumble....) Noel

5 years, 1 month

2
1
0 0

PiDP

by ron＠ronnatalie.com

I bought one of Oscar's kits a while back and I just got around to putting it together. It was kind of neat booting up a straight V6 (it's been a long time) and playing with those DEC operating systems that I had learned to hate (Really Sh-ty Timesharing System). I had hoped that someone, somewhere had a JHU/BRL dist around (well if you do, I'd love to get it). But since the thing is mostly just a decoration in my office, I just hacked the idle function in 2.11 BSD to mimic the one that JHU Unix had.

5 years, 1 month

2
1
0 0

2.11bsd boot countdown stuck at <5> on 11/73

by Jacob Ritorto

Hi, I had a disk in my 11/83 that I'd set up for autoboot. The pdp11 would load block 0, load /boot and happily count down 5 seconds, then continue on with kernel loading & regular bringing up of the system to multiuser. That was cool! So I pulled that disk out and plugged it into my other system with a dual height 11/73 (this system has same CMD CQD-200 scsi controller) and it gets to the countdown part and stops! I'm wondering why. The initial bootblock load is apparently fine and loading and running of boot is happening.. its just that the countdown stays stuck at five and I have to hit <cr> to get it to boot (and the rest of the boot sequence is totally normal). I had a suspicion that maybe the clock isn't working on the 11/73. Would that make sense? Maybe boot is actually using a clock somehow? Maybe I have to check jumpers on the 11/73 to be sure its clock is enabled? Just thought I'd float the question here in case someone remembers this oddity before I start digging / "use the source." thx jake

5 years, 1 month

1
0
0 0

Re: [TUHS] v7 K&R C

by jnc＠mercury.lcs.mit.edu

There was a recent message I now can't find that I wanted to reply to, something about which type to use to get a certain effect. I wanted to reply to say that I felt that it was not really the best way to go, to have one set of type names that tried to denote both i) the semantics of the data, and ii) the size of the item, using arbitrary names. This came up for me when we started to try and write portable networking code. There, you need to be able to specify very precisely how long fields are (well, in lower-level protocols, which use non-printable formats). How to do that in a way that was portable, in the compilers of the day, was a real struggle. (It might be doable now, but I think the fixes that allowed it were still just patches to something that had gone in the wrong direction, above.) I created a series of macros for type definitions, ones that separately and explicitly specified the semantics and size. They looked like 'xxxy', where 'xxx' was the semantics (signed and unsigned integers, bit field, etc), and 'y' was a length indication (byte, short, long, and others). So you'd see things like 'unsb' and 'intl'. The interesting twist was a couple of unusual length specifiers; among them, 'w' stood for 'the machine's natural word length', and 'f' meant 'no particular length, just whatever's fastest on this architecture/compiler, and at least 16 bits'. The former was useful in OSy type code; the latter for locals and things where nobody outside the machine would see them. Then you'd have to have a file of macro definitions (only one per machine) which translated them all into the local architecture/compiler - some didn't go, of course (no 'unsb' on a PDP-11), but it all worked really, really well, for many years. E.g. at one point, as a dare/hack, I said I'd move the MOS operating system, a version written in portable C (with that type name system) to the AMD 29000 over one night. This wasn't totaly crazy; I'd already gotten the debugger (a DDT written in similar portable C) to run on the machine, so I knew where the potholes were. I'd have to write a small amount of machine language (which I could traslate from the M68K version), but most of it should just compile and go. I didn't quite make it, it wasn't quite running when people started coming in the next morning; but IIRC it started to work later that day. Noel

5 years, 1 month

1
0
0 0

Re: [TUHS] v7 K&R C

by Richard Tobin

> Isn't it nonstandard (although I am aware of some compilers that do it) to > default the type of char to unsigned? No. "The implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char." - C99 (Technically it's a separate type from both of them.) -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

5 years, 1 month

15
20
0 0

Chaos networking in 8th edition (and in 7th)

by Norman Wilson

Paul Ruizendaal: Was Chaos networking in use at the labs, or is it just an artifact present on the surviving tape? === I don't recall any use of Chaos in 1127. Possibly one of the nearby groups who also used the Research system needed it at some point, perhaps before my time (I arrived in August 1984). I certainly don't remember anyone raising objections to discarding it. Norman Wilson Toronto ON

5 years, 1 month

2
1
0 0

Re: [TUHS] v7 K&R C

by Doug McIlroy

> [A]lthough these days "byte" is synonymous with "8 bits", historically it > meant "the number of bits needed to store a single character". It depends upon what you mean by "historically". Originally "byte" was coined to refer to 8 bit addressable units on the IBM 7030 "Stretch" computer. The term was perpetuated for the 360 family of computers. Only later did people begin to attribute the meaning to non-addressable 6- or 9-bit units on 36- and 18-bit machines. Viewed over history, the latter usage was transient and colloquial. Doug

5 years, 1 month

2
1
0 0

Re: [TUHS] v7 K&R C

by Doug McIlroy

I should have checked my 7030 manual before asserting that the 8-bit byte came from there. The term did, but it meant an addressable unit of 1 to 8 bits depending on the instruction being executed. [The machine was addressable to the bit. It also had all 16 bitwise logical operators, and maintained counts of the 1 bits and leading 0 bits in a register. And it was BIG. I saw one with 17 memory boxes (each essentially identical with the total memory of a 7090) stretched across the immaculate hardwood floor of IBM's Poughkeepsie plant.] Doug

5 years, 1 month

2
1
0 0

Chaos networking in 8th edition (and in 7th)

by Paul Ruizendaal

The surviving 8th edition source has code for Chaos networking included: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys <https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys> It does not appear to be included in the man pages. Was Chaos networking in use at the labs, or is it just an artifact present on the surviving tape? Related to that, I’m interested in the Chaosnet implementation for 7th edition. Dave Moon's Chaosnet memo includes this intriguing sentence when talking about the V7 implementation: “The NCP is entirely implemented in the kernel as a device driver”. I could not find that source code in the TUHS archive, nor on Kirk McKusick’s DVD. Does anybody happen to have it?

5 years, 1 month

1
0
0 0

Re: [TUHS] v7 K&R C

by Doug McIlroy

They are flagging non-portable usage.

5 years, 1 month

1
0
0 0

Re: [TUHS] v7 K&R C

by Nelson H. F. Beebe

Discussions today on the TUHS list about the signed/unsigned nature of the C char type led me to reexamine logs of my feature test package at http://www.math.utah.edu/pub/features/ I had 170 build logs for it from 2017.11.07, so I moved those aside and ran another set of builds in our current enlarged test farm. That generated another 361 fresh builds. Those tests are all with the C compiler named "cc". I did not explore what other C compilers did, but I strongly suspect that they all agree on any single platform. On all but THREE systems, the tests report that "char" is signed, with CHAR_MAX == +127. The three outliers have char unsigned with CHAR_MAX == +255, and are * ARM armv7l Linux 4.13.1 (2017) and 5.6.7 (2020) * SGI O2 R10000-SC (150 MHz) IRIX 6.5 (2017 and 2020) * IBM POWER8 CentOS Linux release 7.4.1708 (AltArch) (2017) So, while the ISO C Standards, and historical practice, leave it implementation dependent whether char is signed or unsigned, there is a strong majority for a signed type. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

5 years, 1 month

6
6
0 0

QED with Unicode support

by arnold＠skeeve.com

Hello All In case this is of interest: > Date: Sat, 16 May 2020 12:18:15 +0100 > Subject: qed-archive (Github) > To: arnold(a)skeeve.com > > Hi Arnold > > Apologies for an un-solicited email. > > I have ported Rob's UofT QED from your qed-archive/unix-1992 to Linux > (although I suspect anything with a Unix API will work), and have updated > it to work completely in UTF8/Unicode. This includes correct handling of > unicode codepoints in regexes, subs, etc. > > It's up on Github under phonologus/QED. I thought you might want to add it > to your list of QED-s in your README, as it may be of interest to the other > three connoisseurs out there...! > > I have also included typeset pdf-s of the tutorial and manpage. The > tutorial is fascinating. > > Also, there is no clear statement about copyright, or license, of the > unix-1992 tarball. I have attributed it to Rob, and I have noted that I > scavenged it from your Github repo, but was wondering if there is any > definitive statement on ownership/authorship that I could include in my > repo? > > Best wishes

5 years, 1 month

2
1
0 0

Re: [TUHS] v7 K&R C [really lexers]

by Nelson H. F. Beebe

Brantley Coile <brantley(a)coraid.com> wrote on Sun, 17 May 2020 01:36:16 +0000: >> It looks like only grap and pic have mkfiles that invoke lex. Both of those are Brian Kernighan's work, and from the FIXES file in his nawk, I can offer this quote: >> ... >> Aug 9, 1997: >> somewhat regretfully, replaced the ancient lex-based lexical >> analyzer with one written in C. it's longer, generates less code, >> and more portable; the old one depended too much on mysterious >> properties of lex that were not preserved in other environments. >> in theory these recognize the same language. >> ... ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

5 years, 1 month

1
0
0 0

Re: [TUHS] v7 K&R C

by Richard Tobin

> The function prototype for getchar() is: int getchar(void); > > It returns an int, not a char. In all likelihood this is specifically > *because* EOF is defined as -1. It would have probably returned int anyway, because of the automatic promotion of char to int in expressions. It was natural to declare functions returning char as int, if you bothered to declare them at all. As K&R1 said: Since char promotes to int in expressions, there is no need to declare functions that return char. Similarly functions that might return short or float would normally return int or double; there aren't separate atof and atod functions for example. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

5 years, 1 month

2
1
0 0

11/40 CPU (Emulation) test programs still available somewhere

by Michael Stiller

Hi Legends, during corona times i “ported” Dave Cheney’s avr11 PDP11/40 emulator to a Teensy 4 MCU board, fixed already some bugs in it and added multiple rk drives and a partially working tm emulation. (space forward/reverse unimplemented) It runs V6 at about 1 Mips and is completely fine usable with multiple rk and tm drives. Playing around with V6 i noticed that Shoppa disk and tried to get ncc running, but after some debugging it looked like it is stuck in some loop which i think is due to possible bugs in the emulator code. So the question is, are there programs V6 runnable or rk bootable available which test the CPU functionality? I already hat a look at some xxdp disk, but the one i found (while they boot) seem to lack basic cpu tests. Best regards, Michael

5 years, 1 month

2
2
0 0

A la carte menu of OO features or properties

by Don Hopkins

The properties of object oriented programming are better described as an la carte menu like a cafeteria buffet or smörgåsbord, than a point, line, or continuum. http://www.paulgraham.com/reesoo.html <http://www.paulgraham.com/reesoo.html> Paul Graham: Reese Re: OO (Jonathan Rees had a really interesting response to Why Arc isn't Especially Object-Oriented, which he has allowed me to reproduce here.) Here is an a la carte menu of features or properties that are related to these terms; I have heard OO defined to be many different subsets of this list. • Encapsulation - the ability to syntactically hide the implementation of a type. E.g. in C or Pascal you always know whether something is a struct or an array, but in CLU and Java you can hide the difference. • Protection - the inability of the client of a type to detect its implementation. This guarantees that a behavior-preserving change to an implementation will not break its clients, and also makes sure that things like passwords don't leak out. • Ad hoc polymorphism - functions and data structures with parameters that can take on values of many different types. • Parametric polymorphism - functions and data structures that parameterize over arbitrary values (e.g. list of anything). ML and Lisp both have this. Java doesn't quite because of its non-Object types. • Everything is an object - all values are objects. True in Smalltalk (?) but not in Java (because of int and friends). • All you can do is send a message (AYCDISAM) = Actors model - there is no direct manipulation of objects, only communication with (or invocation of) them. The presence of fields in Java violates this. • Specification inheritance = subtyping - there are distinct types known to the language with the property that a value of one type is as good as a value of another for the purposes of type correctness. (E.g. Java interface inheritance.) • Implementation inheritance/reuse - having written one pile of code, a similar pile (e.g. a superset) can be generated in a controlled manner, i.e. the code doesn't have to be copied and edited. A limited and peculiar kind of abstraction. (E.g. Java class inheritance.) • Sum-of-product-of-function pattern - objects are (in effect) restricted to be functions that take as first argument a distinguished method key argument that is drawn from a finite set of simple names. […] (See the web page and the original thread for a discussion of which languages implement which of the above features.) http://www.paulgraham.com/reesoo.html <http://www.paulgraham.com/reesoo.html> https://web.archive.org/web/20160308032317/http://www.eros-os.org/pipermail… <https://web.archive.org/web/20160308032317/http://www.eros-os.org/pipermail…> -Don

5 years, 1 month

1
0
0 0

Re: [TUHS] v7 K&R C

by Doug McIlroy

> I feel the essence of object-oriented computing > is not operator overloading but the representation of behavior. Rob is right. Overloading is a universal characteristic of OO programming, but not the essence. Doug

5 years, 1 month

2
1
0 0

Re: [TUHS] v7 K&R C

by Paul McJones

> On May 13, 2020, at 7:00 PM,Dave Horsfall <dave(a)horsfall.org> wrote: > > I never could figure out why Stroustrup implemented that "feature"; let's > see, this operator usually means this, except when you use it in that > situation in which case it means something else. Now, try debugging that. C continues the tradition begun by Fortran and Algol 60 of overloading the arithmetic operators on the various numeric types. C++ allows new types to be defined; when a new type obeys the generally understood properties of a built-in type, it makes sense to use the same operator (or function) for the corresponding operation on the new type (e.g., addition on complex numbers, arbitrary-precision integers and rationals, polynomials, or matrices).

5 years, 1 month

3
2
0 0

[off topic] anyone want some QIC-250 tapes?

by arnold＠skeeve.com

I recently unearthed two 250 Mb QIC cartridges (like we used to use on Sun workstations). They were last written on in late 1997. I have no idea if they're any good, but they're free to anyone who'll pay postage (from Israel). If no takers, I'll just toss 'em. Thanks, Arnold

5 years, 1 month

2
1
0 0

Re: [TUHS] Linotron 202 Information

by TangentDelta

Here is a dump of the ROM in a text-based format. I couldn't think of a good way to represent the 4-bit words in a normal binary format with the order being ambiguous. Connecting a logic analyzer up to the ROM and triggering an "autoload" sequence, the processor reads ROM address 0, followed by ROM address 1, and then seems to lock up. I'm curious if the processor is attempting to store the 8-bit word into RAM for some reason? My RAM board is in very poor condition and I will need to devise a way to troubleshoot it. It'd also be helpful to have some of those control lines hooked up to the logic analyzer while it is happening. I'm working on a disassembler that should let me shuffle the order of the 4-bit words around until I get something that looks sane. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, May 13, 2020 3:27 PM, Ken Thompson <ken(a)google.com> wrote: > can you send me the bits of the rom. > i will take a look. > > On Tue, May 12, 2020 at 12:44 PM TangentDelta via TUHS <tuhs(a)minnie.tuhs.org> wrote: > >> Hello. >> >> I have a pair of controller card cages out of Mergenthaler Linotron 202 photo-typesetting machines. Sadly the machines themselves were scrapped, and these card cages are all I was able to save. >> >> The controllers use Computer Automation Naked Mini processors, which are relatively small 16-bit minicomputers designed for embedded control applications. I've been hacking on these for a few months now and have built up a system bus pinout diagram and several schematics. I haven't been able to find any technical information online in regards to the specific model of Naked Mini processor used in the 202, but I have found a trove of documents for other Naked Mini models on Bitsavers. >> >> I pulled the 512x4bit "boot ROM" mentioned in the "Experience with the Mergenthaler Linotron 202 Phototypesetter, or, How We Spent Our Summer Vacation" paper and dumped it, but the resulting binary doesn't produce any sane-looking code when manually disassembled using the documents on Bitsavers and reference, no matter how I arrange the nybbles. The processor also does not appear to respect the control opcodes issued by the Computer Automation LSI series programming console that I obtained. This has led me to the hypothesis that this is not a stock "Naked Mini" or later "Naked Milli" processor, but something specific to Mergenthaler. >> >> My goal is to get the processor to run my own code, and eventually design my own MaxiBus peripherals to use with it. >> >> If anyone knows where I can look for more information in regards to the 202 and the Naked Mini processor, or has any stories of working on these machines, I would greatly appreciate it! >> >> Thanks.

5 years, 1 month

1
0
0 0

Linotron 202 Information

by TangentDelta

Hello. I have a pair of controller card cages out of Mergenthaler Linotron 202 photo-typesetting machines. Sadly the machines themselves were scrapped, and these card cages are all I was able to save. The controllers use Computer Automation Naked Mini processors, which are relatively small 16-bit minicomputers designed for embedded control applications. I've been hacking on these for a few months now and have built up a system bus pinout diagram and several schematics. I haven't been able to find any technical information online in regards to the specific model of Naked Mini processor used in the 202, but I have found a trove of documents for other Naked Mini models on Bitsavers. I pulled the 512x4bit "boot ROM" mentioned in the "Experience with the Mergenthaler Linotron 202 Phototypesetter, or, How We Spent Our Summer Vacation" paper and dumped it, but the resulting binary doesn't produce any sane-looking code when manually disassembled using the documents on Bitsavers and reference, no matter how I arrange the nybbles. The processor also does not appear to respect the control opcodes issued by the Computer Automation LSI series programming console that I obtained. This has led me to the hypothesis that this is not a stock "Naked Mini" or later "Naked Milli" processor, but something specific to Mergenthaler. My goal is to get the processor to run my own code, and eventually design my own MaxiBus peripherals to use with it. If anyone knows where I can look for more information in regards to the 202 and the Naked Mini processor, or has any stories of working on these machines, I would greatly appreciate it! Thanks.

5 years, 1 month

1
0
0 0

Re: [TUHS] SDB debugger

by Doug McIlroy

> Does anyone know if dbx ended up 8 or 9th I believe the only debuggers on research machines were db v1-v6 adb v7,v9,v10 cdb v3-v6 sdb v8-v9 pi v8-v10 Doug

5 years, 1 month

4
3
0 0

SDB debugger

by Paul Ruizendaal

Reading some more stuff about the road from 7th Edition to 8th Edition, this time about debuggers. My current understanding is as follows: - On 6th edition the debugger was ‘cdb’ - On 7th edition it was ‘adb’, a rewrite / evolution from ‘cdb’ - In 32V a new debugger appears, ‘sdb’. Its code seems a derivative from ‘adb’, but the command language is substantially reworked and it uses a modified variant of the a.out linker format - in essence the beginnings of ‘stabs’. Of course the compiler, assembler, linker and related tools all emit/recognize these new symbol table elements. - The July 78 file note by London/Reiser does not mention a reworked debugger at all; the 32V tape that is on TUHS has ’sdb' files that are dated Feb/Mar 1979. This stuff must have been developed between July 78 and March 79. - In the SysIII and 3BSD code on TUHS (from early 80 and late 79 respectively) the stabs format is more developed. For SysIII it is ‘VAX only’. With these roots, it is not surprising that it is also in 8th Edition. Two questions: (1) According to Wikipedia the original author of the stabs format is unknown. It also says that the original author of ‘sdb’ is unknown. Is that correct, is the author really unknown? (2) As far as I can tell, the ’sdb’ debugger was never back ported to 16 bit Unix, not in the SysIII line and not in the 2.xBSD line. It would seem to me that the simple stabs format of 32V would have lent itself to being back ported. Is it correct that no PDP11 Unix used (a simple) stabs tool chain and debugger?

5 years, 1 month

12
22
0 0

Question: stdio - Who invented and ...

by Ed Bradford

I've forgotten who created stdio, USG or the research group. Can any of the youthful BTL folks of the 1970's refresh my mind. Given that stdio was invented and, in my opinion at the time, a reasonable and usable standard interface to IO on Unix, I am curious why no standard for networking was developed or proposed and discussed. Sockets just defined a new and very quirky IO interface for Unix based systems. Was any thought given to defining networking using the creat/open/read/write/close/mknod/link/unlink/chmod/chown model of IO in UNIX? Ed Bradford -- Advice is judged by results, not by intentions. Cicero

5 years, 1 month

8
10
0 0

Bell Labs recruiter

by Efton Collins

I was lucky enough to be in the room last year at VCF East when Ken told the story of how the move from Berkeley to Bell Labs happened. Ken's description of his interactions with the Bell recruiter was entertaining and made clear that persistent effort was needed to get him to come out to New Jersey and meet some of the people there. Does anyone know who the recruiter was?

5 years, 1 month

2
1
0 0

Fwd: Great deal on Unix! / Boing Boing

by Clem Cole

I felt that I had to pass this along... https://boingboing.net/2020/05/10/great-deal-on-unix.html

5 years, 1 month

1
0
0 0

uhs@tuhs.org

by Doug McIlroy

Subject: Re: [TUHS] sml/nj and unix/plan9 sml was in the the tenth edition. I used it a bit. I didn't find it unreasonably slow. Doug

5 years, 1 month

1
0
0 0

sml/nj and unix/plan9

by gdiaz＠qswarm.com

hello Was sml/nj part of UNIX at some point? was it considered as a language to use (proof tools may be)? I was wondering if there is any history in common between the two. I've been unable to find anything :-?, please share your stories! :-D Is it true that the language was too slow to be generally useful? There seems to be commentaries along these lines on the internet. thanks! gabi

5 years, 2 months

4
3
0 0

Re: [TUHS] DEC Compilers (was: Re: SDB debugger

by Doug McIlroy

>> Compile time was measured. My favorite "bug" was the >> many minutes it took to compile a constant expression >> that involved shifting a constant INT_MAX bits by >> performing that many 1-bit shifts. > > I don't know if this anecdote is an urban legend or if it really > happened. I was told [a similar] story when I was interning as an operator > at my alma mater, which was an IBM System/360 shop. I heard it not from the grapevine, but from McKeeman himself. Doug

5 years, 2 months

2
1
0 0

Re: [TUHS] DEC Compilers (was: Re: SDB debugger

by Doug McIlroy

> random small C programs with computable expected outputs "computable" is subtle here. The only way to compute the outputs was to run the program. McKeeman's trick was to sic several completely unrelated compilers on the program and let them vote on the answer. Compile time was measured. My favorite "bug" was the mmany minutes it took to compile a constant expression that involved shifting a constant INT_MAX bits by performing that many 1-bit shifts. Doug

5 years, 2 months

1
0
0 0

Re: [TUHS] SDB debugger

by norman＠oclsc.org

Doug's list is slightly off: adb v7-v10 sdb v8-v10 sdb may actually have been in V7; I'm quite sure it was present in 32/V. But it's not in the V7 manual. adb and sdb were certainly working fine when I arrived in 1127, but they still used ptrace because nobody wanted to touch the code. I used adb quite often (still would were it available in modern worlds!), so I cared enough to take it over, restructuring it quite a bit to make it easier to retarget for different instruction sets and byte orders, and of course to use /proc. I also made some trivial, compatible changes to how numbers were read and printed to conform to Rob's Rule (of which I am also a fan) that what a program presents as output it should also accept as input. sdb I wasn't as fond of, but I did want to get rid of ptrace, so I tinkered it just enough to accomplish that. I do remember clearly celebrating the death of ptrace by removing ptrace(2) from the copy of the V8 manual in the UNIX Room. It took up two pages, and they happened to be facing pages, so I glued them together. I wish it was as easy for others to have such satisfaction these days. Norman Wilson Toronto ON

5 years, 2 months

4
3
0 0

Test of new mailman software

by Warren Toomey

All, I upgraded the mailman software on minnie, just want to test that it's working OK. Cheers, Warren

5 years, 2 months

3
3
0 0

Fwd: Gnot terminal schematics

by Warren Toomey

Brantley Coile just asked: Looks like the mailman software works! Say, do you know if there are any copies of the Gnot terminal schematics? Brantley I don't know, does anybody else know? Cheers, Warren

5 years, 2 months

1
0
0 0

as(1) on Ultrix-11 vs 2.11BSD

by Paul Ruizendaal

> Sorry, I typed that in haste without testing. I don’t have a 2.11 system to try it on. However, reading the source code, I did that wrong. The args go on the stack, not in line with the code. > mov $6, -(sp) > mov a, -(sp) > mov $1,-(sp) > sys 4 Without suggesting that every helpful post should be tested, I find the superb https://unix50.org web emulator excellent for such things. Many thanks to the folks hosting & maintaining this great resource!

5 years, 2 months

5
5
0 0

Re: [TUHS] as(1) on Ultrix-11 vs 2.11BSD

by jnc＠mercury.lcs.mit.edu

> From: Jacob Ritorto > I wonder if the differences are written up somewhere. I did try to look > for more documentation but came up short. Sounds like a perfect topic for a CHWiki page. :-) E.g. this one: http://gunkies.org/wiki/Unix_V6_internals which I did as a bit of an addendum to Lions, to explain rsav, qsav and ssav, and similar topics. I noticed in the comparison of your two binary files that the instructions looked the same, but the a.out headers had a difference, but I didn't remember the fields in the a.out header enough to know what the differences meant. I thought I remembered doing an a.out page there, but apparently not. I thought about doing one now, but decided it wasn't worth it; I just needed to spin up my V6 system and do 'man a.out'! :-) Noel

5 years, 2 months

3
2
0 0

as(1) on Ultrix-11 vs 2.11BSD

by Jacob Ritorto

Hiya! Got these two pdp11s, one an 11/23 (Ultrix-11 3.1) and the other an 11/84 (2.11BSD) On the Ultrix machine, I can enter an assembly language program, assemble it and run it fine. amnesiac# cat hello.s mov $1,r0 sys 4 a 6 sys 1 a: <Hello\n> amnesiac# od hello 0000000 000407 000022 000000 000000 000014 000000 000000 000000 0000020 012700 000001 104404 000014 000006 104401 062510 066154 0000040 005157 000000 000000 000000 000002 000000 000000 000000 0000060 000000 000000 000141 000000 000000 000000 000002 000014 0000100 amnesiac# ./hello Hello amnesiac# But on the BSD machine, the exact same source program assembles differently and crashes with Illegal instruction when I run it. > cat hello.s mov $1,r0 sys 4 a 6 sys 1 a: <Hello\n> > od a.out 0000000 000407 000022 000000 000000 000010 000000 000000 000000 0000020 012700 000001 104404 000014 000006 104401 062510 066154 0000040 005157 000000 000000 000000 000002 000000 000000 000000 0000060 000000 000000 000000 000004 000002 000014 000000 000006 0000100 000141 0000102 > ./a.out Illegal instruction (core dumped) > Anyone know what I'm doing wrong? thx jake

5 years, 2 months

3
3
0 0

Re: [TUHS] v7 K&R C

by jnc＠mercury.lcs.mit.edu

> From: Rob Pike > Convenient though the shorthand may be, it always bothered me as > inconsistent and misleading. As someone who made very extensive use of procedure pointers (most notably in upcalls, which never caught on, alas), I couldn't agree more. Two very different things are happenging, but with the shorthand notation, they share an identical representation. And for what? To save three characters? Noel

5 years, 2 months

10
10
0 0

Re: [TUHS] v7 K&R C

by jnc＠mercury.lcs.mit.edu

> From: Derek Fawcus > I think he means something like: > (*((*((*((*f)()->g))()->h))()->i))() So I've been confused by this thread, and I'm hoping someone can deconfuse me - but I think I may have figured it out. What's confusing me is that in C, the -> operator is followed by "an identifier [which] designates a member of a structure or union object" (I checked the spec to make sure my memory hadn't dropped any bits) - but g, h above are arguments; so I couldn't figure out what was going on. I think what may have happened is that initially the discussion was about C ("Pretty sure it was not in v7 C"), but then it switched to C++ - with which I'm not familiar, hence my confusion - without explicitly indicating that change (although the reference to Bjarne Stroustrup should been a clue). (And that's why I thought "f()->g()->h()->i()" was ad hoc notation for "calls f(), then calls g()".) Am I tracking now? Noel

5 years, 2 months

4
3
0 0

Re: [TUHS] v7 K&R C

by jnc＠mercury.lcs.mit.edu

> From: Rob Pike > To make chaining of calls simpler. Write > f()->g()->h()->i() > the other way You mean: (*f)((*g)((*h)((*i)()))) I dunno, it doesn't seem that much worse to me. What I like about the explicit notation (i.e. (*f) ()) is that it forces the programmer to recognize what's going on. On the other hand, I guess, the whole concept of compiled languages is to get the programmer's nose out of the low-level details, so they can focus on the high level. So I guess one could see allowing f() in place of (*f)() as an instance of that. Then again, down that road you find a lot of modern code, where a programmer writes something that is e.g. horribly inefficient and slow, precisely because they are so divorced from the low-level of what the code they wrote turns into... Still, I'd be a little worried about a program doing (*f)((*g)((*h)((*i)()))), no matter what the notation was; it would be awfully hard to recognize what all the possible call chains are. But then again I guess a lot of e.g. AI code does things like that... Noel

5 years, 2 months

9
10
0 0

Re: [TUHS] v7 K&R C

by jnc＠mercury.lcs.mit.edu

> From: moanga >> To make chaining of calls simpler. Write >> f()->g()->h()->i() Ah; I was confused by his notation; I didn't realize he meant the C operator '->'. Noel

5 years, 2 months

2
1
0 0

v3 pipes

by Paul Ruizendaal

>> why the single fd approach was abandoned? To its credit, it appears to allow for limited 2-way communication. > My understanding is that the single file descriptor broke the open-file > model, which had a single read/write pointer. Two-way communication via I’m not sure I understand. In the implementation, the read pointer is file location offset (“fp->f_offset”) and the write pointer is the file size (“ip->i_size”). The location offset on the writing end of the pipe is always zero, and on the reading end it moves between zero and PIPSIZ (but that is unobservable). I just tried making both pipe ends readable+writeable in my “V6.5” kernel and that appears to work. It allows for bi-directional communication in a half-duplex sense (i.e communicating walky-talky style). The other benefit is using just one file descriptor, at a time when a process had just 15 to work with. Maybe the issue was that two sides writing to a full pipe at the same time will cause deadlock?

5 years, 2 months

2
1
0 0

Re: [TUHS] Plan 9 from outer space ?

by norman＠oclsc.org

I asked a friend who was around at the time (I think he and Rob worked together at times). Here's what he recalls: I'll keep it going. rc was a description that it was the worst movie ever. And was for many years listed as the worst system ever (except for all the others) in a mish-mash of creative naming... I have no clue if this is true, and I'm honestly having trouble recalling his name. It wasn't my intention. There was a description that it was a startup script from very early times in Unix, shortened, as Ken was wont to do, from runcom, the nearest thing CTSS had to a shell--it could run up to six prespecified commands in background. It wasn't a 'big name' like Evi, but I don't know if I buy it, that plan 9 from outer space poster hanging. Plan 9 from Bell Labs as all these themes flowed together in a mish-mash of creative naming... With a different name, it could be the lack of information, those who guess at reasons for naming generate volumes of apocrypha. The real reason is usually, ``because''.* Trust me, there are even worse movies... Someone posted some pictures of the names tell you anything helpful. Despite the lack of televised sports getting to me in these shelter-in-place days, but, I mean, sure, I guess I'll throw in some bucks for a pay-per-view of a Pike/Thompson cage match. FIGHT! Followups set. Things are named usually because the name is "Plan 9 from outer space poster hanging. None of the office area at Murray Hill to this list. Plan 9 is the worst system ever (except for all the others) in a knod to Churchill (supposedly based on his comment about Democracy). And from there it was 25 years ago and beer was involved). It makes a great story, but I don't think there's much doubt about it. And was for many years listed as the worst movie ever, including the formative years of plan 9. Yes, but is there anything besides the name? There is a widespred anecdote that "Plan 9" name comes from the movie until the end (what a pain!). _-_-_-_-Mark Norman Wilson Toronto ON

5 years, 2 months

12
13
0 0

Re: [TUHS] v3 pipes

by Doug McIlroy

> why the single fd approach was abandoned? To its credit, it appears to allow for limited 2-way communication. My understanding is that the single file descriptor broke the open-file model, which had a single read/write pointer. Two-way communication via Doug

5 years, 2 months

1
0
0 0

V3 pipes

by Paul Ruizendaal

Was looking into pipes. For the 3rd Edition TUHS does not have source, but is does have a man page. In V3, pipe returns a single file descriptor that echoes whatever is written back upon reading. The pipe buffer capacity is 504 bytes. The surviving ‘nsys’ source for V4 does not yet include the source for pipes, but the man page for 4th edition pipes has - more or less - the well known semantics, including the 4096 byte buffer capacity. Does anyone remember: - why the single fd approach was abandoned? To its credit, it appears to allow for limited 2-way communication. Maybe the reason was that it becomes harder to detect broken pipes? - whether the V3 implementation was based on an in-memory approach and not the later 'anonymous backing file’? The 504 byte buffer capacity suggests a single buffer page minus some header info.

5 years, 2 months

1
0
0 0

Off Topic: Unix Kermit 4x software archeology

by Warner Losh

Greetings, So this happened: https://bsdimp.blogspot.com/2020/04/finding-kermit-4x.html tl;dr: while obsessing over 4C(052) kermit that's in Rainbow Venix, I found a lot of cool "lost" source code versions of Kermit... All except the one I was looking for. Warner

5 years, 2 months

1
0
0 0

8th Edition and /dev/stdio

by Paul Ruizendaal

Whilst spelunking in the V8 source code I came across this dozen lines: http://chiselapp.com/user/pnr/repository/v8unix/artifact/2782d26fa2930724?l… It implements the /dev/stdin, /dev/stdout and /dev/stderr devices (the variable ‘file_no’ in above code snippet is the constant 40, which is the major number of these devices). It would seem that this handful of lines could have been in Unix as early as 4th Edition — but they weren’t. Maybe it was not seen as useful. As far as I can tell this bit of code originates in 8th Edition, with no earlier precursors. It does not seem to be in its man pages. Who added this neat little innovation?

5 years, 2 months

5
10
0 0

Usenix tapes

by Warner Losh

So in the archives we have tapes from 1977, 1980-83 and 1987-89. So I thought I'd ask if there's other tapes that aren't in the archive... google can't even find the tapes we have in our archive, let alone others... Warner

5 years, 2 months

2
2
0 0

Re: [TUHS] Plan 9 from outer space ?

by Doug McIlroy

I'll keep it going. rc was a startup script from very early times in Unix, shortened, as Ken was wont to do, from runcom, the nearest thing CTSS had to a shell--it could run up to six prespecified commands in background. The name runcom came to be applied to the scripts as well as to their interpreter. Doug ------------------------------------- It wasn't my intention. -rob On Sun, Apr 19, 2020 at 11:12 AM Ken Thompson <ken(a)google.com> wrote: > > rob, > you shouldn't have shut down this discussion.

5 years, 2 months

1
0
0 0

Re: [TUHS] Plan 9 from outer space ?

by Rob Pike

It wasn't my intention. -rob On Sun, Apr 19, 2020 at 11:12 AM Ken Thompson <ken(a)google.com> wrote: > > rob, > you shouldn't have shut down this discussion. > > > On Sat, Apr 18, 2020 at 3:27 PM Rob Pike <robpike(a)gmail.com> wrote: >> >> As it says there, >> >> The hermeneutics of naming yields few insights. Things are named usually because the name is nice (sam), or there is some private reference hard to decode (8½), or in honour (perhaps backhanded) of another system (mothra), or an indication of expectation (Plan 9, acme), or just because (acid). None of the names tell you anything helpful. >> >> Despite the lack of information, those who guess at reasons for naming generate volumes of apocrypha. The real reason is usually, ``because''. >> >> -rob >> >> >> >> On Sun, Apr 19, 2020 at 3:50 AM Royce Williams <royce(a)techsolvency.com> wrote: >>> >>> On Sat, Apr 18, 2020 at 9:45 AM Warner Losh <imp(a)bsdimp.com> wrote: >>>> >>>> >>>> On Sat, Apr 18, 2020 at 11:24 AM Pierre DAVID <pdagog(a)gmail.com> wrote: >>>>> >>>>> On Sat, Apr 18, 2020 at 06:20:18PM +0100, Richard Tobin wrote: >>>>> >> There is a widespred anecdote that "Plan 9" name comes from the >>>>> >> movie "Plan 9 From Outer Space". >>>>> > >>>>> >Given that the full name is "Plan 9 from Bell Labs" I don't think >>>>> >there's much doubt about it. >>>>> > >>>>> >>>>> Yes, but is there anything besides the name? >>>> >>>> >>>> Plan 9 is the worst movie ever. And was for many years listed as the worst movie ever, including the formative years of plan 9. >>>> >>>> A professor(?) at CU once told me, though I don't know if I buy it, that plan 9 was Unix Plan B at first. There was a description that it was the worst system ever (except for all the others) in a knod to Churchill (supposedly based on his comment about Democracy). And from there it was a quick jump to Plan 9 from Bell Labs as all these themes flowed together in a mish-mash of creative naming... With a different name, it could break with Unix in interesting ways... >>>> >>>> I have no clue if this is true, and I'm no longer in contact with the professor that told me this since it was mid to late 90s, and I'm honestly having trouble recalling his name. It wasn't a 'big name' like Evi, but I think it was someone at CU I had a beer with (which means it could have been a grad student to post-doc as well, it was 25 years ago and beer was involved). It makes a great story, but I don't know if it's anything more than that. I put it out there because I know Rob or Ken is likely to correct something that's this detailed and specific if it's really wrong :) >>> >>> >>> See also: >>> >>> http://9p.io/wiki/plan9/lfaq/index.html#GENERAL_INFORMATION >>> >>> Royce

5 years, 2 months

2
1
0 0

Re: [TUHS] Plan 9 from outer space ?

by Richard Tobin

> There is a widespred anecdote that "Plan 9" name comes from the > movie "Plan 9 From Outer Space". Given that the full name is "Plan 9 from Bell Labs" I don't think there's much doubt about it. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

5 years, 2 months

5
4
0 0

Plan 9 from outer space ?

by Pierre DAVID

There is a widespred anecdote that "Plan 9" name comes from the movie "Plan 9 From Outer Space". Since I didn't find anything more than a reference to this anecdote (see https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs for example), I forced myself to watch the movie until the end (what a pain!). Guess what? I couldn't find the link between the film and the beloved OS. I'm sure there are people here who know more. Thanks in advance for sharing your knowledge with us. Pierre

5 years, 2 months

3
2
0 0

"7th Edition UNIX TM Summary" => "â7th Edition UNIX â Summaryâ => â€œ7th Edition UNIX â€” Summaryâ€

by Don Hopkins

I love how in a discussion of how difficult it was to publish a book on Unix with the correct punctuation characters 42 years ago, we still can’t even quote the title of the book in a discussion about Unix without the punctuation characters degrading and mutating each round trip. Worse truly is better! ;) -Don

5 years, 2 months

2
1
0 0

Early Datakit - Summary of findings

by Paul Ruizendaal

I’ve posted a summary of my Datakit notes here: https://drive.google.com/open?id=1p6HD5-NSAYKfiXL6GUxfYZgGoesqG6Sp (available for a limited time) Hopefully, these notes are helpful for anyone trying to figure out Datakit networking in Eighth Edition. At the user level, access is organised through the ‘dkdial’ and ‘dkmgr’ routines: http://man.cat-v.org/unix_8th/3/dkmgr http://man.cat-v.org/unix_8th/3/tdkdial The IP networking is handled in the same pattern: http://man.cat-v.org/unix_8th/3/tcp http://man.cat-v.org/unix_8th/3/udp The ipc set of library routines that unify these lower level routines into a single API will only appear in 9th Edition (a year later).

5 years, 2 months

1
0
0 0

4.2BSD Steering committee

by Paul Ruizendaal

According to “20 years of BSD”, there was a steering committee to inform the development of what would eventually be 4.2BSD Unix. The committee had the following members: Duane Adams and Bob Baker: DARPA Bob Fabry, Bill Joy, Sam Leffler: CSRG Dennis Ritchie: Bell Labs Alan Nemeth, Rob Gurwitz: BBN Dan Lynch: ISI Keith Lantz: Stanford Rick Rashid: CMU Bert Halstead: MIT Jerry Popek: UCLA I’m intrigued by the composition and the rationale for each member. Some of it is obvious, some of it is not. According to “20 years of BSD” what DARPA wanted was: "In particular, the new system was expected to include a faster file system that would raise throughput to the speed of available disk technology, support processes with multi-gigabyte address space requirements, provide flexible interprocess communication facilities that allow researchers to do work in distributed systems, and would integrate networking support so that machines running the new system could easily participate in the ARPAnet." As I understand Duane Adams was the contract manager and Bob Baker a DARPA vice-president. The CSRG crowd are also clear, they were going to do the work. Then it becomes less clear. I can certainly see the logic of asking dmr to provide his guidance, also in view of Bell Labs expertise in working with large scale communication systems. I can also see the logic of having the BBN and ISI folk there, representing the Arpanet community and doing the work on the new TCP/IP protocol stack. I’m not sure about the four others. They seem to be one each for 4 main computer science schools in the US at the time. Rashid and Popek had moreover recently completed distributed systems (Aleph and LOCUS). Halstead seems to have been working on messaging systems at the time. I’m not sure what Lantz’ spike was at the time. All in all, a strong focus on distributed systems and messaging. No people with apparent links to virtual memory research or disk access research. Other than dmr, no research people from industry. For example, nobody from Xerox Parc. Nobody from IBM, HP, DEC, DG, etc. Any and all recollections about the committee and its composition welcome.

5 years, 2 months

2
1
0 0

First book on Unix for general readership

by markus schnalke

Hoi, found on Wikipedia: As well as the Bourne shell, he wrote the adb debugger and The UNIX System, the second book on the UNIX system, intended for a general readership. https://en.wikipedia.org/wiki/Stephen_R._Bourne Thus I now wonder what the first book on Unix, intended for a general readership was. Bourne's book was published 1983. (``The UNIX Programming Environment'' was published 1984.) Was it Banahan and Rutter's ``UNIX -- the Book''? It says 1982. Could anyone share some background on that one? (The authors were from Bradford University.) I only have the German translation by Axel T. Schreiner, dated 1984. Haven't read the English original, but Schreiner's version definitely is worth to read (if you speak German). He added lots of footnotes, and it becomes apparent that he knows the system better than the authors. ;-) I'd like to get an understanding of the books in relation to each other. How does the Banahan/Rutter book fit into the picture? Why didn't Bell Labs write a user's book earlier? Were Bourne's and Kernighan/Pike's books reactions to it? meillo

5 years, 2 months

13
20
0 0

Re: [TUHS] First book on Unix for general readership

by Doug McIlroy

> OK, I've dug out my copies. They have perforated, 3-hole punched pages ... > I can't find any obvious typesetting errors. That sets my mind at rest after three decades. What I saw back in the day was littered with @ signs, and was not punched for a ring binder. Thanks for checking. Doug

5 years, 2 months

1
0
0 0

STREAMS performance

by Paul Ruizendaal

> Date: Sat, 11 Apr 2020 08:44:28 -0700 > From: Larry McVoy > > On Sat, Apr 11, 2020 at 11:38:44AM -0400, Norman Wilson wrote: >> -- Stream I/O system added; all communication-device >> drivers (serial ports, Ethernet, Datakit) changed to >> work with streams. Pipes were streams. > > How was performance? Was this Dennis' streams, not Sys V STREAMS? It was streams, not STREAMS. > I ported Lachmans/Convergents STREAMS based TCP/IP stack to the > ETA 10 Unix and SCO Unix and performance just sucked. Ditto for > the Solaris port (which I did not do, I don't think it made any > difference who did the port though). STREAMS are outside the limited scope I try to restrain myself to, but I’m intrigued. What in the above case drove/caused the poor performance? There was a debate on the LKML in the late 1990’s where Caldera wanted STREAMS support in Linux and to the extent the arguments were technical *), my understanding of them is that the main show stopper was that STREAMS would make ‘zero copy’ networking impossible. If so, then it is a comment more about the underlying buffer strategy than STREAMS itself. Did STREAMS also perform poorly in the 1986 context they were developed in? Paul *) Other arguments pro- and con included forward maintenance and market need, but I’m not so interested in those aspects of the debate.

5 years, 2 months

5
6
0 0

Re: [TUHS] First book on Unix for general readership

by Doug McIlroy

> Indeed the Unix manuals were available as printed books. Volume One was the manual pages and Volume Two the articles from /usr/doc. I remember seeing soft-cover bound copies of the 7th Edition manuals, ... > I think the next time this happened in the exact same way was with the "Unix Research System Tenth Edition" books published by Saunders College Publishing in 1990. Those were the only two that were published as trade books. I still use the 10th Ed regularly. The 7th Ed was a debacle. The publisher didn't bother to send us galleys because they had printed straight from troff. It turned out they did not have the full troff character set, and put an @ sign in place of each missing character. The whole print run was done before we saw a copy. Not knowing whether they ever fixed it, I'd be interested to hear whether or not the botch made it to bookstores. Doug

5 years, 2 months

3
2
0 0

V8, V9 and V10 now in the "Unix Tree"

by Paul Ruizendaal

Oops - pressed send too soon - apologies — Many thanks for the below notes! Some comments in line below: > The initial user-mode environment was a mix of 32V, > subsequent work within 1127, and imports from 4.1BSD. > I don't know the exact heritage: whether it was 1127's > work with 4.1BSD stuff added or vice-versa. Looking at the organisation of the source tree I’d say it is more likely that the base was V32 with bits of 4.1BSD imported than the other way around. If it was the other way around somebody would have spent considerable time to reorganise the source tree back to a form consistent with 32V. I think that such an effort would have been remembered even 40 years later. > The kernel was a clean break, however: 4.1xBSD for some > value of x (probably 4.1a but I don't remember which) > with Research changes. I don’t mean disrespect, but I think the surviving sources support Rob’s recollection that it was a gradual, ongoing effort. As a first approximation looking at the top comments of a file gives its origin: the BSD derived files still have an SCCS-type marker. For example the file https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/vmmem.c still has the top comment "/* vmmem.c 4.7 81/07/09 */“, even though it was last touched in 1985. (By the way, who knows which tool generated these comments? Is it early SCCS?) For the VM code, the BSD version stamp comment strings are consistent with the 4.1BSD release. For the TCP/IP stack they are consistent with 4.2BSD; it would seem probable to me that this code was imported multiple times during the development of 8th Edition. As far as I can tell 4.1aBSD was released in March or April 1982. Unfortunately no source code tape of it has surfaced, and SCCS coverage at this point is still very partial. I think 4.1b with the initial FFS implementation followed late summer 1982, I don’t have a more precise date (yet). > -- Berkeley FFS replaced by Weinberger's bitmapped > file system: essentially the V7 file system except > the free list was a bitmap and the blocksize was 4KiB. Thank you for pointing this out. With my focus on networking I had completely missed that. > Hacky implementation, depending on a flag bit in the > minor device number; didn't use the file system switch. > Old 512-byte-block file systems had to be supported > partly to ease the changeover, partly because the first > version had a limited bitmap size so file systems larger > than about 120MiB wouldn't work. For those interested, some of the relevant files are: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/param.h (middle bit) https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/filsys.h (note the union) https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/alloc.c (note 'if(BITFS(dev))’) And indeed the bitmap was fitted inside the 4KB superblock, 961 longs. 961 x 32 bits x 4KB = 120MB I’m not sure I understand the link between cluster and page size that is mentioned in param.h > This limit was removed > later. (In retrospect I'm surprised I didn't then insist > on converting any remaining old-format file systems in > our domain and then removing the old-format code from > the kernel, since user-mode tools--including a user-mode > file server!--could be used to access any old disks > discovered later.)

5 years, 2 months

2
1
0 0

V8, V9 and V10 now in the "Unix Tree"

by Paul Ruizendaal

Many thanks for the below notes! Some comments in line below: > The initial user-mode environment was a mix of 32V, > subsequent work within 1127, and imports from 4.1BSD. > I don't know the exact heritage: whether it was 1127's > work with 4.1BSD stuff added or vice-versa. Looking at the organisation of the source tree I’d say it is more likely that the base was V32 with bits of 4.1BSD imported than the other way around. If it was the other way around somebody would have spent considerable time to reorganise the source tree back to a form consistent with 32V. I think that such an effort would have been remembered even 40 years later. > The kernel was a clean break, however: 4.1xBSD for some > value of x (probably 4.1a but I don't remember which) > with Research changes. I don’t mean disrespect, but I think the surviving sources support Rob’s recollection that it was a gradual, ongoing effort. As a first approximation looking at the top comments of a file gives its origin: the BSD derived files still have an SCCS-type marker. For example the file https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/vmmem.c still has the top comment "/* vmmem.c 4.7 81/07/09 */“, even though it was last touched in 1985. (By the way, who knows which tool generated these comments? Is it early SCCS?) For the VM code, the BSD version stamp comment strings are consistent with the 4.1BSD release. For the TCP/IP stack they are consistent with 4.2BSD; it would seem probable to me that this code was imported multiple times during the development of 8th Edition. As far as I can tell 4.1aBSD was released in March or April 1982. Unfortunately no source code tape of it has surfaced, and SCCS coverage at this point is still very partial. I think 4.1b with the initial FFS implementation followed late summer 1982, I don’t have a more precise date (yet). > -- Berkeley FFS replaced by Weinberger's bitmapped > file system: essentially the V7 file system except > the free list was a bitmap and the blocksize was 4KiB. Thank you for pointing this out. With my focus on networking I had completely missed that. > Hacky implementation, depending on a flag bit in the > minor device number; didn't use the file system switch. > Old 512-byte-block file systems had to be supported > partly to ease the changeover, partly because the first > version had a limited bitmap size so file systems larger > than about 120MiB wouldn't work. For those interested, some of the relevant files are: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/param.h (middle bit) https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/filsys.h (note the union) https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/alloc.c (note 'if(BITFS(dev))’) And indeed the bitmap was fitted inside the 4KB superblock, > This limit was removed > later. (In retrospect I'm surprised I didn't then insist > on converting any remaining old-format file systems in > our domain and then removing the old-format code from > the kernel, since user-mode tools--including a user-mode > file server!--could be used to access any old disks > discovered later.) > > For the purposes of Paul's note it probably suffices > just to say that there was a restart with a 4.1-series > kernel with changes as he describes, except also the > new file system format.

5 years, 2 months

1
0
0 0

V8, V9 and V10 now in the "Unix Tree"

by Paul Ruizendaal

Warren has been nice enough to put 8th, 9th and 10th edition on the TUHS “Unix Tree” web page. There is the following question on each entry web page: “Who wants to write something here?” Below my suggested draft text for Eight Edition. All suggestions for improvement welcome. === Shortly after the release of 7th Edition, the VAX became the base machine for further Unix development. The initial code base was the 32V port, enhanced with selected elements from 4.1BSD, such as support for virtual memory and later the TCP/IP stack. From there the code further evolved: Eighth Edition of Unix was released by Bell Laboratories in February 1985, six years after Seventh Edition. Key innovations in 8th Edition include ‘streams’ and the 'file system switch’, which allowed the “everything is a file” approach to be extended to new areas. Three notable applications built on these were the ‘/proc’ file system and new debugger API, a unified approach to networking over Datakit, TCP/IP and phone lines, and a network file system. Eighth Edition is also at the root of graphical user interfaces on Unix, being the platform used for the development of the ‘Blit’ graphical terminal. Several of the new ideas from Eigth Edition found their way into the 3rd release of System V, although in a much modified way. ===

5 years, 2 months

2
2
0 0

Discord chat in about 13 hours?

by Warren Toomey

Anybody feel like a text/voice chat on the ClassicCmp Discord server in about 13 hours, say 2200 UTC? #coff and the General voice channel. I'll pop on for an hour but start whenever you feel like. Cheers, Warren -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

5 years, 2 months

4
4
0 0

V8, V9 and V10 now in the "Unix Tree"

by norman＠oclsc.org

Minor corrections to the material in Paul's text. This is meant to be a laundry-list of facts, not a suggested set of words; I'm feeling too prolix this morning to produce the latter, and figure those on the list may be interested in the petty details anyway. The initial user-mode environment was a mix of 32V, subsequent work within 1127, and imports from 4.1BSD. I don't know the exact heritage: whether it was 1127's work with 4.1BSD stuff added or vice-versa. The kernel was a clean break, however: 4.1xBSD for some value of x (probably 4.1a but I don't remember which) with Research changes. By the time of V8, that means: -- All trace of BSD's original network interfaces removed, except that select(2) remained in a slightly-different form. -- Stream I/O system added; all communication-device drivers (serial ports, Ethernet, Datakit) changed to work with streams. Pipes were streams. -- File system switch added, supporting Killian's /proc and Weinberger's first-generation (neta) network file system. -- Berkeley FFS replaced by Weinberger's bitmapped file system: essentially the V7 file system except the free list was a bitmap and the blocksize was 4KiB. Hacky implementation, depending on a flag bit in the minor device number; didn't use the file system switch. Old 512-byte-block file systems had to be supported partly to ease the changeover, partly because the first version had a limited bitmap size so file systems larger than about 120MiB wouldn't work. This limit was removed later. (In retrospect I'm surprised I didn't then insist on converting any remaining old-format file systems in our domain and then removing the old-format code from the kernel, since user-mode tools--including a user-mode file server!--could be used to access any old disks discovered later.) For the purposes of Paul's note it probably suffices just to say that there was a restart with a 4.1-series kernel with changes as he describes, except also the new file system format. Norman Wilson Toronto ON

5 years, 2 months

3
2
0 0

Re: [TUHS] V8, V9 and V10 now in the "Unix Tree"

by norman＠oclsc.org

Doug McIlroy: The v8 manual was printed in 1985, but the system was not "released" in the ordinary sense until a couple of years ago. Some v8 features made it out into the world via USG; some were described in open literature or Usenix presentations, but I believe none were formally shipped out of the company. I'm surprised; I thought copies of the V8 manual existed when I arrived at the Labs in mid-1984, but the date on the title page is indeed February 1985. There was no general release of V8 like those for earlier Research systems, but there was a quasi-official V8 tape sent to a handful of universities under a special letter agreement. I remember working on that with Dennis, checking that everything compiled and worked properly in a chroot environment before the tape was written. I think that happened in the summer of 1985. I don't remember our doing that work, to make a single coherent consistency-checked release tape, for any subsequent system; just one-off caveat-emptor snapshots. Norman Wilson Toronto ON

5 years, 2 months

2
1
0 0

Re: [TUHS] V8, V9 and V10 now in the "Unix Tree"

by Doug McIlroy

The v8 manual was printed in 1985, but the system was not "released" in the ordinary sense until a couple of years ago. Some v8 features made it out into the world via USG; some were described in open literature or Usenix presentations, but I believe none were formally shipped out of the company. Doug

5 years, 2 months

1
0
0 0

PK protocol

by Paul Ruizendaal

I ran a search for ‘Datakit’ on the archive of this maling list and came across the below message from Norman Wilson (Sep 2017). Having spent quite a bit of time recently on figuring out Datakit details and 8th Edition source, I now much better understand what he was saying — or at least I think I do. It made me take another look at the /dev/pk[0123].c files in the V7 source code. I’d seen it before, but always thought it was UUCP code. Now I’m wondering. It looks like UUCP packet "protocol g” is maybe much the same as the original (“Chesson”) packet algorithm for Datakit, and if so it would be “dual use”. It would seem that in V7 line discipline ‘0’ was normal tty handling, discipline ‘1’ was PK protocol over serial and line discipline ‘2’ was PK protocol over something with CRC in the driver - whatever that was. If the above thought is correct, then it shines a light on network buffering in V7: it uses buffer space in blocks of n*32 bytes, carved out from a pool of disk buffers (see pk3.c); it pre-allocates space for one full receive window. I have not fully figured it out, but at first glance it seems that the PK line discipline was only integrated with the DH-11 driver in the public V7 source. That would make sense in a networking context, as that board offered input buffering / DMA output to reduce the interrupt load. In 1979 Datakit seems to have connected over a DR-11C board, but there is no driver for that in the V7 source tree. Am I on the right track? ===== The point of the stream I/O setup with stackable line disciplines, rather than the old single line-discipline switch, was specifically to support networking as well as tty processing. Serial-device drivers in V7 used a single line-discipline driver, used variously for canonical-tty handling and for network protocols. The standard system as used outside the labs had only one line discipline configured, with standard tty handling (see usr/sys/conf/c.c). There were driver source files for what I think were internal-use-only networks (dev/pk[12].c, perhaps), but I don't think they were used outside AT&T. The problem Dennis wanted to solve was that tty handling and network protocol handling interfered with one another; you couldn't ask the kernel to do both, because there was only one line discipline at a time. Hence the stackable modules. It was possible to duplicate tty handling (probably by placing calls to the regular tty line discipline's innards) within the network-protocol code, but that was messy. It also ran into trouble when people wanted to use the C shell, which expected its own special `new tty' line discipline, so the network code would have to know which tty driver to call. It made more sense to stack the modules instead, so the tty code was there only if it was needed, and different tty drivers could exist without the network code knowing or caring. When I arrived at the Labs in 1984, the streams code was in use daily by most of us in 1127. The terminals on our desks were plugged into serial ports on Datakit (like what we call a terminal server now). I would turn on my terminal in the morning, tell the prompt which system I wanted to connect to, and so far as I could tell I had a direct serial connection. But in the remote host, my shell talked to an instance of the tty line module, which exchanged data with a Datakit protocol module, which exchanged data with the low-level Datakit driver. If I switched to the C shell (I didn't but some did), csh would pop off the tty module and push on the newtty module, and the network code was none the wiser. Later there was a TCP/IP that used the stream mechanism. The first version was shoehorned in by Robert T Morris, who worked as a summer intern for us; it was later cleaned up considerably by Paul Glick. It's more complicated because of all the multiplexers involved (Ethernet packets split up by protocol number; IP packets divided by their own protocol number; TCP packets into sessions), but it worked. I still use it at home. Its major flaw is that details of the original stream implementation make it messy to handle windows of more than 4096 bytes; there are also some quirks involving data left in the pipe when a connection closes, something Dennis's code doesn't handle well. The much-messier STREAMS that came out of the official System V people had fixes for some of that, but at the cost of quite a bit more complexity; it could probably be done rather better. At one point I wanted to have a go at it, but I've never had the time, and now I doubt I ever will. One demonstration of virtue, though: although Datakit was the workhorse network in Research when I was there (and despite the common bias against virtual circuits it worked pretty well; the major drawback was that although the underlying Datakit fabric could run at multiple megabits per second, we never had a host interface that could reliably run at even a single megabit), we did once arrange to run TCP/IP over a Datakit connection. It was very simple in concept: make a Datakit connection (so the Datakit protocol module is present); push an IP instance onto that stream; and off you go. I did something similar in my home V10 world when quickly writing my own implementation of PPP from the specs many years ago. The core of that code is still in use in my home-written PPPoE code. PPP and PPPoE are all outside the kernel; the user-mode program reads and writes the serial device (PPP) or an Ethernet instance that returns just the desired protocol types (PPPoE), does the PPP processing, and reads and writes IP packets to a (full-duplex stream) pipe on the other end of which is pushed the IP module. All this is very different from the socket(2) way of thinking, and it has its vices, but it also has its virtues. Norman Wilson Toronto ON

5 years, 2 months

1
1
0 0

8th Edition timeline

by Paul Ruizendaal

Here is a question for the old hands from the Labs, I’m trying to get the timeline of some development steps right. The two main things are: when did the 4.1 merge take place, and when were ‘streams’ added? Going by file dates, the surviving 8th edition source appears to be from 1985. I can see that a lot of files in /usr/include did not change after Jan 1982 (e.g. nlist.h). This suggests that early in 1982 the merge between 4.1 code and 32V code took place, to create the foundation for further development (“proto 8th edition”, so to speak). Similarly, there are a dozen or so files in the kernel that all have a file date of November 1982. The most interesting one of these is “dtline.c”, a character mode Datakit driver: it uses ‘streams’. This suggests that there was a further code merge late in 1982 and implies that ‘streams’ were developed prior to that date. From the S/F-Unix papers it seems that ‘streams’ did not exist in 1981, at least they are not mentioned in an otherwise comprehensive set of papers. On the other hand, the S/F-Unix work was done in the Exploratory group, not the Research group: maybe it was inappropriate to mention. All in all, my hypotheses would be that: - the 32V/4.1 merge took place early in 1982 - ‘streams’ were developed in 1982 on 32V (maybe also V7) systems - a further merge took place late in 1982 that combined the new base with latest developments Does that sound correct, or was it all different? Related is the question when the "file system switch" was added. It must have been later than 1981 and before 1985, but I have not been able to pinpoint it further. Paul

5 years, 2 months

10
22
0 0

Manuals

by John P. Linderman

Andrew Hume (andrew(a)humeweb.com) has had trouble posting this, and asked me to try. Reply directly to Andrew, not to me. ============================ I have the following manuals available: 3 Eight Edition Unix manuals (2 shrink-wrapped, one not (but still good condition)) Unix programmers manual, Release 3.0 (Dolotta et al, 1980) Sixth Edition programmers manual (Bell Labs cardboard cover) Sixth Edition Documents manual (Bell Labs cardboard cover) Seventh Edition programmers manual Volume 2a, Jan 1979. (actually documents such as make, lint, troff etc) Documents for UNIX, Volume 2 (Dolotta et al, 1981) sections E and F (make, lex, security etc) All the above are in pretty good condition, given they are bound in cardboard covers and are 40ish years old. I’d prefer to give them to someone archival, but otherwise, first come, first served. Andrew Hume

5 years, 3 months

2
1
0 0

Software Archaeology Challenge?

by Warren Toomey

Anybody feel up for a bit of an archaeology challenge? Warner Losh is currently poking through a bunch of bits but not having much luck decoding them correctly. I've put a copy here: https://minnie.tuhs.org/Y5/Challenge/ If you can help, I'd suggest report major findings here, and we can use the #TUHS channel in the ClassicCmp Discord server for chat. Here's what Warner has found out so far: It's quite interesting, but in a format I've so far not been able to decode more than with emacs. However, there's all kinds of wonderful here. This looks like it was a dump from a VMS (or maybe similar DEC OS) ANSI tape. There's 4 datasets of 2.5MB each. The first one appears to be a V5 tree of some sort (at least it matches the V5 sources in places I can spot check in Dennis_v5. The second block looks v6ish or maybe pwbish, but no kernel sources. I don't think it's a continuation of the v5 stuff from the first dataset. The third dataset is all binaries, as far as I can tell so far, but things like mv and passwd. The 4th dataset appears to be the dump of a VENIX-11 system, complete with source. The 3rd dataset appears to be a Venix system. At least it has venix and venix.old in what looks like the root directory. Still trying to sort out extracting files from these datasets. v7fs hates them, but I'm almost positive that's what they are. Cheers, Warren

5 years, 3 months

7
10
0 0

Xenix-11 Images

by Warner Losh

Crazy longshot post, part 27 in an infinite series Are there any Xenix-11 images (boot tapes or disk images) around? My googling skillz aren't mad enough to find this. I've seen the Xenix 86 image in the archive that was copied from pce's image warehouse which is cool and the generation of code I'm looking for, but is for 8086 machines... Warner

5 years, 3 months

2
3
0 0

Re: [TUHS] First book on Unix for general readership

by Doug McIlroy

Another book from the same era--quite good--is A Unix Primer by Ann Nichols Lomuto and Nico Lomuto, copyright 1983. Before the title page appears an interesting endorsement: "Prentice-Hall Software Series, Brian Kernighan, advisor Doug

5 years, 3 months

1
0
0 0

Re: [TUHS] Research PBX legacy

by Doug McIlroy

Prologue to TPC. Bob Morris did a visiting-researcher stint at AT&T, where he became aware of infelicitous software architure proposed for ESS 5. He thought Research could do it better. Ken, Joe, and Lee bit. Lee's architecture was indeed novel: every device in the system, right down to each touch-tone button, was modeled as a process. Only after the clean model was working were some processes--notably the buttons--jammed together to cinch in the process table. The team got the switch working in a matter of months--in time to demonstrate it to Indian Hill before ESS was irrevocably set in stone. ESS architecture was indeed rethought, taking some ideas from TPC. TPC was named after "TPC, The Phone Company" in the 1967 film, "The President's Analyst". Doug

5 years, 3 months

1
0
0 0

Research PBX legacy

by Paul Ruizendaal

About a year ago the Research telephone switch came up on this list. Rob Pike wrote: "But the PBX story is correct. To demonstrate how message passing was a good model for a switching system, in particular to make a point to the switching systems division of Bell Labs/AT&T, Ken and Joe bought a commercial PBX and swapped out its processor for a PDP-11/23 (I think), and programmed it up. It was just before I arrived there but I was given the impression it had the desired strategic influence on Indian Hill. The feature we all loved it for was that instead of ringing the phone in the Unix room when you got a call, it would announce your name through the voice synthesizer: "Phone call for Ken." "Phone call for Joe". One rapidly stopped even hearing the announcement if it didn't end with your name.” I’ve been having an off list discussion with Bill Marshall and this PBX was influential in another way as well. First of all, Bill can confirm that it indeed was a 11/23, the same racks were used for Datakit switches. He also remembered that the software for this PDP-11 went by the nickname of “TPC” - for Tiny Phone Company. Lee McMahon was on the team writing TPC. The first software for the Datakit switch was written by Greg Chesson and was called “CMC” (for ‘Common Control’). There are still some references to CMC in the 8th Edition source code. This first software was later replaced by new code designed by Lee McMahon that was modelled after TPC. This new code was named “TDK”. This, too, can be seen in the 8th Edition source. The TDK protocols for building and releasing a Datakit virtual circuit appear to have been in use into the 1990’s.

5 years, 3 months

1
0
0 0

Stdio and ABIs

by Warren Toomey

https://fingolfin.org/blog/20200327/stdio-abi.html An interesting look at the history of stdio and subsequent ABI choices. Cheers, Warren -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

5 years, 3 months

1
0
0 0

Re: [TUHS] weird \s

by Doug McIlroy

Thanks, everyone, for pointing out the "accident of history". This is a little morality tale about clever programming. Joe Ossanna would never have tokenized \s constructs that way if the CAT typesetter had been capable of a wider range of type sizes. Brian seems to have kept it for backward compatibility. But groff was perfectly willing to break backward compatibility in tokenizing command names. Why not in \s? I encourage Branden to go whole hog and let \s123DEWEY WINS produce a banner headline. Doug

5 years, 3 months

1
0
0 0

Re: [TUHS] Article on Unix pipes history

by jnc＠mercury.lcs.mit.edu

> From: Warren Toomey > Quite good Yes. The second part of: "Sixth Edition sources are much more widely available than earlier versions, thanks largely to the Lions book" is I believe incorrect, though; I reckon it's because V6 was so widely distributed, both inside and outside Bell. Many more copies -> higher probability of retention. Also, from 'Source code listing for the Lions' Commentary in PDF and PostScript': "in 1988 I discovered an old 9-track tape being discarded of a PDP11 backup. It was hard to determine what it was running, but it did have an intact /usr/src/ tree of which most of the files were timesamped 1979, even at that time it seemed ancient. So it was either 7th edition or a derivative like PWB, which I believe it was. Do you still have the tape, or its contents? Noel

5 years, 3 months

1
0
0 0

Re: [TUHS] First appearance of named pipes

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > The paper is from late 1981. ... When did FIFO's become a > standard Unix feature? Err, V4? :-) At least, that's when pipes arrived (I think - we don't have V4 sources, but there are indications that's when they appeared), and a pipe is a FIFO. RAND ports just allowed (effectively) a pipe to have a name in the file system. The implementation of both is pretty straight-forward. A pipe is just a file which has a maximum length, after which the writer is blocked. A port is just a pipe (it uses the pipe code) whose inode appears in the file system. > From: Clem Cole > I think the code is on one of the 'USENIX' tapes in Warren's archives. Doc is here: https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6/doc/ipc and sources for all that are here: https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6/dmr https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6/ken (port.c is in 'dmr', not 'ken'where it should be). Noel

5 years, 3 months

16
36
0 0

Article on Unix pipes history

by Warren Toomey

https://toroid.org/unix-pipe-implementation Quite good. Cheers, Warren -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

5 years, 3 months

1
0
0 0

execl and execv, first appearance in unix

by Warner Losh

Greetings, I was reviewing a manual page update and came across an ambiguous answer to a question that came up, so I thought I'd ask here. execl and execv first appear in our extant unix man pages in V4. The v3 and v2 man pages don't have this listed at all. Case closed, right? It appeared in V4. However, the Dennis_v1/unix72 tree has execl.s and execv.s in them. Diving back into the history on Warren's github account, https://github.com/DoctorWkt/unix-jun72/tree/master/src says they come from: "The files in lib/ come from the libc.sa file which is on the last1120c.tar.gz tap(I) tape image, also at the same URL, and form the C library for the above compiler." and "from a working C compiler for 2nd Edition UNIX." which suggests that it may have been in V2 or maybe even V1. It's first use in Unix appears to be V5, but the extant pre-v5 code is so fragmentary it's hard to know for sure. It's not mentioned in section II or section III of v1, v2 or v3. Does anybody know for sure, or can provide more insight into the last1120c.tar.gz file to help disambiguate? Warner

5 years, 3 months

2
4
0 0

I made a tar tape

by Ed Bradford

When I left BTL in 1983, I made a tar tape. A number of years later I translated the tape into a file. Only recently have I wandered through it. I don't know how many people remember Ron Hardin in the Columbus BTL location. He was one of the smartest guys I ever met. There are lot of Ron Hardin stories. One of his creations (as far as I know he authored it) was a program to create Memorandums For File -- technical memorandums. My tar tape scooped up festoon. To this day it compiles and runs happily on Windows 10. It was written in 1978 or thereabouts. Here is an example output: bin$ festoon.exe .TL No Worthynesses .AU "C. C. Festoon" CCF Headquarters 1584734291 .AS A restriction had been being amicated by a convenience at the inclusion. .AE .MT "MEMORANDUM FOR COAT LOCKER" .hy 1 On this occasion, no team responsibilities could have polyesced a renewed emphasis. A friction had penated an activation. At the present moment in time, an undue number of good progresses being collected together with the populations were being proportionately fideated by the fact that there was a data stream which was transenniesced by an issuance being joined together with these team re sponsibilities, because natural basises have been veriating a partitioning. The supplementary work should be conclusively quinquepolyated by a well defined interfacing. A sophisticatedness by a schedule is operated by a nature in conflict with a correspondence under some serious discussi ons. It is within the realm of possibility that the effectiveness had vicfacesced a schedule, but there was not a necessary background information which is being testesced by a strong interest, and a statistical accuracy was tempoesced by the preparation. It should be noted that a joint partnership very repeatedly aidioated this publication of a centralized organization. Due to the fact that there is a simplification which simply enniesced a process, a new technology is fluxesced from monorogatities. It is of the utmost importance that an insurance could be putated by an assumption. A major advance centered about a deficiency octocessates an important outcome. .P An effectation would extramicroate to the situation. A complete revision gravated a direction. Inasmuch as there was not a potential usefulness that cedeates by the timely delivery, a consideration centered around a technique was monofortated by an integration: .BL .LI There is a not unclear meterdom which had risiesced an occasion. .LE .P A clamstress of this enclosedness is cludescing the hemidormity. .P To arrive at an approximation, a large quantity had been chromated by a strong feeling. Moreover, that idea sharing was lusated by a current proposal. Anytime that the final outcomes had been very firmly unpathesced by not unphilaible reasonable compromises, no serious concerns might be being sacrated by internal establishments for the basic objectives in back of a full utili zation. .P As a consequence of the fact that a total effect might vacate an easily situational beneficial assistance, the apparent provisioning being effectuated by a continuing difference can have protenesced a realization of an underly ing purpose. A different doubtful important outcome is cludated by a capkin. A rationale had fortated attachments. Moreover, this assumption had nilcoresced the continuing study. .P .H 1 "An Easily Added Basic Assumption Being Joined Together With A Concept Stage" There is not an impediment which neoated a restriction, therefore. A couple utilizations could morsate a great similarity at considerable difficulties, but an input is primescing the concept activities, and a growing importance was hemicisesced by that beneficial assistance. In the same connection, these extremenesses are rather usefully ultralucesced by directions. .SG .NS 0 C. R. Glitch S. A. Hobble R. S. Limn M. Shayegan .NE Ed Bradford, Ph.D. Physics, retired from IBM BTL 1976-1983 -- Advice is judged by results, not by intentions. Cicero

5 years, 3 months

11
14
0 0

Re: [TUHS] The most surprising Unix programs

by jnc＠mercury.lcs.mit.edu

> From: Dagobert Michelsen > the excellent book "G=C3=B6del, Escher, Bach: An Eternal Golden Braid" > from Douglas R. Hofstadter which also gives a nice introduction into > logic and philosopy. IIRC, the focus of the book is how systems made out of simple components can exhibit complex behaviours; in particular, how information-processing systems can come to develop self-awareness. > From: Chet Ramey > One of the best books I read in high school. A book on a very similar topic to GEB, which was _extremely_ important in developing my understanding of how the universe came to be, is "Recursive Universe", by William Poundstone, which I recommend very highly to everyone here. It's still in print, which is really good, because it's not as well known as it should (IMO) be. It uses an analogy with Conway's Life to explain how the large-scale structure of the universe can develop from a random initial state. Buy it now! Noel

5 years, 3 months

1
0
0 0

Re: [TUHS] RPN (was The most surprising Unix programs)

by Doug McIlroy

Sorry to flog this topic, but the two examples below are an unfair comparison. What happened to the multiplications in the second? And two of the [enter]s in the first are unnecessary. Ironically three of the four operations in the second are actually reverse Polish! If you had to utter sqrt first, as we do on paper and in speech, things wouldn't look so great. [a] [enter] [a] [enter] [multiply] [b] [enter] [b] [enter] [multiply] [add] [square root] [a] [square] [plus] [b] [square] [square root] Doug

5 years, 3 months

3
2
0 0

The most surprising Unix programs

by Doug McIlroy

Once in a while a new program really surprises me. Reminiscing a while ago, I came up with a list of eye-opening Unix gems. Only a couple of these programs are indispensable or much used. What singles them out is their originality. I cannot imagine myself inventing any of them. What programs have struck you similarly? PDP-7 Unix The simplicity and power of the system caused me to turn away from big iron to a tiny machine. It offered the essence of the hierarchical file system, separate shell, and user-level process control that Multics had yet to deliver after hundreds of man-years' effort. Unix's lacks (e.g. record structure in the file system) were as enlightening and liberating as its novelties (e.g. shell redirection operators). dc The math library for Bob Morris's variable-precision desk calculator used backward error analysis to determine the precision necessary at each step to attain the user-specified precision of the result. In my software-components talk at the 1968 NATO conference on software engineering, I posited measurement-standard routines, which could deliver results of any desired precision, but did not know how to design one. dc still has the only such routines I know of. typo Typo ordered the words of a text by their similarity to the rest of the text. Typographic errors like "hte" tended to the front (dissimilar) end of the list. Bob Morris proudly said it would work as well on Urdu as it did on English. Although typo didn't help with phonetic misspellings, it was a godsend for amateur typists, and got plenty of use until the advent of a much less interesting, but more precise, dictionary-based spelling checker. Typo was as surprising inside as it was outside. Its similarity measure was based on trigram frequencies, which it counted in a 26x26x26 array. The small memory, which had barely room enough for 1-byte counters, spurred a scheme for squeezing large numbers into small counters. To avoid overflow, counters were updated probabilistically to maintain an estimate of the logarithm of the count. eqn With the advent of phototypesetting, it became possible, but hideously tedious, to output classical math notation. Lorinda Cherry set out to devise a higher-level description language and was soon joined by Brian Kernighan. Their brilliant stroke was to adapt oral tradition into written expression, so eqn was remarkably easy to learn. The first of its kind, eqn has barely been improved upon since. struct Brenda Baker undertook her Fortan-to-Ratfor converter against the advice of her department head--me. I thought it would likely produce an ad hoc reordering of the orginal, freed of statement numbers, but otherwise no more readable than a properly indented Fortran program. Brenda proved me wrong. She discovered that every Fortran program has a canonically structured form. Programmers preferred the canonicalized form to what they had originally written. pascal The syntax diagnostics from the compiler made by Sue Graham's group at Berkeley were the mmost helpful I have ever seen--and they were generated automatically. At a syntax error the compiler would suggest a token that could be inserted that would allow parsing to proceed further. No attempt was made to explain what was wrong. The compiler taught me Pascal in an evening, with no manual at hand. parts Hidden inside WWB (writer's workbench), Lorinda Cherry's Parts annotated English text with parts of speech, based on only a smidgen of English vocabulary, orthography, and grammar. From Parts markup, WWB inferred stylometrics such as the prevalance of adjectives, subordinate clauses, and compound sentences. The Today show picked up on WWB and interviewed Lorinda about it in the first TV exposure of anything Unix. egrep Al Aho expected his deterministic regular-expression recognizer would beat Ken's classic nondeterministic recognizer. Unfortunately, for single-shot use on complex regular expressions, Ken's could finish while egrep was still busy building a deterministic automaton. To finally gain the prize, Al sidestepped the curse of the automaton's exponentially big state table by inventing a way to build on the fly only the table entries that are actually visited during recognition. crabs Luca Cardelli's charming meta-program for the Blit window system released crabs that wandered around in empty screen space nibbling away at the ever more ragged edges of active windows. Some common threads Theory, though invisible on the surface, played a crucial role in the majority of these programs: typo, dc, struct, pascal, egrep. In fact much of their surprise lay in the novelty of the application of theory. Originators of nearly half the list--pascal, struct, parts, eqn--were women, well beyond women's demographic share of computer science. Doug McIlroy March, 2020

5 years, 3 months

21
31
0 0

Re: [TUHS] The most surprising Unix programs

by Nelson H. F. Beebe

Tomasz Rola writes on Thu, 19 Mar 2020 21:01:20 +0100 about awk: >> One task I would be afraid to use awk for, is html processing. Most of >> html sources I look at nowadays seems discouraging. Extracting >> anything of value from the mess requires something more potent, I >> think. If you want to tackle raw HTML from abitrary source, then I agree with you: most HTML on the Web is not grammar conformant, there are numerous vendor extensions, and the HTML is hideously idiosynchratic and irregularly formatted. The solution that I adopted 25 years ago was to write a grammar recognizing, but violation lenient, prettyprinter for HTML. It has served well and I use it many times daily for my work in the BibNet Project and TeX User Group bibliography archives, now approaching 1.55 million entries. The latest public release is available here: http://www.math.utah.edu/pub/sgml/ I notice that the last version there is 1.01; I'll get that updated in a couple of days to the latest 1.03 [subject to delays due to major work dislocations due to the virus]. The code should install anywhere in the Unix family without problems: I build and validate it on more than 300 O/Ses in our test farm. With standardized HTML, applying awk is easy, and I have more than 450 awk programs, and 380,000 lines of code, that process publisher metadata to produce rough BibTeX entries that numerous other tools, and some manual editing, turn into clean data for free access on the Web. For some journals, I run a single command of fewer than 15 characters to download Web pages for journal issues for which I do not yet have data, and then a single journal-specific command with no arguments that runs a large shell script with a long pipeline that outputs relatively clean BibTeX that then normally takes me only a couple of minutes to visually validate in an editor session. The major work there is bracing of proper nouns in titles that my software did not already handle, thereby preventing downcasing of those words in the many bibliography styles that do so. I'm on journal announcement lists for many publishers, so I often have new data released to the Web just 5 to 10 minutes after receiving e-mail about new issues. The above-mentioned archives are at http://www.math.utah.edu/pub/bibnet http://www.math.utah.edu/pub/tex/bib http://www.math.utah.edu/pub/tex/bib/index-table.html http://www.math.utah.edu/pub/tex/bib/idx http://www.math.utah.edu/pub/tex/bib/toc They are mirrored at Universität Karlsruhe, Oak Ridge National Laboratory, Sandia National Laboratory, and elsewhere. Like Al Aho, Doug McIlroy, and Arnold Robbins, I'm a huge fan of awk; I believe that I was the first to port it to PDP-10 TOPS-20 and VAX VMS in the mid-1980s, and it is one of the first mandatory tools that I install on any new computer. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

5 years, 3 months

4
4
0 0

calculators

by Steve Simon

i never got on with rpn, even though i am the kind if person who should - i have a little bit of dyslexia, perhaps thats why. when i moved to plan9 i found it included hoc from K&P, just used that for the odd bits of maths i need. -Steve

5 years, 3 months

1
0
0 0

Unix on Zilog Z8000?

by Jon Forrest

There's been a lot of discussion about early Unix on Intel, National Semi, Motorola, and Sparc processors. I don't recall if Unix ran on the Z8000, and if not, why not. As I remember the Z8000 was going to be the great white hope that would continue Zilog's success with the Z80 into modern times. But, it obviously didn't happen. Why? Jon

5 years, 3 months

18
25
0 0

Re: [TUHS] Unix 8th / 9th edition IPC paper

by Clem Cole

I sent it off list to Chet and Paul but it's too big for Warren's reflector. I'll work with him to get it separately. If anyone else wants it before, please let me know off list. Clem On Mon, Mar 16, 2020 at 10:37 AM Clem Cole <clemc(a)ccc.com> wrote: > Here you go... > > Warren - Would please be able to add to the docs/paper directories... > USENIX Summer 1985 June 11-14 >

5 years, 3 months

1
0
0 0

BSD Net/2 Updates from CSRG

by Dan Plassche

Hi, Would anyone know how the CSRG made available updates to the public distribution of Net/2 before releasing 4.4 BSD Lite? Net/2 was released on tape in July 1991 as represented in the TUHS archive. The first mention I see of the sources appearing online is old usenet posts announcing the bsd-sources mirror on uu.net starting in January 1992. However, the Net/2 derived versions of NetBSD (0.8-0.9) and FreeBSD (1.0-1.1.5.1) imported userland tools revised after both dates in early 1993, when there are also mentions of using 4.4 code in the commit logs (well before Lite 1 was released in March 1994). At this point, I'm wondering if the latest code was issued on tape at the time of a request for Net/2 sources and there were direct uploads from the CSRG to any online mirrors before the USL lawsuit? Thanks, Dan Plassche -- Dan Plassche

5 years, 3 months

1
0
0 0

Re: [TUHS] Command line options and complexity

by Dave Horsfall

Meant for the list (and don't get me started on Reply All)... -- Dave ---------- Forwarded message ---------- Date: Fri, 13 Mar 2020 21:43:51 +1100 (EST) From: Dave Horsfall <dave(a)horsfall.org> To: Greg 'groggy' Lehey <grog(a)lemis.com> Subject: Re: [TUHS] Command line options and complexity On Fri, 13 Mar 2020, Greg 'groggy' Lehey wrote: >> -h is a gnuism, isn't it? > > It might have originated there, but then I would expect it to be spelt > '--produce-human-readable-output'. I haven't been able to establish from the > FreeBSD sources or commit logs when it was introduced. It would clearly have > been a reimplementation. It's in "df" as well, praise Cthulu: aneurin# df -h Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 496M 302M 154M 66% / devfs 1.0K 1.0K 0B 100% /dev tmpfs 1000 272K 999M 0% /tmp /dev/ad0s1d 2.9G 1.4G 1.2G 54% /usr /dev/ad0s1e 989M 581M 329M 64% /var /dev/ad0s1f 3.9G 2.2G 1.4G 62% /home /dev/ad0s1g 8.9G 8.0G 127M 98% /usr/local fdescfs 1.0K 1.0K 0B 100% /dev/fd procfs 4.0K 4.0K 0B 100% /proc (Memo to self: see where all the room has gone in /usr/local, as that's where I assigned the leftover space after the other partitions.) No, I've never liked stuffing everything under the root file system as both the Mac and Penguin do; fill the root file system and you're hosed (and I also have an itch about /tmp being there as it's a world-writable directory). >> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html does >> specify the -S switch. That's POSIX, isn't it? > > So it is! This was the first option that I wanted to add, back when I still > had practice wheels. I asked my mentor, and he said "not the Unix way", so I > let it be. Then Wes Peters came up with the idea, and I thought he committed > it, but it seems that it ultimately came from Kostas Blekos in 2005, based on > the same feature on NetBSD and OpenBSD. I wonder when it made it to POSIX. Years ago I wrote a simple script "lss" which did the sort after being howled down on one of the FreeBSD lists; what a surprise to see "-S"... Heck, back in my UNSW days I suggested extending stty() to cover non-TTY devices and got trashed by the AGSM/ElecEng mob; well well, look at ioctl() when it appeared. -- Dave

5 years, 3 months

4
3
0 0

Re: [TUHS] Command options and complexity

by Doug McIlroy

> -,: Make the option standard: output numbers with commas every 3 digits A terrible idea. Whatever ls outputs should be easy for other programs to read, and few know how to read commafied numbers. As others have mentioned, this is also a strong argument for changing the output representation of dates. I often do mailx -H | sort -t/ -k2nr to sort in reverse order of size--a quick way to find the pay dirt when I want to shrink my mailbox. This would never fly if the sizes had commas. (Well, I suppose I could add sed s/,//g to the pipeline.) Doug

5 years, 3 months

5
4
0 0

Command line options and complexity

by Jon Steinhart

OK, this should be good for some conversation. A friend sent me this link today: http://danluu.com/cli-complexity/

5 years, 3 months

18
34
0 0

Re: [TUHS] Command line options and complexity

by John P. Linderman

Nothing I'm aware of. I didn't mind throwing "tac" over the wall, because it was trivial, probably a couple hours work for me, under a minute for Ken. But the rsort source is not at all trivial, and still of potential value to AT&T. The source managed to get out as part of the "Hancock" project. I found a link in https://www.wired.com/2007/10/att-invents-pro/ but the page is gone. It probably didn't help that Wired titled the article *AT&T Invents Programming Language for Mass Surveillance* That's horse-pucky, akin to "Pitchfork makers invent device for spearing babies". I'm trying to track down a copy that was released publicly. I'm not hopeful. On Mon, Mar 9, 2020 at 11:28 AM Tyler Adams <coppero1237(a)gmail.com> wrote: > Woah, this sounds really useful, is there anything like it today? > > On Sun, Mar 8, 2020, 16:32 John P. Linderman <jpl.jpl(a)gmail.com> wrote: > >> In the "UNIX SYSTEM" issue of the BSTJ back in October of 1984, I >> suggested that it might be better, both for functionality *and* >> performance, to have a sort that only worked on records with a *single* >> key to be sorted *lexicographically*, and put all the complexity of >> dealing with native integers, dates, case-mapping, etc into a key-building >> front end. I wrote such a sort built around a radix sort. The sort >> itself sported very few options relating to record format (fixed-length, >> newline terminated, and header-based, where an ascii header identified >> record length, and, optionally, key position and key length), where to find >> the key in fixed-length and newline terminated records, merge-only, check >> sort order only, unique, strip off the sort key (to avoid the need for a >> post-process in many cases). Key-building was usually near-trivial using >> awk or perl or a few commands for tweaking native integer and floating >> point values so they would sort lexicographically. The sort was stable and >> blazingly fast. Some summer students once complained to me that I was >> messing up a paper they were writing because my external sort was faster >> than an internal qsort... the kind of complaint that warms one's heart. At >> the back of my mind was a generic key-building library that would >> accommodate (decimal) numbers of arbitrary length, with or without "E" >> exponents, dates in various formats, string collation for Unicode, etc. It >> remains at the back of my mind. >> >> On Sun, Mar 8, 2020 at 5:32 AM Tyler Adams <coppero1237(a)gmail.com> wrote: >> >>> The idea of a simple rule is great, but the suggested rule fails on sort >>> -u which afaik came after sort | uniq for performance reasons. >>> >>> Another idea on the same vein is that a flag should be added only when >>> the job can be done inside the program and not with stdin/stdout (or no >>> flag can be added if one can reproduce the same behavior using pipelines). >>> >>> So, you need sort -u because only within sort can you get the >>> performance needed to get the job done. >>> >>> But you don't need -h in ls -lh. All the information to render a human >>> readable number is present on stdout of ls -l. You could easily have a >>> filter which renders numbers with options like adding commas, dots, >>> scientific notation, precision, money, units, etc. >>> >>> Tyler >>> >>> On Sun, Mar 8, 2020, 07:33 Jon Steinhart <jon(a)fourwinds.com> wrote: >>> >>>> After following this discussion, I guess that I have a simplistic way to >>>> determine whether something should be a dash option or a filter. In >>>> general, I'd make a filter if whatever it was doing was applicable to >>>> more than one command, a dash option otherwise. >>>> >>>> Jon >>>> >>>

5 years, 3 months

5
7
0 0

Re: [TUHS] eqn anomaly

by norman＠oclsc.org

On (post-)V10: echo '.EQ define f % $1 % f("a,b") .EN' | eqn emits .lf 1 - .EQ .ds 11 "\f2a,b\fP .if 1m>\n(.v .ne 1m .rn 11 10 \&\*(10 .EN .lf 5 On a Linux system with GNU eqn (groff) version 1.22.3, the output is rather more verbose (48 lines!), but the troff result is just an a (rather than the proper a,b) and eqn complains eqn:<standard input>:3: newline before end of quoted text I assume this Linux result is more or less what Doug expects. Norman Wilson Toronto ON (still heating my basement with a MicroVAX)

5 years, 3 months

1
0
0 0

Re: [TUHS] eqn anomaly

by Doug McIlroy

I was surprised that eqn parses the macro call below as having two arguments, each with an unmatched ". .EQ define f % $1 % f("a,b") .EN Ralph Corderoy found that the comma can be hidden by replacing it with \N'44'. A somewhat cleaner way to hide it is .EQ define f % $1 % define comma % , % f(a comma b) .EN This works too. .EQ f(f(a comma b)) .EN [Note for cognoscenti. Eqn's practice in expanding macro arguments clashes with troff's. Eqn expands nested calls after substitution in the outer macro definition; troff expands while collecting arguments of the outer call. I've found no documentation of the eqn behavior.] The classical man page for eqn asserts categorically, `Strings enclosed in double quotes " " are passed through untouched.' Unfortunately the version of Kernighan/Cherry User's Guide that describes macros with arguments says little about how arguments are parsed except that they are separated by commas--nothing about whether commas are hidden by parentheses or quotes. Certainly splitting at a comma in a quoted string violates the plain meaning of the man-page assertion. If anyone has v10 (or perhaps something else after v7) running, I'd be grateful to learn what classic eqn actually did. I'm morally certain that if it did split and anyone had complained to Brian, he would have fixed it. These observations lead me to file a bug report. Doug

5 years, 3 months

1
0
0 0

Re: [TUHS] Command line options and complexity

by Doug McIlroy

> This begs questions of stability Astute question. I had that in my original draft, but eliminited it for what I thought was clarity. Anyway, depending on implementation of sort, you may need sort -s. Of course it doesn't matter which copy among several equal lines uniq produces, nor does it matter in sort when there are no comparison options--they're all the same. > I don't know enough about the > internals of sed to know even what algorithm it uses > (... a disk-based merge sort?) sed is not a sorting program--basically it copies input to output, making line-by-line editing changes. That's the way I meant to use it in sed s/nonkeys//|sort -keys|uniq. (I have added options to sort, hopefully for clarity). The argument to sed here means substitute the empty string for the nonkey fields (specified by a regular expression). If "sed" was a typo for "sort", all versions of sort that I know of use an internal sorting algorithm for big chunks of the file, then combines the chunks by merge. But internal sorting varies all over the map--variations on quicksort, radix sort, merge sort, ... Doug

5 years, 3 months

2
1
0 0

Re: [TUHS] Command line options and complexity

by Doug McIlroy

> The idea of a simple rule is great, but the suggested rule fails on sort -u > which afaik came after sort | uniq for performance reasons. As the guilty party for most of sort's comparison options, I can attest that efficiency was not an objective of -u. It was invented precisely because uniq had proved useful, but not when one was interested in uniqueness only of some key aspect of the data. -u differs from uniq in that -u selects samples based on equality of keys, not equality of lines. In the default case of whole-line keys, sort -u of course does exactly what sort|uniq does. For many applications of -u with keys, the non-key fields are not of interest. Then sed s/nonkeys//|sort|uniq may suffice. But sed did not exist when -u was invented. And not all sort key specs are easily imitated in sed. Doug

5 years, 3 months

3
3
0 0

sockets (was Re: First appearance of named pipes)

by Norman Wilson

Derek Fawcus: Yeah - I always found that a bit weird, having to use socketpair() to get a bidirectional "pipe". In the Research system, pipes became bidirectional when they became streams. That happened slightly before my time, but so far as I know it broke absolutely nothing. Some time in the late 1980s, the System V people wanted to allow pipes to be streams, but were worried about the bidirectionality. They proposed to have a new system call to make a bidirectional pipe. I attended a meeting with the relevant programmers and program manager to find out why they thought pipes couldn't just be bi-directional, as they had been without fuss in the Research system for some years. They agreed with me that that was how it ought to be; the trouble was that System V releases all had to pass an official System V Verification Suite (reasonable enough), and that suite checked not only that you could read the one pipe file descriptor and write the other, but that you couldn't do it the wrong way. Wait a minute, I said. I'm pretty sure that's not how the official System V Interface Description reads. Anyone got a current copy handy? We found one, and we looked, and sure enough, the official verification suite was wrong. The specification said that data written to fd[1] must be readable from fd[0], but nothing about the other direction: full-duplex pipes were not required but neither were they outlawed! The programming group was delighted: I'd given them the ammo they needed to do it right (make pipes streams, and make them full-duplex by default). I believe that is how it came out, though the only reference I have is Solaris 10, where the manual page specifically says that what pipe(2) makes is full-duplex (and a stream). I wish POSIX and Linux and the BSDs would catch up; that was only 30 years ago. Norman Wilson Toronto ON

5 years, 3 months

2
1
0 0

First appearance of named pipes

by Paul Ruizendaal

> Always bemused me that to get a named local I/O connection one ended up with "Unix domain (what does that even mean?) sockets" rather than named pipes, especially since sockets are about as natural a Unix concept as lawn mowers. I've been told, but haven't confirmed, that early sockets didn't even support read and write. They still don't support open and close, and never will. My interest in Unix networking 1975-1985 originally came from wondering how we came up with this alien feeling socket API as the dominant model. The original ideas for this API are in the recently found CSRG tech reports #4 and #3 - which I hope to discuss on this list in Spring. I think we have to distinguish the API and the underlying paradigms. When it comes to the “Arpa” lineage of Unix networking, the original API model was fully within the open-read-write-close framework. See for instance RFC681 and this document: https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-Vax-TCP/doc/net.5.P; the entire BBN network API model fits on a few pages of ‘man’ text. In 1975 Arpa Unix, the network name space was integrated with the file name space, by creating a character special file for each network host. This was possible because at that time an Arpa network address was 8 bits, and this fitted in the minor number; when Arpa addresses were expanded to 24 bits soon after this approach was abandoned (but one could think of a mechanism akin to symbolic links that could have continued the practice). One could have an entry for the local host, e.g. “/n/local” or something like that. In my mind, “socket” does not only refer to the sockets API, but also to the concept of a bi-directional, possibly remote, named pipe; ‘named' as in “discoverable by a possibly unrelated process”, i.e. the in file name space, the network name space if different, etc. [aside: I realise (now) that this is a confusing use of the word socket, but I don’t have a better phrase at hand.] In my opinion, it is this concept that has proven strong and durable, much more so than the socket API itself. When viewed in this definition a ‘fifo’ is a limited form of socket: it is unidirectional, local only (although in the 1981 S/F-Unix it wasn’t) and a server process cannot easily distinguish or delegate individual client connections. The Rand Port was better in the sense that it prefixed each client’s data with a header block. > Networks are not intrinsically more special than any other I/O peripheral, but they have become gilded unicorns mounted on rotating hovercrafts compared to the I/O devices Unix supported before them. -rob "Networks are not intrinsically more special than any other I/O peripheral”: that indeed is the paradigm that underlies Spider-Datakit-streams-STREAMS-Plan9, networks are just an I/O peripheral. There is nothing wrong with that paradigm, excellent systems can be built on top of it. The other paradigm is that the network is a (mostly hidden) substrate that carries bidirectional pipes between processes. It would seem to me that there is nothing wrong with that paradigm either and it can be implemented in a “natural Unix” way as well. > On Sun, Mar 8, 2020 at 3:48 AM Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote: > >> > On Sat, Mar 07, 2020 at 01:17:09PM +0100, Paul Ruizendaal wrote: >> > > >> > > Interestingly, Luderer also refers to a 1978 paper by Steve Holmgren (one of the Arpa Unix authors), suggesting ’sockets’ (in today’s parlance) for interproces communication. >> > >> > Could that simply be bleed over of terminology from the ARPAnet / Internet >> > usage, in that "socket" is used to refer to protocol end points? I meant ’socket’ in the sense that I described above. “Socket” must be one of the most overloaded words in networking. My understanding is that on the Arpanet the “socket number” was what we now would call a "port number”, although I think it was initially meant to identify a user on a host, rather than a service on a host. In the 1980 BBN TCP implementation “socket” is used to mean “ip address”. A year later, Bill Joy uses “socket” as an API call name. >> > >> > i.e. see these from 1970: >> > >> > https://tools.ietf.org/html/rfc54 >> > https://tools.ietf.org/html/rfc55 >> > https://tools.ietf.org/html/rfc60 >> > >> > DF

5 years, 4 months

2
1
0 0

Re: [TUHS] Command line options and complexity

by Nelson H. F. Beebe

Arnold Robbins writes: >> There was no tac in V7 Unix. It was first posted to USENET, I don't >> know by who, and picked up by Linux and *BSD. That brought back memories, and to verify them, I checked the tac.c source code in the latest GNU coreutils test release. It says /* Written by Jay Lepreau (lepreau(a)cs.utah.edu) GNU enhancements by David MacKenzie (djm(a)gnu.ai.mit.edu) */ So my memory was right that my old friend Jay was the author. Sadly, we lost him in September 2008: see https://www.legacy.com/obituaries/saltlaketribune/obituary.aspx?page=lifest… Jay founded the influential Flux group in advanced networking research: http://www.flux.utah.edu/profile/lepreau ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

5 years, 4 months

13
12
0 0

First appearance of named pipes

by Paul Ruizendaal

The Luderer paper on distributed Unix has the following paragraph: "A new special UNIX interprocess communication mechanism is the fifo, which provides communication between unrelated processes by associating a new special file type with a file name. Since remote fifos are legal, they can be used for interprocessor communication between S-UNIX machines or between an S-UNIX machine and an F-UNIX machine.” The paper is from late 1981. Maybe I’m especially mud-eyed today, but I cannot see FIFO’s implemented in V7..V8 or 4.1xBSD. When did FIFO’s become a standard Unix feature? Paul

5 years, 4 months

3
3
0 0

Re: [TUHS] Command line options and complexity

by Doug McIlroy

> These go all the way back to v7 unix, where ls has an option to reverse the sort order (which could have been done by passing the output to tac). A cool idea, but tac was not in v7. And tail didn't get the -r option until v8. As for rev, I don't know why it was first written, but one use was to examine suffixes--a kind of thing that several word lovers in the Unix lab were prone to do. Apropos of using rev to make rhyming dictionaries, Walker's Rhyming Dictionary was published decades before Noah Webster's dictionary appeared and stayed in print for about 200 years. Notionally the relation between webster and walker is rev <webster | sort | rev >walker Doug

5 years, 4 months

2
1
0 0

Early Datakit

by Paul Ruizendaal

I’m making a little progress with early Datakit & Unix. It would seem that there were various experimental protocols before URP was arrived upon. The first protocol appears to have been designed by Chesson in 1979. One Fraser paper says: ""The first Datakit protocols used a packet structure that was aligned with cell boundaries. Chesson designed a file transfer protocol that transported data in variable length packets, each ending with a trailer.” I think this protocol is being described in his paper "Datakit Software Architecture” (vol. 2, pp. 20.2.1-20.2.5 Proceedings of the IEEE Int. Conf. on Communications, June 1979, Boston) - which unfortunately does not seem to be available in the IEEE online library. Maybe it will surface some day. Next there was a protocol tied to a Datakit terminal interface board that used an 8-slot packet sequence/acknowledge mechanism that carried over into URP. Not much appears to have been published about this. The most interesting experiment seems to have been a project by Luderer, Che and Marshall to build a Datakit-based distributed Unix in 1980/81. Marshall is credited by Fraser as one of the inventors of the URP protocol. The papers are “A virtual switch as the basis for distributed systems” and “A distributed unix system based on a virtual circuit switch” (available online from the ACM library). The first has a good overview description of how early Datakit worked (including interface hardware) and describes the Network Kernel or “NK protocol”. It would seem that URP combines the flow & retransmission control from the terminal interface board with the concept of a single simple receiver algorithm from NK. Unfortunately the paper does not describe the design of the NK transmitter algorithm(s). It confirms that everything ran on V7, but it remains unclear how the Datakit channels were exposed to the user (I currently assume as a cluster of character devices, with the major number identifying the switch connection and the minor number identifying the channel - similar to what later would be used in V8). The second has a description of a modified Unix system, where clients (“S-Unix”) talk to file servers (“F-Unix”), with the file servers mounted into the local file tree of the client. This appears to predate the work of Weinberger for the V8 network file system and its implementation appears different. Questions: - Are Luderer, Che and Marshall still around? (especially Bill Marshall might still recall some more details of the genesis of the URP protocol) - Any recollections about S/F-Unix and how it did or did not influence V8-V10/Plan9?

5 years, 4 months

1
0
0 0

Full set of "Computing Systems" for the cost of shipping

by arnold＠skeeve.com

Hi All. I have a full set (hardcopy) of the USENIX "Computing Systems" journal. It's just sitting on my shelf taking up space, and I'd like to give them to someone who'll give them a good home. So, first person to reply to me directly, who's willing to pay shipping from Israel, gets them. (Payment via paypal, or preferably a US dollar check sent to my US address.) Thanks! Arnold

5 years, 4 months

1
1
0 0

What was the release history timeline of Ultrix for VAX/MicroVAX?

by Pat Barron

I was just discussing this with someone today, and I realized this information has fallen out of working memory, and I can't find it on secondary storage anywhere... ;-) Does anyone remember the release history and version numbering of Ultrix for the VAX and MicroVAX (which I believe was referred to at various times as Ultrix-32 and Ultrix-32M, until some point when the "-32" thing was dropped, I think?) I was trying to remember what the various released versions of Ultrix were. The person I was discussing with thinks he remembers a version 1.4 and 1.6, before Ultrix 2.0. I honestly don't remember any 1.x version beyond 1.2. Is there a timeline somewhere? --Pat.

5 years, 4 months

1
0
0 0

First COFF Video Session in ~22 hours

by Warren Toomey

All, I've had a few queries about the proposed video chat sessions, so I'll kick the first one off tomorrow: UTC Brisbane London New York Friday, 28 Feb 2020 at 21:00 Sat 7:00am Fri 9:00pm Fri 4:00 pm I'll only be able to stay for an hour but the chat session should continue when I've gone. URL: https://meet.tuhs.org/COFF Password: unix Cheers, Warren

5 years, 4 months

1
0
0 0

Re: [TUHS] Crabs

by Lawrence Stewart

This explains something, I think! Luca Cardelli and Mark Manasse later worked at the Digital Systems Research Center in Palo Alto, which was formed in 1984 after PARC fired Bob Taylor. Mark helped write the window system we used, and at some point a cat appeared, which would sleep until you moved the mouse and then come over to pat at the mouse. My impression was that Luca wrote it, be he was cagy about it. This later evolved into xneko for X Windows. -Larry

5 years, 4 months

3
3
0 0

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