- TUHS - www.tuhs.org

by Dave Horsfall

Co-inventor of Unix, he was born on this day in 1943. Just think: without those two, we'd all be running M$ Windoze and thinking that it's wonderful (I know, it's an exaggeration, but think about it). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 3 months

15
20
0 0

And .. a reminder of the charter of the TUHS list

by Warren Toomey

TUHS: The Unix Heritage Society So topics that relate to Unix, its development, old Unix systems, Unix anecdotes please! Thanks, Warren

7 years, 3 months

1
0
0 0

Re: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!)

by Doug McIlroy

> My experience is that the problems involved in making a program faster are > often quite interesting and fun to work on. But the problems making things > fit in a small space are, IMHO, really deadly. First make things "as simple as possible, but no simpler" (Einstein). Ken and Dennis not only cut out fat, they also found generalizations that combined traditionally disparate features, so the new whole was smaller (and more comprehensible) than the sum of the old parts. The going gets tough in the presence of constraints on space or time. Steve's perception, I think, is colored by the experience of facing hard limits on space, but not on time. Describing one complication of hard time constraints, John Kelly used to say that the Packard Bell 250 was "the only machine I ever used where you transfer to a time of day rather than a memory location". (The delay- line memory had two instruction formats: one was operation + address-of- next-instruction, the other was just the operation--the next instruction being whatever came out of the delay line when the operation ended. The latter mode minimized both execution time and code space, but the attention one had to pay to time was, to borrow Steve's phrase, "really deadly".) Design tradeoffs for efficiency pose an almost moral conundrum: whether to make things fast or make them easy. For example, the classic Unix kernel typically did table lookup by linear search, whereas Linux (when I last looked) typically used binary search. The price of Linux's choice is that one must take care to keep the tables sorted. Heavy discipline has to be imposed on making entries and deletions. Doug

7 years, 3 months

1
0
0 0

Re: [TUHS] Happy birthday, Ken Thompson!

by Daniel Camolês

What do you mean plan9 is dead? It's even possible make a facebook post from inside plan9 nowadays! https://twitter.com/bigatojj/status/949838932841201664 See vmx(1) Em 3 de fev de 2018 23:25, "Steve Simon" <steve(a)quintile.net> escreveu: Hi, I have to take issue with the “plan9 is dead” statement, I agree it seems on a downward spiral, but are a few who fight on. [sent from my plan9] -Steve

7 years, 3 months

2
1
0 0

Fwd: [math-fun] Outside In written accompaniement

by William Cheswick

Concerning the sphere eversion video, Tamara writes: > > There's a DVD-supplement bundle that includes a single DVD and the two hardcopy supplements for both Outside In and Not Knot. > https://www.amazon.com/Outside-Not-Knot-DVD-Booklets/dp/1568814534 <https://www.amazon.com/Outside-Not-Knot-DVD-Booklets/dp/1568814534> > https://www.crcpress.com/Outside-In-and-Not-Knot-DVD--two-Booklets/The-Geom… <https://www.crcpress.com/Outside-In-and-Not-Knot-DVD--two-Booklets/The-Geom…> > > That's the only way to get access to the written supplements, they're not posted online. I don't even have the PDF of either one of these in my own possession, I tried to hunt those down when I converted the original master videos onto the DVD version in 2009 but those files have gotten lost in the mists of time... > > So you could order the bundle just for access to the booklets! The Not Knot one is black and white rather than color, but a similar level of care went into the mathematical exposition for that one too. > > Cheers, Tamara > > ---- > Tamara Munzner > Professor, Department of Computer Science, University of British Columbia > http://www.cs.ubc.ca/~tmm <http://www.cs.ubc.ca/~tmm>, tmm(a)cs.ubc.ca <>

7 years, 3 months

1
0
0 0

Re: [TUHS] Happy birthday, Ken Thompson!

by Daniel Camolês

You can use make as much as you like; Go just doesn't need it. You can use Go to fetch code from internet if you like, or you can do it yourself if you prefer. Regarding the "hardwired" directories, you can change it through an environment variable. Em 3 de fev de 2018 23:20, "Lyndon Nerenberg" <lyndon(a)orthanc.ca> escreveu: That's the second endorsement I've seen for Go; I guess I should learn it. > In the scheme of "current" languages, Go is pretty good. With two major caveats, IMO: 1) The build system. It doesn't work with make(1). That makes it a non-starter for anything other than trivial projects at $WORK. While I appreciate the arguments for the apparent simplicity of the "go" command, that doesn't work for us. Which would have been fine, but for the entirely antagonistic bent they have taken against being able to build Go programs with make(1). Our build environment entirely precludes Go's promiscuous insistence on unfettered internet access, and hardwired directory paths. 2) Hardwired directory paths for the development/build environment (see above). It seems they have unlearned all the UNIX lessons. Sad, really. I would love to toss out Python, Ruby, PHP, Perl, et al. And could make the argument for it, I think. But the build environment will never work in our shop, therefore Go won't either. And that ... sucks.

7 years, 3 months

2
1
0 0

Happy birthday, Ken Thompson!

by Norman Wilson

Or as we old 1127ers would put it: What day is it, Ken?

7 years, 3 months

1
0
0 0

Dynamics between BSD and Linux

by Kevin Bowling

Hi, Interested in some perspective here since the list has influential Linux people like Ted Tso. Linux has been described as influenced by Minix and System V. The Minix connection is well discussed. The SysV connection something something Linus had access to a spec manual. But I’d guess reality would be more gradual — new contributors that liked CSRG BSD would have mostly gravitated to the continuations in 386/BSDi/Net/Free that were concurrent to early and formative Linux development.. so there’d be an implicit vacuum of BSD people for Linux development. What I am curious about is the continuing ignorance of BSD ideas. Linux isn’t exactly insular; a lot of critical people and components came much later on from other SysV flavors (lvm, jfs, xfs, RCU) The kinds of BSD things I am talking about are ufs, kqueue, jails, pf, Capsicum. Linux has grown alternatives, but with sometimes willful ignorance of other technology. It seems clear epoll was not a good design from the start. Despite jails not being taken to the logical conclusion of modern containers like zones, the architecture is fundamentally closer aligned to how people want to securely use containers versus namespaces and cgroups. And Google ported Capscicum to Linux but it’s basically been ignored in lieu of nebulous concepts like seccomp. And then there seems to be outright hostility toward other platforms from the postmodern generation with things like systemd. This seems strange to me as BSD people are generally open to other /ideas/, we have to be careful with Linux code due to license incompatibility, but the converse is does not seem true either in interest in other ideas or license hampering code flow. The history of UNIX is spectacularly successful because different groups got together at the table and agreeed on the ideas. Is there room for that in the modern era where Linux is the monopoly OS? The Austin Group is still a thing but it’s not clear people in any of the Freenix communities really care about evolving the standards. I get that, but not so much completely burrying ones head in the sand to what other OSes are doing. Is there any future for UNIX as an “open system” in this climate or are people going to go there separate ways? Regards, Kevin

7 years, 3 months

7
10
0 0

Happy birthday, John von Neumann!

by Dave Horsfall

We gained John von Neumann on this day in 1903, and if you haven't heard of him then you are barely human... As computer science goes, he's right up there with Alan Turing. There is speculation that he knew of Babbage's work; see https://cstheory.stackexchange.com/questions/10828/the-relation-between-bab… . -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 3 months

9
9
0 0

Re: [TUHS] Odd behaviour on V6 startup, etc

by jnc＠mercury.lcs.mit.edu

> From: Sergio Pedraja > I am very interested in your work exactly for the reasons you explain We will generally be sending messages about it to the CCTalk list (for collectors of 'classic' computers), so if you want to be notified about it, sign up there. We currently have only wire-wrap prototypes (the FPGA is on an off-the-shelf daughter-card); we're hoping to produce PCB production versions 'soon'. We do have the technology for getting PCB's, which we have used for doing 'indicator panels': http://ana-3.lcs.mit.edu/~jnc/tech/DECIndicatorPanels.html We have those working (they've been a big help in debugging, actually :-), and they'll be available too. I don't personally have one of them yet, I'm _really_ looking forward to watching the lights blink as UNIX boots... :-) > The only difference is that my PDP-11 is one 23/PLUS. There are some > differences between this one and the PDP-11/23 and perhaps your emulator > woudln't work in this PDP-11 model. No, AFAIK the /23 and /23-PLUS are effectively identical, as far as the QBUS goes. (Obviously the -PLUS has devices, etc, the plain /23 doesn't, but they don't enter into whether our board will work with one.) We also plan at UNIBUS version; the two busses are similar enough that we'll probably start with a PCB version for that one. > I will test the working state of my PDP. If all is fine perhaps I could > help doing with some tests on it. Sure; use CCTalk. Noel

7 years, 3 months

1
0
0 0

Odd behaviour on V6 startup, etc

by jnc＠mercury.lcs.mit.edu

As I mentioned recently, Dave Bridgham and I are doing an RK11 emulator (and soon an RP11, which just will take editing the Verilog a tiny bit) using an SD card for storage, for heritage computer collectors who want to run their PDP-11's but don't want to risk a head crash (since replacement heads are now un-obtainium) - and also for people who have an -11, but no mass storage. So the last stage was bringing up V6 on a hardware PDP-11/23, using the emulated RK11, and we were having an issue (which turned out to be partial block reads/writes not working properly; this has since been fixed, and we have successfullly booted V6 on the -11/23 with only an SD card). In the process of debugging that issue, I added logging to the RK driver, and noticed that in the process of attempting to boot single-user, the system was trying to do some swapping - two writes, and two reads - before it even tried doing the fork() to create the shell process, followed by opening /dev/tty8 and doing the exec() of /bin/sh. This confused me, since both newproc() and expand() have code which uses a memory-memory copy if there is enough free memory - and on first booting, there definitely was. Why was it swapping? So I added some more logging, and the cause turned out that at one point, I had re-compiled /etc/init - and without thinking about it too hard, had made it a pure-text program. And that's what did it: in exec() (called when process 1 tries to exec() /etc/init), it calls xalloc(), which i) if the text was not already available, gets together the pure text, and puts a copy on the swap device, and ii) if the text is not already in core, swaps the rest of the process out, because, as the code explains: * if the calling process * is misplaced in core the text image might not fit. * Quite possibly the code after "out:" could check to * see if the text does fit and simply swap it in. If you're looking at the code, the process doesn't have a data segment at that point, just the U area; the data will be set up later in the exec() code, after the call to xalloc() returns, after the process is swapped back in. In fact, the process will _never_ have anything other than a U area when in this code; the only call to xalloc() in the system is immediately preceeded by an "expand(USIZE)" which throws away everything except the U area. So I'm contemplating doing what the comment suggests - adding code to check to see if there's enough memory available to hold the pure text, and if so, avoiding the swap-out/in of the process' U-only data segment. If done 'right', it should also be possible to allow avoiding the reading-in of the text from the swap device, when first exec'ing a pure text... Probably not as interesting a project as doing the splice() system call was, but no doubt it will teach me about a corner of the system I don't know very well (back in the day, doing networking stuff, I was mostly looking at I/O code). Although there is potentially a certain amount of amusement in an additional enhancement, which is trying to make sure there's enough room for both the text and the data; immediately upon the return from xalloc(), the process is expanded to have room for the data. Which might involve _another_ swap-out/in sequence... So perhaps the U area should simply be moved out of the way via a direct memory-memory copy, rather than swapping it out/in, just before doing it again! You are not expected to understand this... :-) I guess I should first take a look at the PWB1 pure text code, which is heavily modified from the stock V6, to see what it does - this all may have already been done there. Noel

7 years, 3 months

2
1
0 0

Calgary buffer modifications

by Paul Ruizendaal

For a while I had been wondering about the origins of a modification to the V6 kernel that places the kernel buffers in a separately mapped area, freeing up space for other things. It is used in some of the early networking code, i.e. both the UoI code and the V6 BBN code (as available on the TUHS Unix Tree). I came across the following reference in https://www.osti.gov/scitech/servlets/purl/12130675: “One widely distributed (though undocumented) solution to this hardware limit on the model 40 was a version of Unix by Robert Sidebotham, Faculty of Environmental Design, University of Calgary. His solution was to move the I/O buffers out of kernel space.” This would explain the modifications being bracketed with "#ifdef UCBUFMOD”. Some questions for the old hands: - Was this patch indeed widely known / distributed? - Widely distributed is not the same as widely used: was it?

7 years, 3 months

3
2
0 0

Happy birthday, Douglas Engelbart!

by Dave Horsfall

Born on this day in 1925, he was a pioneer in human/computer interaction, and invented the mouse; it wasn't exactly ergonomic, being just a square box with a button. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 3 months

2
1
0 0

V6 UNIX main() oddness

by jnc＠mercury.lcs.mit.edu

So, while bringing up V6 on a hardware PDP-11/23 with an RK11 emulator using an SD card for storage which Dave Bridgham and I are doing, I found this piece of code in main() on V6 Unix: rootdir = iget(rootdev, ROOTINO); rootdir->i_flag =& ~ILOCK; u.u_cdir = iget(rootdev, ROOTINO); u.u_cdir->i_flag =& ~ILOCK; I don't get why two separate calls to iget(), with the same arguments; why not replace the second pair of lines with: u.u_cdir = rootdir; rootdir->i_count++; What am I missing? Noel

7 years, 3 months

3
2
0 0

LSX swapping

by Paul Ruizendaal

>>> LSX has a maximum of three processes that are swapped in and out in a >>> stack-like fashion. Only one process is ever in core. > > I'm having a hard time working out how this works. If process A is swapped > out, and then B, B has to be swapped in before A can be? But only one process > is ever in core at a time? To get A in, B has to be moved out? But then B > would be the last one out, and would have to come in before A? > > Anyway, I don't understand why the OS could/would care which order processes > we swapped in - unless it's something like the 'onion skin' memory allocation > algorithm of CTSS (which also had only a single process resident at a time, > IIRC), where, when a small process had to be swapped in, and a large one was > already in, it only swapped out enough of the large one to make room for the > small one. The process could recurse, hence the name. The LSI-11 had 40KB of core. The lower 16KB held the LSX kernel, the upper 24K was for the active process. LSX has 3 process slots and 2 swap slots (on floppy!). Optionally, LSX could be built with an additional background process ("BGOPTION"), but this does not work very well. Process numbers and swap slots have a 1:1 relationship. There is a global variable, cpid, with the process number of the current process, initially zero. Upon boot, LSX will load a shell as process 0. (There is no swapper process and no init in LSX). The original LSI-11 kernel code is here: http://minnie.tuhs.org/cgi-bin/utree.pl?file=LSX/sys I can refer to source lines in the repository for my TI990 port of it: https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b6ec9496e23efe8c When a process forks, it writes the current core image out to the corresponding swap slot (this swaps out the parent) and the core image is repurposed as the new process (i.e. cpid is incremented and the proc table filled in): https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/3617ec3245c40a69?l… The child now runs and the parent remains suspended until the child completes. Yes, this implies no pipes. The shell is modified to emulate pipes with files. When the child completes, it stores its u area / exit code in its swap slot (as it is running, the swap slot must be empty. Process 3 has a small swap slot just for this). Next LSX decreases cpid and the parent process is reloaded from its swap slot: https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b9c07dfc5add9fc5?l… The actual swapping happens here: https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b6ec9496e23efe8c?l… The original PDP11 source has code to compress the empty space between _end and the stack pointer, which I did not get to work properly. LSX works well enough to run the standard V6 binaries unmodified. Some need to be tweaked (e.g. table space in cpp) and the shell needed the pipe change. It can run the V6 c compiler, but not with a wild card argument: that requires 4 stacked processes (sh, glob, cc and cpp/c0/..) and LSX allows only 3. Hope the above makes it a bit more clear.

7 years, 3 months

1
0
0 0

RIP Marvin Minsky

by Dave Horsfall

We lost AI pioneer Marvin Minsky on this day in 2016 from a cerebral haemorrhage, aged 88. Amongst other things, along with John McCarthy he co-founded the MIT AI Lab, co-invented the Logo "turtle", was mentioned in Arthur C. Clarke's novel "2001: A Space Odyssey", and built the first randomly wired neural network learning machine, SNARC, in 1951. He is now thought to be cryogenically preserved as "Patient 144" at Alcor (he started cooling on 27/1/2016). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 4 months

1
0
0 0

Re: [TUHS] Swapping (Was: !mail tuhs@minnie.tuhs.org)

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy >> From: Paul Ruizendaal >> LSX has a maximum of three processes that are swapped in and out in a >> stack-like fashion. Only one process is ever in core. I'm having a hard time working out how this works. If process A is swapped out, and then B, B has to be swapped in before A can be? But only one process is ever in core at a time? To get A in, B has to be moved out? But then B would be the last one out, and would have to come in before A? Anyway, I don't understand why the OS could/would care which order processes we swapped in - unless it's something like the 'onion skin' memory allocation algorithm of CTSS (which also had only a single process resident at a time, IIRC), where, when a small process had to be swapped in, and a large one was already in, it only swapped out enough of the large one to make room for the small one. The process could recurse, hence the name. > V1 was a time-sharing system; for which LIFO swapping is > inappropriate. And I don't follow that either... V1 ran on the 11/20 without memory management hardware, though, right? (Although there's that cryptic reference to the KS11 in "Odd Comments and Strange Doings in Unix", although I've never been able to find out anything else about the KS11.) So presumably one would not have wanted more than one process resident at a time, as that decreases the odds of a buggy program trashing another process? Noel

7 years, 4 months

1
0
0 0

origin of C header files

by Wesley Parish

Hi I've just had an interesting experience, explaining C header files to a nephew programmer who didn't understand them. I pointed him in the direction of Minix as an example of a small well-engineered system which would display their use. Which raised the question: when did header files come into use? Who was the first to use header files to store common system-wide or application-wide data definitions? Was it used in any languages prior to C? Thanks Wesley Parish

7 years, 4 months

5
6
0 0

OT: Need help from a *BSD guru

by arnold＠skeeve.com

Hi. Can a modern BSD guru please contact me off-list? I have a set of related tests in the gawk test suite that consistently fail on just about every *BSD system. It has me stumped, and I'd like to see these tests working if possible. (They've been not working for quite a while. That I get no complaints from BSD users tells me that gawk isn't popular in that world, but that's another story. :-) Thanks, Arnold

7 years, 4 months

2
4
0 0

!mail tuhs@minnie.tuhs.org

by Doug McIlroy

Re: [TUHS] Kernel Sizes > I've often thought that LSX was V5 'regressed' to the concepts of > V1, which was facing similar hardware constraints. Is that a > reasonable view? > LSX has a maximum of three processes that are swapped > in and out in a stack-like fashion. Only one process is ever in core. > Is that how V1 was organized? The rocess limit was higher in V1. And V1 was a time-sharing system; for which LIFO swapping is inappropriate. So LSX seems to have "regressed" to some pre-Unix state. doug

7 years, 4 months

1
0
0 0

Re: [TUHS] Kernel Sizes

by Rudi Blom

16K kernels? Well, I came late to the UNIX world. I only remember getting a SCO UNIX 3.2V4.2 kernel onto a single 3-1/2" diskette and still have all I wanted including (with scripts on a second diskette of course :-) ). That was 25 years ago. Mind you, from there I moved to Digital UNIX /vmunix 9,613.712, Tru64 17.930.976 to HP-UX 11iv2 66.161.464 and HP-UX 11iv3 127.929.032 Of course, I also got lots more functionality I'm supposed to want and need :-) Cheers, rudi

7 years, 4 months

1
0
0 0

Kernel Sizes

by Warner Losh

For a presentation I'm doing this summer on FreeBSD, I thought it would be cool to get the kernel sizes for various old flavors of Unix. I see numbers for v5, v6 and v7 in the tuhs tree view, and it appears these versions are complete enough for me to extract the kernels themselves. However, I see nothing prior to that. The archives seem to be somewhat incomplete, but I'm wondering if people have sizes for earlier versions. Later versions are more problematic because they move to new hardware, instruction sets, etc. For this graph to be meaningful, it would need to be pdp-11 only, though I'm of the opinion more data is better than less. I'll also be extracting the different V7 commercial kernels: V7M, Ultrix and Venix and the BSD 2.x releases, but those appear to be intact enough in the archives to extract data on my own. I've heard rumors there's a SysV for the pdp-11, but I've not been able to locate images for that. I don't need the actual images, just sizes with some reference for the source of the data. It's just for one slide in the talk, so I don't want to burn a ton of time on it... The larger picture is that I've written what's effectively modprobe for FreeBSD and will be talking about it in detail. How it's like modprobe, how it's different, how all the pieces fit together, history of similar efforts, etc. Part of the driving force here is the bloated FreeBSD GENERIC kernel. Of course, I'll share the final report I'm planning on sizes with the group. Thanks for any data you can provide. Warner

7 years, 4 months

11
13
0 0

Re: [TUHS] Kernel Sizes

by Paul Ruizendaal

> A self-imposed limit of 16K held in v1, and was quite fully utilized. > When the iernel was rewritten in C, the limit (perhaps larger by then) > influenced the C compiler. More than one optimization was stimulated > by the need to keep the kernel in bounds. > > Doug The LSX kernel was kept within a self-imposed limit of 16KB as well. I've often thought that LSX was V5 'regressed' to the concepts of V1, which was facing similar hardware constraints. Is that a reasonable view? For example, LSX has a maximum of three processes that are swapped in and out in a stack-like fashion. Only one process is ever in core. Is that how V1 was organized? I realize that LSX was API compatible with V5/V6 and I don't mean 'regressed' in that sense. Paul

7 years, 4 months

1
0
0 0

Re: [TUHS] Kernel Sizes

by Doug McIlroy

> I seem to remember that at some point early on, we spent some of our > capital budget on buying another 16K bytes for the PDP-11. As I > recall, the deal was that the OS got 8K and users got 8K. I also > recall that that purchase was 20% of our capital budget for the > year... > Doug, did I remember this correctly? > Steve Things did happen that way. I don't specifically remember the numbers, but those you state have the ring of truth. Memory came in (expensive) 4K increments. When the keepers of Unix in the Charlotte wire center wanted to add 4K, their management consented only on the condition that the wizards in Research would confirm that roposed new functionality really required it. doug

7 years, 4 months

1
0
0 0

Re: [TUHS] Kernel Sizes

by Doug McIlroy

>> A self-imposed limit of 16K held in v1 > 16k words or 16k bytes? Bytes. doug

7 years, 4 months

1
0
0 0

Subject: Re: KernelSizesA self-imposed limit of 16K held in v1, and was quite fullyutilized.Subject:Re: Kernel Sizes

by Doug McIlroy

A self-imposed limit of 16K held in v1, and was quite fully utilized. When the iernel was rewritten in C, the limit (perhaps larger by then) influenced the C compiler. More than one optimization was stimulated by the need to keep the kernel in bounds. Doug

7 years, 4 months

3
2
0 0

OT - Has anyone seen / have a copy of computer lore story about a DC consolidation?

by Grant Taylor

Sorry for the off topic post. I'm hoping that someone here might have seen a (what I consider to be) a computer lore type story about a contractor that was brought in part way through a project to consolidate three DCs into one. - In the end he managed to do it early and under budget. The kicker is that they quite literally physically moved and re-connected everything the way that it was. Meaning that there were still WAN circuits (local only of course) between equipment that was previously in different DCs. I would like to find a copy of this story and save it in my archive. But I've not been able to do so. Thus I'm asking a wider audience to see if anyone might be able to give me a pointer. -- Grant. . . . unix || die

7 years, 4 months

1
0
0 0

RIP Ed Yourdon

by Dave Horsfall

We lost Ed Yourdon on this day in 2016; a computer pioneer, he helped to design the underpinnings of relational databases, and pretty much wrote the book. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 4 months

2
1
0 0

Happy birthday, John Lions!

by Dave Horsfall

Dr. Prof. John Lions was born on this day in 1937; I had the pleasure of having him as one of my Computer Science lecturers in the early 70s, and he drilled into us the Principle of Least Astonishment (or POLA), better known as "why the fsck did it do that?" (but he was far too genteel to express it that way). And yes, that's my name in the credits; I helped with the proof-reading and provided the use of the high-quality printer in the CSU. You are not expected to understand this. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 4 months

2
1
0 0

Scot Hacker's 1999-2001 "BeView" columns for Byte.com (BeOS)

by Arrigo Triulzi

Scot Hacker has re-published his BeOS columns for Byte. BeOS was an interesting operating system with a clear Unix inheritance built for a dual-PowerPC system, similar to the Macs of that era. http://birdhouse.org/beos/byte/ Its inheritance can be found in Haiku (https://www.haiku-os.org) Arrigo

7 years, 4 months

2
2
0 0

Some resources for V6/PDP/SIMH newbs like me

by Will Senn

All, While it's fresh, I thought I'd share some resources I've found helpful in learning about the venerable v6 as a relative newb... Learning Unix V6 in the modern era is an interesting and enormously educational experience. In the process of using it I have had to learn how to host it in a simulator (SimH in my case, but there are others), install it, communicate with it, configure it, build special files for it, attach devices to it, communicate with the devices attached to it and to SimH, build a kernel, install the kernel, boot the kernel, work with a variety of media intended to work with it, extend it, and so on. In addition, I have had to learn a bit about the PDP-11 (as arguably the most convenient architecture for learning about V6), about its architecture, its instruction set, its devices, its memory structure, and so on. None of this exploration would have been possible without the excellent work of Bob Supnik, Mark Pizzolato, and co. on the SimH pdp-11 simulator, the Simh mailing list, Warren Toomey and TUHS for making the bits available, the TUHS mailing list, PUPS, Bitsavers, and a slew of readily available documentation and texts including these notables: Setting Up Unix 6th Edition from the V6 Programmer's Manual The Unix V6 Programmer's Manual in its entirety The SimH and SimH PDP-11 Manuals A large number of blogs with SimH specific V6 installation logs The V6 Source Code and man pages (don't forget to install man - the 1bsd version works, and is superior)! The DEC PDP-11/05-10-35-40 1973 Handbook (the 11/40 handbook is not as detailed with respect to memory management) Lions's Commentary on the Sixth Edition source code Now that I'm over the beginner's hump, so to speak, I'm exploring things differently and I thought I'd share some resources that I am currently finding useful and interesting in my explorations... To bone up on assembly language, Lions's commentary is exceptionally helpful in explaining assembly as it is implemented in V6. The manual itself is really thin, and the source is a bit cryptic, for the newcomer. Lions explains the idioms used in the main source of V6. However, without a background in assembly language, Lions is pretty meaningless, so I went looking for something that was PDP specific that would bridge the gap and help me understand Lions's words. I found a number of texts that were really good. Most require a working RT11 instance to actually try out the coding examples and do the exercises (SimH and Bitsavers to the rescue): Arthur Gill - Machine and Assembly Language Programming of the Pdp-11 Charles A. Kapps and Robert L. Stafford - Assembly Language for the PDP-11 Glenn H. MacEwan - Introduction to Computer Systems: Using the PDP-11 and Pascal James F. Peters - The Digital Way: Macro-11 Assembler Programming (PDP-11) Michael G. Schneider - The Principles of Computer Organization: With Assembly Language Programming for the PDP-11 PDP-11 Processor Handbook (pretty much any edition) Thomas A. Frank - Introduction to the PDP-11 and its Assembly Language All of these are useable with a running RT11 instance. But, I think the Peters and Frank books are the standouts. Peters because all of the exercises that I have tried (dozens) have worked as printed and Frank because he is rigorous in his treatment of the subject and builds up from digital logic all the way through program execution. Frank is an excellent complement to Lions work because he explains the details that Lions assumes. To learn about digital logic, and a special thanks to Warren for his work on Crazy Small CPU, I have been introduced to logisim. It is a great playground for exploring digital logic. I had no idea that a sketchpad for digital logic simulation was available and accessible to the layperson. Logisim development stopped around 2014 and while there are a number of successors out there, I am using logisim-evolution: https://github.com/reds-heig/logisim-evolution The rabbit trails never seem to end... in order to learn how to use logisim, I went through the excellent tutorial and then went looking for a book of experiments in digital logic and found: digital computer lab workbook from 1969 http://bitsavers.trailing-edge.com/pdf/dec/handbooks/Digital_Computer_Lab_W… digital equipment corporation computer lab teacher's guide from 1968 http://www.so-much-stuff.com/pdp8/pdf/ComputerLabTeachersGuide.pdf These two are useable with very little modification as a source of digital logic exercises that work great with logisim and are related to the architectural lineage of the PDP-11. These resources fit together nicely in my pursuit to better understand digital logic, the pdp-11, assembly language, and unix v6. In sum: Source code for v6 for what really is supposed to happen in v6 operation Lions for understanding Unix V6 sources and for unix assembly language information PDP-11 Hanbook for quick reference on PDP-11 assembly language instruction set Frank for assembly language details and for details on digital logic and its relationship to the PDP-11 architecture. Logisim to test logic constructs The digital lab workbook for practice with digital logic Later, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

7 years, 4 months

2
2
0 0

Re: [TUHS] origin of C header files

by Lars Brinkhoff

The book "Expert C Programming" claims Alan Snyder suggested the addition of a preprocessor.

7 years, 4 months

1
0
0 0

2018: eighteen months to the Unix 50th anniversary

by Warren Toomey

Hi all, Happy New Year. As it's now only eighteen months to the Unix 50th Anniversary, I thought I'd poll you all to get an update of what is being done to celebrate the anniversary, and/or what could we organise that has not yet been organised. Cheers, Warren

7 years, 4 months

10
16
0 0

Happy birthday, C.A.R. Hoare!

by Dave Horsfall

Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a computer pioneer (one of the greats) he gave us things like the quicksort algorithm and ALGOLW (a neat language). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 4 months

5
6
0 0

Re: [TUHS] 2018: eighteen months to the Unix 50th anniversary

by jnc＠mercury.lcs.mit.edu

> From: George Michaelson > Try this on the birth of the ICL 2900. Along the same lines, there's this: https://www.netjeff.com/humor/item.cgi?file=GenesisForProjects with its great closing line.. Noel

7 years, 4 months

2
1
0 0

Happy birthday, Donald Knuth!

by Dave Horsfall

Computer pioneer Donald Knuth was born on this day in 1938; amongst other things he gave us the TeX typesetting language, and he's still working on "The Art Of Computer Programming" fascicles (I only got as far as the first two volumes). I really must have a look at his new MMIX, too; I love learning new programming languages (I've used about 50 the last time I looked, and I'm happy to post a list for my coterie of disbelievers). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 4 months

2
1
0 0

Re: [TUHS] [TUHS} 2018: eighteen months of the Unix 50th anniversary

by Doug McIlroy

> I will be happy to forward pertinent suggestions. Here's one. If Bell Labs holds some kind of symposium on the lines of the dmr memorial, how about a plenary session with TV participation from remote venues (think Berkeley/Silicon Valley and Wollongong/Sydney--a nine-hour span of time zones). Any thoughts about this or other possibilities? Doug

7 years, 4 months

2
1
0 0

Re: [TUHS] [TUHS} 2018: eighteen months of the Unix 50th anniversary

by Doug McIlroy

I don't think I'm violating anyone's confidentiality by revealing that Marcus Weldon, current president of the Labs, at the suggestion of Martin Carroll, expects the Labs to embark soon on plans to mark the occasion. I, and no doubt Martin, will keep you posted. Meanwhile I will be happy to forward pertinent suggestions. Doug

7 years, 4 months

1
0
0 0

RIP John Mauchly

by Dave Horsfall

We lost a co-inventor of ENIAC, John Mauchly, on this day (that's 8th January like my headers say) in 1980. ENIAC is claimed to be the "first general purpose electronic digital computer", but I guess it comes down to a matter of definition[*], as every culture likes to be the "first" (just ask the Penguins, for example); for "computer" you could go all the way back to the Mk-I Antikythera (Hellenic variation, from about the 100BC production run)... [*] Analogue/digital/hybrid Mechanical/electrical/electronic/hybrid General/special Wired/programmable/Turing Prototype/production Harvard/Neumann/quantum Etc... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 4 months

1
0
0 0

Re: [TUHS] OT: critical Intel design flaw

by jnc＠mercury.lcs.mit.edu

> From: Andy Kosela > it appears this is a fundamental Intel bug that exists in all x86_64 > CPUs. I'm highly amused by the irony. Intel throws bazillions of transistors at these hyper-complex CPUs in an attempt to make them as fast as possible - and (probably because of the complexity) missed a bug, the fix for which involves... slowing things way down! I wonder how many other bugs are lurking in these hyper-complex designs? Didn't anyone at Intel stop to think that complexity is bad, in and of itself? But I guess the market demands for faster and faster machines outweighed that - until it bit them in the posterior. The real question is 'how many more times will it have to happen before they get a clue'? There's an interesting parallel between this, and uSloth's struggle with security and bugs. For a long time, it seemed it was more important to the market to add features (i.e. complexity), and security be damned - until poor security really started to become an issue. So now they're trying to catch up - but seemingly still haven't got there, in terms of the fundamental architecture of the OS, as the never-ending stream of bug patches attests. The sad thing is that how to provide good security (not perfect, but much, much better than what we have) was worked out a long time ago, and Intel hired Roger Schell to add the necessary hardware underpinnings when they did the 386: http://conservancy.umn.edu/bitstream/11299/133439/1/oh405rrs.pdf Mutatis mutandis. Noel

7 years, 4 months

14
35
0 0

Re: [TUHS] OT: American Culture

by Norman Wilson

Random832 (a good year for randomness, that): Who says right is positive? ===== Good question. Norman Wilson Toronto ON Left-handed

7 years, 4 months

4
3
0 0

Re: [TUHS] OT: critical Intel design flaw

by Norman Wilson

Clem Cole: IIRC this is part of the argument Dykstra made with the THE paper years ago, Parnas in his information hiding paper -- i.e. why microkernels and proper layering are a good idea. Keep is simple and do one thing well/protect yourself against other subsystems not being 100%. ===== Indeed. Complexity creates needless RISC, er, risk. Norman Wilson Toronto ON

7 years, 4 months

1
0
0 0

OT: critical Intel design flaw

by Andy Kosela

http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ Including here as it concerns Unix kernel and leaking memory from kernel space to userland. This is big -- it appears this is a fundamental Intel bug that exists in all x86_64 CPUs. It will be interesting to watch the ramifications and impact of this on the industry as a whole. --Andy

7 years, 4 months

3
2
0 0

Re: [TUHS] OT: American Culture

by Doug McIlroy

> A lingering gripe that explains my latent anti-Americanism goes back to > when I had to support Uniplus 2.2/2.4 (sorta SysIII-ish) on the WICAT boxes > in here in Australia. At installation time, we had to express the time > offset as hours *west* of GMT; this left me with a lingering belief that > Americans didn't want to be perceived as being backwards (yeah. it saved an > entire keystroke out of the dozens that were otherwise required). But east postive is an artifact of north up. I remember Australian souvenir shops selling maps on "MacQuarrie's corrective projection", in which south is up. In fact this orientation was not uncommon in Europe between medieval maps that really were oriented, with east up, and later convention that put north up and shoved Australia down under. Surely an Aussie would prefer south up and west positive! Doug

7 years, 4 months

2
1
0 0

Re: [TUHS] OT: American Culture

by Clem Cole

On Sun, Dec 31, 2017 at 7:15 PM, Dave Horsfall <dave(a)horsfall.org> wrote: > > A lingering gripe that explains my latent anti-Americanism goes back to > when I had to support Uniplus 2.2/2.4 (sorta SysIII-ish) on the WICAT boxes > in here in Australia. At installation time, we had to express the time > offset as hours *west* of GMT; this left me with a lingering belief that > Americans didn't want to be perceived as being backwards (yeah. it saved an > entire keystroke out of the dozens that were otherwise required). Dave I'm not so sure it's about being perceived as forward or backwards - its just shallow, provincial and often lazy because the program did not really knowing any better. The problem is too many American', (particularly younger ones that experience our 'excellent' educational system), have often never travelled that much and experiences other places, cultures or social norms. I admit this is extreme example, but about 8 years ago, my daughter had a friend, who was approx 16 at the time, that we took to the big city (Boston) to play in a orchestra concert at Symphony Hall when they both were named 'All State' for the instruments. I don't remember why said friends family did not/could not come - but it made sense and we said we would take her with us. On the drive in-town, we were talking with her and I discovered that she had never gone to Boston before ... ever -- she was excited to see it (we live less than 1hr North mind you. Note quite the boon-docks). She had not gone to a 'Bo Sox' game or anything. Never went to the Science Museum, etc. She grew up in her town (mind you happy) and using TV as her window to world. Which brings me to >>my complaint<<. We, as American's, project so much about 'us' via TV. The said truth is most Americans are not like what they see on TV [e.g. Rice-A-Roni is made up!!, Benihana's is an American invention, and "the big yellow school bus" is dirty/noisy and usually without seat belts]. Sadly, many Americans do not know any better - queue the famous quote about never under-estimating the taste of the American public. But think about what folks outside the US see and think? Many of my European friends in particular all want to visit NYC. [I tell them all, visit Boston or Philadelphia first if you can. Those cities are much more representative of America then LA, NYC or Dallas; if for no other reason they are more 'European' in feel]. When I run into things like what you just described (and I seem to run into then most often with MicroSoft based tools), I think to myself, it must have been a cold day in Redmond, WA and some programmer did not want to make an effort to do make her/his solution really general ;-) Clem FWIW: Not only did we take my kids all over the world as children, we brought the world to them by sponsoring kids from all sorts of countries. But I fear, my wife and I are less the norm then I would wish. ᐧ ᐧ

7 years, 4 months

2
1
0 0

Re: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > What timezone did you say you were in again? Ah; didn't realize you wanted the exact time, not just a date! :-) Well, according to this: http://www.rfc-editor.org/rfc/museum/ddn-news/ddn-news.n19.1 it was _planned_ to happen at "00:01 (EST) 1 Jan 1983". Whether it did happen at that moment, or if in reality there was some variance, I don't know (IIRC, I was off sailing in the Caribbean when it actually happened :-). Noel

7 years, 4 months

3
2
0 0

, ARPAnet converted to TCP/IP

by Ron Natalie

It was sort of a soft change over. All the did on January 1, 1983, is disable link 0 on the IMPs. This essentially blocked NCP from working anymore. You could (and many of us were) run IP on the Arpanet for years before that. In fact the weeks before we were getting ready for the change and we had our TCP/IP version of the system up. It crashed. We rebooted it and set about debugging it. It crashed again. Immediately my phone rang. It was Louis Mamakos, then of the University of Maryland. He had tried to ping our system. I called out the information to Mike Muuss who was across the desk from me. We set to find the bug. It turned out that the ICMP echo handling in the 4.1c (I believe this was the version) that we'd cribbed our PDP-11/70 TCP from had a bug where it used the incoming message to make the outgoing one, AND it freed it, eventually causing a double free and crash. It was at this point we realized that BSD didn't have a ping client program. Mike set out to write one. It oddly became the one piece of software he was most known for over the years. The previous changeover was to long leaders on the Arpanet (Jan 1, 1981?). This changed the IMP addressing space from eight bits (6 bits for imp number, 2 for a host on imp) to 16 bits for imp number and 8 for a host on imp. While long leaders were available on a port basis for years earlier, they didn't force the change until this date. The one casualty we had a PDP-11/40 playing terminal server running software out of the University of Illinois called "ANTS." Amusingly the normal DEC purple and red logo panels at the top of the rack were silkscreened with orange ANTS logos (with little ants crawling on it). The ANTS wasn't maintained anymore and stuck in short-leader mode. We used that option to replace that machine with a UNIX (we grabbed one of our ubiquitous PDP-11/34's that were kicking around). I kept the racks and the ANTS logo for the BRL Gateways. I turned in the non-MM PDP-11/40. A year later I get a call from the military supply people. ME: Yes? GUY: I need you to identify $65,000 of computer equipment you turned in. ME: What $65,000 machine? GUY: One PDP-11/40 and accessories. ME: That computer is 12 years old... and I kept all the racks and peripherals. Do you know how much a 12-year-old computer is worth? The other major cut over was in October of 1984. This was the Arpanet-Milnet split. I had begged the powers that be NOT to do the change over on the Jan 1st as it always meant I had to be working the days leading up to it. (Oct 1 was the beginning of the "fiscal" year). Our site had problems. I made a quick call to Mike Brescia of BBN. This was pre-EGP, and things were primarily static routed in those days. He'd forgotten that we had routers at BRL now on the MILNET (all the others were on the ARPANET) and the ARPANET-MILNET "mail bridge" routers had been configured for gateways on the MILNET side.

7 years, 4 months

1
0
0 0

Re: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > the ARPAnet got converted from NCP to TCP/IP in 1983; ... have a more > precise date? No, it was Jan 1. It wasn't so much a 'conversion', as that was the date on which, except for a few sites which got special _temporary_ dispensation to finish their preparations, support for NCP was turned off for most ARPANET hosts. Prior to that date, most hosts on the ARPANET had been running both, and after that, only TCP worked. (Non-ARPANET hosts on the then-nascent Internet had always only been using TCP before that date, of course.) Noel

7 years, 4 months

3
4
0 0

OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP

by Dave Horsfall

Some interesting historical stuff today... We lost Rear Admiral Dr. Grace Hopper USN (Retd) in 1992; there's not much more than can be said about her, but I will mention that she received (posthumously) the Presidential Medal of Honor in 2016. As every Unix geek knows, today is the anniversary of The Epoch[tm] back in 1970, and at least one nosey web site thinks that that is my birthdate too... And according to my notes, the ARPAnet got converted from NCP to TCP/IP in 1983; do any greybeards here have a more precise date? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 4 months

1
0
0 0

Re: [TUHS] Why did PDPs become so popular?

by Larry McVoy

On Fri, Dec 29, 2017 at 04:04:01AM -0700, Kevin Bowling wrote: > Alpha generally maintained integer/ALU and clockspeed leadership for > most of the '90s > http://www.cs.columbia.edu/~sedwards/classes/2012/3827-spring/advanced-arch… Wow, that first graph is the most misleading graph on CPU performance I've ever seen. Ever. So from 1993 to 2000 the only CPUs released were Alphas? That era was when I was busy measuring performance across cpus and operating systems and I don't ever remember any processor being a factor of 2 better than its peers. And maybe I missed it, I only owned a couple of alpha systems, but I never saw an Alpha that was a game changer. Alpha was cool but it was too little, too late to save DEC. In that time period, even more so now, you had to be 2x better to get a customer to switch to your platform. 2x cheaper 2x faster 2x more reliable Do one of those and people would consider switching platforms. Less than that was really tough and it was always, so far as I remember, less than that. SMP might be an exception but we went through that whole learning process of "well, we advertised symmetric but when we said that what we really meant was you should lock your processes down to a processor because caches turn out to matter". So in theory, N processors were N times faster than 1 but in practice not so much. I was very involved in performance work and cpu architecture and I'd love to be able to claim that we had a 2x faster CPU than someone else but we didn't, not at Sun and not at SGI. It sort of make sense that there weren't huge gaps, everyone was more or less using the same sized transistors, the same dram, the same caches. There were variations, Intel had/has the biggest and most advanced foundries but IBM would push the state of the art, etc. But I don't remember anyone ever coming out with a chip that was 2x faster. I suspect you can find one where chip A is introduced at the end of chip B's lifespan and A == 2*B but wait a few month's and B gets replaced and A == .9*C. Can anyone point to a 2x faster than it's current peers chip introduction? Am I just not remembering one or is that not a thing? --lm

7 years, 4 months

7
13
0 0

Re: [TUHS] Why did PDPs become so popular?

by Rudi Blom

A bit off the PDPs, but to do a minor correction on mail below The commercial version of 'UNIX' on Alpha was maybe first called Digital Unix OSF/1, but quickly changed to Digital Unix at least with v3 and v4.0 (A - G). From there we had a 'break' which only in part was due to take over by Compaq and we had Tru64 UNIX v5.1A and V5.1B. The V5.1B saw updates till B-6. As for the Digital C compiler, I'm still using DTCCMPLR650 installed Compaq C Version 6.5 for Compaq Tru64 UNIX Systems When I get some old source (some even developed on SCO UNIX 3.2V4.2) I like to run it through all compiler /OS-es I got handy. With the Compaq C compiler and HP-UX ANSI C I mostly get pages of warning and a few errors. By the time I 'corrected' what I think is relevant some nasty coredumps tend to disappear :-) Compile for a better 2018, uncle rubl >Date: Fri, 29 Dec 2017 21:30:11 -0500. >From: Paul Winalski <paul.winalski(a)gmail.com> >To: Ron Natalie <ron(a)ronnatalie.com> >Cc: TUHS main list <tuhs(a)minnie.tuhs.org> >Subject: Re: [TUHS] Why did PDPs become so popular? >Message-ID: <CABH=_VRwNXUctFPav5rHX83wfUS0twMQuBhinRZ6QEY1cB3TNQ(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" > >On 12/29/17, Ron Natalie <ron(a)ronnatalie.com> wrote: > The Alpha was hot > stuff for about nine months. Ran OSF/1 formerly DigitalUnix formerly > OSF/1. >Digital UNIX for the VAX was indeed derived from OSF/1. The port to >Alpha was called Tru64 UNIX. >Tru64 UNIX was initially a pure 64-bit system, with no provision for >building or running 32-bit program images. This turned out to be a >mistake . DEC found out that a lot of ISVs had code that implicitly >"knew" that sizeof() a pointer was the same as sizeof(int) was the >same as 4 bytes. Tru64 was forced to implement a 32-bit compatibility >mode. >There was also a problem with the C compiler initially developed at >DECwest in Seattle. It supported ONLY ANSI standard C and issued >fatal errors for violations/extensions of the standard. We (DEC >mainstream compiler group) called it the Rush Limbaugh >compiler--extremely conservative, and you can't argue with it.

7 years, 4 months

3
2
0 0

Re: [TUHS] origin of C header files

by Doug McIlroy

Warning: off-topic info > I was told once that McIlroy and Morris invented macro instructions > for assembly language. And certainly they wrote the definitive > paper on macros, with, as I recall, something like 10 decisions you > needed to make about a macro processor and you could generate 1024 > different macro systems that way. I wonder if that ever got > published The suggestion that I invented macros can also be found on-line, but it's not true. I learned of macros in 1957 or before. GE had added a basic macro capability to an assembler; I don't know whether they invented the idea or borrowed it. In 1959 George Mealy suggested that Bell Labs install a similar facility in SAP (SHARE assembly program). Doug Eastwood wrote the definition part and I handled expansions. Vic Vyssotsky later asked whether a macro could define a macro--a neat idea that was obviously useful. When we went to demonstrate it, we were chagrinned that it didn't work: definition happening during expansion resulted in colliding calls to a low-level string-handling subroutine that was not re-entrant. Once that was fixed, Steve Johnson (as a high-school intern!) observed that it allowed the macro table to serve as an addressable memory, for which the store and load operations were MOP (macro define) and MAC (macro call). Probably before Steve's bright insight, Eastwood had folded the separate macro table into the opcode table, and I had implemented conditional assembly, iteration over a list, and automatic generation of symbols. These features yielded a clean Turing-complete language-extension mechanism. I believe we were the first to achieve this power via macros. However, with GPM, Christopher Strachey showed you don't need conditionals; the ability to generate new macro names is enough. It's conceivable, but unlikely, that this trick could be done with earlier macro mechanisms. As for publication, our macroprocessor inspired my CACM paper, "Macro nstruction extension of compiler languages", but the note that Steve remembers circulated only in the Labs. A nontrivial example of our original macros in action--a Turing machine simulator that ran completely within the assembler--was reproduced in Peter Wegner's programming book, so confusingly described that I am glad not to have been acknowledged as the original author. Doug

7 years, 4 months

1
0
0 0

Re: [TUHS] Why did PDPs become so popular?

by jnc＠mercury.lcs.mit.edu

> From: Paul Winalski > Lack of marketing skill eventually caught up to DEC by the late 1980s > and was a principal reason for its downfall. I got the impression that fundamentally, DEC's engineering 'corporate culture' was the biggest problem; it wasn't suited to the commodity world of computing, and it couldn't change fast enough. (DEC had always provided very well built gear, lots of engineering documentation, etc, etc.) I dunno, maybe my perception is wrong? There's a book about DEC's failure: Edgar H. Schein, "DEC is Dead, Long Live DEC", Berett-Koehler, San Francisco, 2003 which probably has some good thoughts. Also: Clayton M. Christensen, "The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail", Harvard Business School, Boston, 1997 briefly mentions DEC. Noel

7 years, 4 months

6
6
0 0

tuhs@minnie.tuhs.org

by Mutiny

'FUNCTION: To save the programmer effort by automatically incorporating         library subroutines into the source program.'in Cobol whole 'functions' (subroutines) and even code snipplets are 'copied' into the main source file by the copy statement. That's different to preprocessor macros, -definitions, -literals and, since ansi c, function prototypes. 

7 years, 4 months

1
0
0 0

tuhs@minnie.tuhs.org

by Mutiny

'FUNCTION: To save the programmer effort by automatically incorporating         library subroutines into the source program.'in Cobol whole 'functions' (subroutines) and even code snipplets are 'copied' into the main source file by the copy statement. That's different to preprocessor macros, -definitions, -literals and, since ansi c, function prototypes. 

7 years, 4 months

1
0
0 0

History of exploits - request for authors

by Arrigo Triulzi

Dear all, I am starting a new “history” section of the “weird machines and security” publication PoC||GTFO (https://www.alchemistowl.org/pocorgtfo for my mirror, https://www.nostarch.com/gtfo for a printed compilation of the first 15 issues). Ideally we would like some articles about the history of security exploits where the historical importance is emphasised: we always get authors willing to tell us about the latest and greatest web exploit but they often lack any historical perspective about what has been done before. As PoC||GTFO has a strong emphasis on weird machines and generally forgotten hardware and software I thought that the contributors to TUHS would be ideally placed to write something about their preferred security exploits in the past. I have fond memories of taking over a machine using and NFS /home filesystem exported to the wide-world, of someone trying to hack into my MasPar via the DEC Ultrix which controlled it, etc. but I am really rather interested in other perspectives. I hope a few of you will want to contribute something to the collection, there is still space for the January 2018 edition if anyone is so inclined. Cheers, Arrigo

7 years, 4 months

6
10
0 0

Why did PDPs become so popular?

by Alec Muffett

I apologise if this is too far from the main topic, but I wanted to check an urban legend. There is a story - as I have heard it told - that PDPs established their place (and popularity) in the marketplace by pointedly *not* advertising themselves as "computers", but instead as "programmed data processors". This was because - so the story goes - that everyone in corporations of the time simply *knew* that "computers" came only from IBM, lived in big datacentres, had million-dollar price-tags, and required extensive project management to purchase; whereas nobody cared enough about a thing called a "programmed data processor" to bother bikeshedding the few-tens-or-hundreds-of-thousands-of-dollars purchase proposal to an inevitable death. Thus, they flitted under the purchasing radar, and sold like hotcakes. I wonder: does this story have substance, please? Aside from anything else: I draw parallels to the adoption of Linux by Wall St, and the subsequent adoption of virtualisation / AWS by business - now reflected in companies explaining to ISO27001 auditors that "well, we don't actually possess any physical servers..." - alec -- http://dropsafe.crypticide.com/aboutalecm

7 years, 4 months

4
5
0 0

Why did PDPs become so popular?

by Dave Ritchie

I think that steep educational discounts and equipment grants from Digital to major collages also had a major impact,as did the existence of DECUS that made a lot of software readily available. Best regards, David Ritchie

7 years, 4 months

5
6
0 0

Happy birthday, Charles Babbage!

by Dave Horsfall

Charles Babbage KH FRS was born on this day in 1791; pretty much the father of the computer, a model of his "difference engine" built to the standards of the day worked, complete with its printer. What is not so well known about him was that he dabbled in cryptography, and broke the Vigenère cipher; unfortunately for him it was classified as a military secret, so one Friedrich Kasiski got the credit instead. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 4 months

3
4
0 0

Scanned: Xenix Abstract (1982)

by Toby Thain

Hi, Found this in a box of papers... Scanned it in yesterday. Posting in case it's of list interest: https://docs.telegraphics.com.au/Microsoft_The%20Xenix%20Operating%20System… An OCR'd PDF version will eventually appear here: http://chiclassiccomp.org/docs/index.php?dir=%2Fcomputing/Microsoft (but it's not there yet). --Toby

7 years, 4 months

1
0
0 0

Old tar bug in SVR4.2 was: SYSTEM V R1 HELP

by Arthur Krewat

Somewhat tangentially related to the other thread... So, back in the days when I was using Consensys SVR4.2, I found a bug in tar. It goes like this: If there is a symbolic link in the tree that you are taring, the first one works fine. If a second symbolic link has a shorter destination name than the first, the extra characters from the first symbolic link destination are appended to the end of the second. So for example: a -> abcdef b -> zyx Tar will actually tar these symbolic links as: a -> abcdef b -> zyxdef Being that I happen to have found, on the Internet, the sources to AT&T SVR4.2, and some other System V variants, I went and investigated. The relevant piece from AT&T SVR4.2 tar.c (broken): Jan 25 1993 ./ATT/ATT-SYSVr4/cmd/tar/tar.c case S_IFLNK: <SNIP> i = readlink(shortname, filetmp, NAMSIZ - 1); if (i < 0) { vperror(0, "can't read symbolic link %s", longname); return; } From USL-4.2 (apparently fixed): Jan 22 1994 ./USL/usl-4.2-source/src/i386/cmd/tar/tar.c case S_IFLNK: <SNIP> i = readlink(shortname, filetmp, NAMSIZ - 1); if (i < 0) { vperror(0, ":462:Cannot read symbolic link %s", longname); return; } else filetmp[i] = '\0'; /* since readlink does not supply a '\0' */ From Solaris 2.5: case S_IFLNK: <SNIP> i = readlink(shortname, filetmp, NAMSIZ - 1); if (i < 0) { vperror(0, gettext( "can't read symbolic link %s"), longname); if (aclp != NULL) free(aclp); return; } else { filetmp[i] = 0; } BSD 4.4: case S_IFLNK: <SNIP> i = readlink(shortname, dblock.dbuf.linkname, NAMSIZ - 1); if (i < 0) { fprintf(stderr, "tar: can't read symbolic link %s: %s\n", longname, strerror(errno)); return; } dblock.dbuf.linkname[i] = '\0'; Anyone know when/why/how tar diverged between the two branches? Note the readlink directly into dblock.dbuf, while the SVR4 variants use a temp string and then sprintf it in later. From: http://www.catb.org/esr/faqs/usl-bugs.txt 17. tar(1) fails to restore adjacent symbolic links properly Arthur Krewatt <...!rutgers!mcdhup!kilowatt!krewat> reports: SVR4 tar has another strange bug. Seems if when restoring files, you restore one file that is a link, say "a ->/a/b/c/d/e" and there is another link just after it called "b ->/a/b/c" tar will restore it as "b ->/a/b/c/d/e" This just seems to be a lack of the NULL at the end of the string, like someone did a memmov or memcpy(dest,src,strlen(src)); where it should be strlen(src)+1 to include the NULL. Esix cannot reproduce this under 4.0.4 or 4.0.4.1, they think it's fixed.

7 years, 5 months

1
0
0 0

SYSTEM V R1 HELP

by William Corcoran

Hello Team TUHS: I am having a problem with my PDP-11 SVR1 running under a recent SIMH build. My problem occurs on both MAC OS X and FreeBSD. First, I created a six disk (RP06) and eight port TTY (DZ) kernel, with swap placed on drive 1. The system behaves beautifully as FSCK reports clean. Eight users can login with no problem. Second, I reverted to a pristine PDP-11 SVR1 with one drive (RP06) and no DZ and booted the default kernel (gdtm) and I see the same problem described below. Third, when using the tape driver instead of /dev/null i get the same results. Next, here is the issue: cd / find . -print | cpio -ocvB > /dev/null It runs for a short while and then shitz a core: I am using /dev/null to take the tape driver out of the equation. Here is the backtrace for cpio: $c __strout(053522,043,0,053012) __doprnt(046652,0177606,053012) _fprintf(053012,046652,053522) ~main(02,0177636) Now, interestingly, I run into a similar issue when using tar: cd /usr tar -cvf /dev/null . Again, this will run for a while, then drops a core. Here is the backtrace for tar: $c __strout(043123,02,0,045506) __doprnt(043123,0167472,045506) _fprintf(045506,043123,0170600) ~putfile(0170600,0170641) ~putfile(0171654,0171704) ~putfile(0172730,0172745) ~putfile(0174004,0174016) ~putfile(0175060,0175066) ~putfile(0176134,0176136) ~putfile(0177672,0177672) ~dorep(0177632) ~main(04,0177630) This really bugging me since my SVR1 is otherwise working flawlessly. I was able to remake the entire system and custom kernels that boot with no problem. Also, I configured my main port to run inside the AWS Lightsail and now I have access to SVR1 from anywhere in the world! I was also wondering if doing a CPIO or TAR on the entire system was overflowing some link tables and maybe this is expected behavior for the minimal resource of the PDP-11? Thank you for any help. Would you expect tar or cpio to dump core if you attempted to copy large filesystems (or the entire system) on a PDP-11? Note: All of my testing has been in single user mode. Truly, Bill Corcoran

7 years, 5 months

6
14
0 0

Re: [TUHS] OT: Happy birthday, Tommy Flowers!

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > Colossus, arguably the world's first electronic computer Well, it all depends on your definition of "computer"... :-) I myself prefer to reserve that term for things that are programmable, and Turing-complete. (YMMV... :-) So I call things like Colossus and ABC "digital electronic calculating devices" (or something similar). None of which is to take anything away from the incredible job done by Flowers and his cohorts. It was an amazing device, and had a major effect on history. Noel

7 years, 5 months

1
0
0 0

OT: Happy birthday, Tommy Flowers!

by Dave Horsfall

Tommy Flowers MBE was born on this day in 1905; an electrical and mechanical engineer, he designed Colossus, arguably the world's first electronic computer, which was used to break the German "Lorenz" high-level cipher (not Enigma, as some think). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

2
1
0 0

Various Unix

by Jose R. Valverde

Before we had to phase out our FTP server, I kept on it several versions of UNIX clones and related OS that were mostly not on TUHS. This post is to remember some of these systems. Many of these were open sourced or widely available at some time and were related to UNIX one way or another. I may not have the latest versions or all the versions, but at least I do keep something. The following ones have been open sourced at some point in time (I believe): ChorusOS Coherent EXOS L4 Lunix MaRTE-OS Mach OpenBLT OpenSolaris Sprite (I also own the original distribution CD) Trix UniFlex agnix amoeba bkunix bsd386 hurd iunix jaluna-c5 lsx-unix mini-unix minix omu opensolaris starunix thix from tliquest.net/local/unix: uzi and various other bits tme tropix tunix unix-v8 unix-wega uzi xhomer xinu xv6 yoctix Plus several archaic CDs with early versions of Linux, Open/Free/NetBSD, (Walnut Creek, InfoMagic, etc. CD/ROMs) and even the Beowulf/Extreme Linux CDs (plus I must keep around the mirror we hosted for a long time of the Beowulf site). The hobbyist CDs for OpenSolaris 8 (and I believe 9) with sources. Oh, and MOSIX/OPENMOSIX. In addition, I have many other sources whose Copyright status I'm not aware of, but which are interesting for archival purposes. Regarding QNX, yes, it was open sourced (at least for hobbyist use, I have to check the license) for several distributions. I ported some bioinformatics software and kept for some time a distribution repository, and I'm pretty certain I must have the sources as well as the virtual machines. I'll try to verify the licenses to see if it can be redistributed, although I doubt they can. Oh, and I also own the mentioned famous 3.5" diskette. I think I digitized it long ago. Would have to check. Off the Net, it has been possible, one time or another, to recover executables and, sometime, even sources, of many systems. Archive.org has -I believe- a copy of a once famous repo of abandonware with binaries of SCO, System V, AIX, etc... I know that AIX, ATT systemV vI, II, III and IV, Solaris V6, Tru64, OSF-1, Dynix, Ultrix 11, BSDI, Ultrix-32 etc... have been out there at some time or another in source code format, and binaries of IRIX, Lisa, QNX, A/UX, xenix... Some years ago, I had more free time and could test many systems on emulators, and built images and accompanying scripts ready ti run. I also made some tools to be able to transfer data in and out of old unix versions (so I could edit the software off the virtual machine while back-porting a screen editor to V6, v5, etc... with only vt100 support). Not UNIX-related, I also keep copies of many other ancient operating systems and software and hardware emulators. Well, as I said at the beginning, everything that I had, I should still keep while the hard disks continue spinning. If there is any interest in adding any of these to TUHS, I can try to find a way to send it all. If I find time to browse through everything, I would like to upload all the source code to GitHub (at least anything that's redistributable). If I find the time... But, Warren, if you are interested in anything, let me know and I'll find a way to give you access. j -- Scientific Computing Service Solving all your computer needs for Scientific Research. http://bioportal.cnb.csic.es

7 years, 5 months

2
1
0 0

pre-UNIX legacy in UNIX?

by Nigel Williams

I blundered today into the GECOS field in /etc/passwd: https://en.wikipedia.org/wiki/Gecos_field "Some early Unix systems at Bell Labs used GECOS machines for print spooling and various other services,[3] so this field was added to carry information on a user's GECOS identity." I had forgotten about this field and I don't recall it being previously described as related to GECOS (I likely didn't take note at the time I first encountered it). Aside from the influence of Multics and other things on UNIX design are there other tangible[1] manifestations of non-UNIX operating system things like the GECOS field that were carried forward intact in later UNIX implementations? [1] things can be pointed at, rather than design ideas

7 years, 5 months

8
8
0 0

Re: [TUHS] pre-UNIX legacy in UNIX?

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy > In fact, I don't recall being aware of the existence of the ITS > movement at the time Unix arose. For background, here are a few selected timeline items: ?/1967 ITS design starts 7/67 ITS first becomes operational 12/67 Multics single process boot on 645 10/68 Initial Multics milestone (8 users) 01/69 Limited Initial Multics milestone (12 users) 04/69 Bell Labs drops out of Multics (I included the latter since I'm assuming the "time Unix arose" is after the Bell Labs departure.) Note: I'm not saying or implying anything about the 3 systems with this; this is purely data. Noel

7 years, 5 months

1
0
0 0

Re: [TUHS] pre-UNIX legacy in UNIX?

by Doug McIlroy

> > are there other tangible[1] manifestations of non-UNIX operating > > system things like the GECOS field that were carried forward intact in > > later UNIX implementations? > > Job control was inspired by ITS job control capabilities. Control-Z > does pretty much the same thing in both operating systems. I don't think "carried forward" describes job control, which I believe was never in any Research system. "Borrowed" would be more accurate. In fact, I don't recall being aware of the existence of the ITS movement at the time Unix arose. Doug

7 years, 5 months

2
2
0 0

Re: [TUHS] pre-UNIX legacy in UNIX?

by Richard Tobin

> > In fact, I don't recall being aware of the existence of the ITS > > movement at the time Unix arose. > Was there ever a movement? It was just four machines at MIT. When AT&T sued BSD Inc over (among other things) the phone number 1-800-ITS-UNIX, the joke was that MIT should have sued them too. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

7 years, 5 months

1
0
0 0

Re: [TUHS] OT: trains [Was: Date madness]

by Norman Wilson

Ian Zimmerman: > How do other train systems handle [DST], e.g. the European intercity > system? Dave Horsfall: UTC? It's not hard to get used to it. ===== You misunderstand the problem. Suppose I'm planning to board a train at 0300 on the morning Daylight Time ends. Now suppose the train actually departs an hour early, at 0200, because it originated before the time change and some nerd who never rides trains declared that it shall not wait the extra hour until scheduled departure time. Nerds may be happy, but the paying passengers won't be. Telling passengers to set their watches to UTC just won't happen. (Some of us nerds actually had our watches on GMT for a few months back in the years that gave the `Nixon table' in old ctime.c its (informal) name, but gave up because it was just too damn much work to stay in sync with the real world.) Once upon a time, before railways had radio communications and proper track-occupancy signalling, the consequences were more serious than that: if you run an hour ahead of schedule, you risk colliding with another train somewhere. That is why it was the railways that first accepted and promoted standard time zones. Nowadays it's not about scheduling and safety, just about having an acceptable user interface. In a similar vein, I know of at least one case in which Amtrak changed the official departure time of a train (that requires advance reservations and often runs full) from 0000 to 2359, because people would get confused about which day midnight falls on and show up a day late. (Actually the Amtrak timetable read 1200 midnight and 11:59 PM, but 24-hour time is one of the changes I agree people should just accept and use.) Norman Wilson Toronto ON

7 years, 5 months

3
2
0 0

Early Clones / Rewrites for TUHS archives

by Clem Cole

My question about SOL got me thinking a bit. It would be nice to have section in TUHS of any early clones that could be collected. The two that I can think of that probably should be there are (other feel free to point ones that we should try to find): 1.) Idris, which was fairly true to V6 (enough that the one time I test it, things from pretty much just worked). It was notable from being first. Although the C compiler and the 'anat' (the assembler) were a tad different. It the system that got Bill Plauger in trouble @ USENIX @ UDEL when he was booed for a 'marketing' talk. 2.) CRDS (pronounced Cruds by those of use that use it at the time) - Charles River Data Systems. It was a UNIX-like system, although I do not think really attempted to hold to a V7 API much more than intent. Although if my memory serves me, one of the unique features was the use of Reed & Kanodia synchronization in its kernel [REED79], which I was a always a fan. The system was slow as sin bit it ran on a 68000. [CRUDS system, a Fortune box and our Vax/750 running BSD4.1 were the systems Masscomp used to bootstrap]. Clem [REED79] D.P. Reed and R.K. Kanodia, "Synchronization with Eventcounts and Sequencers"

7 years, 5 months

17
21
0 0

Re: [TUHS] Date madness

by Norman Wilson

Arnold: ISTR that the vaxen did have such things. Or rather, I ran some BSD 780s for several years and I don't remember having to set the date / time every time I did a reboot. They sat in a data center, so I may have never done a cold boot from power on. It was a LONG time ago now, so there's undoubtedly lots that I just plain don't remember. ==== I believe all the VAXes had time-of-year clocks, though the implementation and the method of access varied from model to model. On `Big' VAXes, the clock was considered part of the console front-end, and accessed through the model-specific console scheme. MicroVAXes had no console front-end; I believe the clock was accessed through registers, but it was an off-the-shelf digital-watch chip with some funny format (separate registers for year, month, day, hour, minute, second). So they all had proper battery-backed-up clocks, but of many different types. It wasn't as simple as reading a single counter out of a register, sensible as that might seem. If anyone's really interested I can dig up details for the several models of Big and MicroVAX I dealt with; I still have all the code lying around. Norman Wilson Toronto ON

7 years, 5 months

7
7
0 0

OT: Konrad Zuse

by Dave Horsfall

We lost Konrad Zuse on this day in 1995; he invented the world's first programmable computer -- the Z3 -- which was unfortunately lost in the Berlin bombing during 1943. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

2
1
0 0

Date madness

by jnc＠mercury.lcs.mit.edu

Heh, my V6 machine thinks (via 'date') that today is _Monday_, December 12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess the date code is probably missing the '400 year' exception. Noel

7 years, 5 months

10
14
0 0

shell PS1/PS2 which survive cut-paste

by George Michaelson

I tried a long time ago to set PS1 and PS2 to character sequences which would permit cut-paste to work. I failed, but I didn't try very hard. The choice of "# " and "> " interests me. Because roots prompt of "hash" has a side effect of making a cut-paste over it a comment in most shells. But.. it predates being *able* to cut-paste so it has to be a side-effect, not a design choice. "> " is more dangerous in cut-paste. Which again feels like a side-effect both by anachronistic time effects, and intent: nobody would be that suicidally mad to make cut-paste invoke shell pre-forming the command sequence which neccessarily zeros out the > targets before executing the cmd... -G

7 years, 5 months

11
17
0 0

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> From: Arnold > One would think that SIMH I'm using Ersatz-11... > into the simulated computer's time of day clock. What Time of Day clock? We're talking PDP-11's here! :-) The very last DEC models of the -11 (/93-94) had a ToY clock; I'm pretty sure none of their others did. And of course V6 long pre-dated the /93-94. Noel

7 years, 5 months

8
10
0 0

Re: [TUHS] Date madness

by Doug McIlroy

>>> Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106. If you have source it’s incredibly trivial to change, and nothing changes size wise. >> >> Easy, but perhaps unwise. The sign bit is a potential escape hatch for >> times, just as it is for characters in UTF-8. > > I'm not sure what you're suggesting - UTF-8 works because it's a variable length encoding - a variable length timestamp might be interesting as an academic exercise, but there's no way for time() to specify how much space is needed, or be informed of how much space is allocated Like UTF-8, a variable-length time would be something normal programs aren't supposed to see--it would be a format for external media (i.e. file systems). Times in inodes would be variable-length. Times returned by stat() and time() would be full length. Only the kernel needs to know the encoding. One may note that inodes already use a variable-length encoding for the list of physical block addresses, so there is nothing radical here. I admit, though, that if the kernel can tell "old" from "new" inodes, then they could have different time encodings rather than one variable-length encoding. Doug

7 years, 5 months

3
2
0 0

Re: [TUHS] Early Clones / Rewrites for TUHS archives

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > It would be nice to have section in TUHS of any early clones that could > be collected. The Unix Tree does have a section for "Unix Clones", and it has Coherent, Xinu, Minix and some early Linuxes. Another one that's missing (although in a different category) is Ultrix-32.> Noel

7 years, 5 months

6
6
0 0

Partition table rationales?

by Random832

Is there any information on the rationales behind the sizes and positions of the hardcoded partitions in the rp/hp drivers in V6? There are odd gaps of unused space between ones that appear to be intended to be used together (I think I have some pieces of the puzzle worked out below, but not all). For the rp driver, only rp[01] uses the whole disk - rp2 and rp3 are 9200 blocks. The hp partitions looked more complicated, but it looks like the manpage is wrong about where partition 2 starts - 84018 vs 48018. Partitions 0123 are 161584 blocks, 4567 are 162400 blocks. 4567 start on 100-cylinder boundaries, but are only a bit over 97 cylinders long - in fact, they are the same length as rp[01]: 203 RP03 cylinders. rp6 and rp7 are not mentioned in the manpage, and are 15600 blocks, making rp[65] and 47 reasonably non-wasteful configurations. Is there something special about 9200 blocks? rp2 and rp3 are that size, and hp1 is that size rounded to the next cylinder. V7 is much simpler: rp0 is the whole disk, 123 is a non-overlapping set with no wasted space. hp[0145], 016, and 017 are non-overlapping sets.

7 years, 5 months

1
0
0 0

Re: [TUHS] Date madness

by Doug McIlroy

> Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106. If you have source it’s incredibly trivial to change, and nothing changes size wise. Easy, but perhaps unwise. The sign bit is a potential escape hatch for times, just as it is for characters in UTF-8. Doug

7 years, 5 months

2
2
0 0

Difference in purpose of /var/spool vs /var/lib

by Grant Taylor

Can anyone enlighten me on the effective difference in the use of /var/spool vs /var/lib? It's my understanding that spools are for files that are in transit. Effectively like packages moving through a shipping depo or people waiting in line. I.e. they come in, they hang around for a while, and then they leave. I'm of the opinion that files in /var/lib should stick around longer and are not nearly as dynamic (if at all, save for code updates). As sure as I type this, I can't think of a reason library files would go under /var vs a different */lib directory. Does it make any difference if the files are actually executed and / or consumed on the system? I don't consider the POP3 / IMAP / NNTP server to be processing files when people access messages / articles (read: files) via the respective protocols. Back story: I'm considering writing something that will download a file every day and process the last day's / week's / month's file(s) to generate output which is itself stored elsewhere. - I feel like these files should live in the /var/spool/<bla> subdirectory. -- Grant. . . . unix || die

7 years, 5 months

2
1
0 0

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> From: Tom Ivar Helbekkmo > My /83s have them, but I'm not so sure it's a feature of the CPU board: > there's this thought nagging in the back of my head that the ToY thing > actually sits in the front panel module with the various buttons on it. /83 documentation seems to be very thin on the ground, alas. It's definitely not the CPU; the KDJ11-B CPU (of the /83) manual (EK-KDJ1B-UG-001) makes no mention of it; and in the PDP-11/94E System User and Maintenance Guide (EK-KDJ1E-UG-001), section D.2 "PDP-11/94 and 11/84 Hardware Differences" (the /?3 and /?4 models use the same CPU board, but a different backplane, with QBUS/UNIBUS converter, so this could equally well be titled "PDP-11/93 and 11/83 Hardware Differences") says "Time of Year Clock", indicating the 83/84 don't have one. Several companies made after-market ToD clocks to plug into the QBUS, e.g. here: https://www.ebay.com/itm/371284594072 Is something like that what your /83 has? Noel

7 years, 5 months

1
0
0 0

Other history lists...

by Grant Taylor

Does anyone know of any other similar history discussion mailing lists / newsgroups to discuss things like Mainframes or (Open)VMS? I have some questions as I try to broaden my horizons, but I don't think they fit in the TUHS context. -- Grant. . . . unix || die

7 years, 5 months

5
5
0 0

V7 Addendem

by Warner Losh

>From the tuhs web site: "This is a set of addenda to Seventh Edition Unix, possibly put out by the Labs." and "The identity of the person who donated them is unknown." Two questions: Was this put out by the Labs? Second: There was recently a discussion about a tape found at some public location during an early Unix user group meeting. Is this that tape? Warner

7 years, 5 months

16
27
0 0

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> From: Arnold > So how did you manage to lose a whole year? Time travel? :-) No, I just haven't booted the V6 often in the last year, and when I did, I never bothered to reset the time; so it was still on Nov, 2016. Noel

7 years, 5 months

2
1
0 0

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> So, I looked at the code, and the bug is not obvious. Because there _was_ no bug!!! :-) It was saying December 12 was a Monday because the _year_ was still set to _2016_, and in 2016, December 12 _was_ a Monday! {Smacks forehead!} Noel

7 years, 5 months

2
1
0 0

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> Guess the date code is probably missing the '400 year' exception. So, I looked at the code, and the bug is not obvious. (The routine for detecting leap years in V6's ctime.c is so minimalistic it actually works for 2000!) The version I'm currently running had been worked on some, to have a hack fix for the overflow of the number of 8-hour periods since the epoch ("hack" since the 'fixed' version will break in 2029 or so), and I was worried that 'fix' was wrong and caused the week-day problem, but I don't think so. Noel

7 years, 5 months

1
0
0 0

The French SOL Project

by Clem Cole

In the early 1980s, a bunch of French researchers set out to build a clone of UNIX/V7 in Pascal (using a ukernel IIRC). The project was the SOL project [Gien, 1983]. I believe it eventually begat the Chorus system (which was C++); which UI was going to use for System V/R5 before it all blew up. 1) Does anyone know what happen to SOL? Was it finished, deployed, used for anything? 2.) Did the sources and doc survive (and who owns the IP)? I think those should be in the TUHS archives, as I think this was the first attempt at a rewrite of UNIX in something other than C (or assembler). 3.) On a similar thought, did the Chorus code survive and who owns the IP? Clem [Gien, 1983]*“The SOL Operating System*”, Michel Gien, USENIX Association, 1983, Proceedings of the Summer ’83 USENIX Conference, Toronto, On, Canada, July, 1983, Pages 75-78

7 years, 5 months

4
3
0 0

Re: [TUHS] Early Clones

by Rudi Blom

actually not an early clone but a late(r), Philips MPX (Multi-processor UNIX) based on SystemV running on Moterola CPUs. Mostly sold in the (Retail) Banking Industry as branch server. The "M" was more related to having various boards running their own UNIX. That would be an Ethernet board and one Networking board for SDLC and X.25. These boards run their own copy of unix to 'offload' the main CPU. I've worked with this UNIX but more a system tester, interface to National Sales Organisations. No idea where the source is, but guess it would be IP of Philips (or DEC, or Compaq, or HP, or HPE) if anyone still remembers that is. For a (very) short while there was also an Intel CPU based version, but dropped in favour of SCO UNIX when DEC bought Philips Computer division. A very little bit in this 1987 article. https://www.cbronline.com/news/better_late_philips_enters_the_uk_unix_marke… Cheers, uncle rubl

7 years, 5 months

1
0
0 0

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> From: Warner Losh > So at some point you had to hack things in to make 20xx work, no? I had a number of date issues with V6; more here: http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#Issues That one was the easiest to fix! (Although this one will probably also be pretty easy, too.) Noel

7 years, 5 months

1
0
0 0

Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > IP and datagrams were very much built on no central control Well, yes and no. One can easily have a centrally controlled datagram network (q.v. the ARPANET) - although it's true that its path-selection algorithms, etc were not centrally controlled - but other aspects of the network were. (Interestingly, after various routing disasters the Internet caused by improper configuration, some aspects of path selection in _parts_ of it are now effectively centrally controlled; but I digress.) The IP Internet was designed with no _overall_ central control, but as a collection of autonomous entities. > In the end, it was MetCalfe's law (which was formulated on observations > about the phone system) that caused IP to win Over any and all comers, including other decentralized datagram networks like CLNP. MetCalfe's law doesn't talk about decentralized, it's just about 'first to field'. > all want to see the net neutrality go away This whole 'net neutrality' campaign drives me completely crazy. If all people wanted was a rule saying 'ISPs can't give third parties _worse_ service, or - more importantly - deny service altogether, unless those parties pay up' (i.e. what would amount to targeted extortion), I'd be _all for_ a rule like that. But the 'net neutrality' aficionados (most of whom, I'm fairly sure, are not aware of/thinking about these details) are all signing up for a much more expansive rule, one that says 'no ISP can offer anyone _better_ service for paying more money' - which is quite different. My problems with this latter form are two-fold. First, what's wrong with that anyway? Do we have a rule saying you can't get better road service if you pay? Absolutely not - restricted toll lanes are becoming more and more common. So there's clearly no societal agreement on this principle. (I suspect this 'net netrality' campaign has as a goal some sort of 'forced equality' thing - unless the people behind it simply don't even understand the difference.) Second, that rule is, with a little extra work on the ISPs' part, ineffective anyway. All they have to do is build _two_ networks, one better provisioned than the other - and priced accordingly. You want better service? Sign up for the second network; you'll pay more, but it's your choice. Noel

7 years, 5 months

5
4
0 0

Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]

by jnc＠mercury.lcs.mit.edu

> From: George Michaelson > I didn't mean to disrespect the people who did the models or the > protocol or standards work btw. Oh, I personally have no problem with you saying hard things about this work, as long as it's what you really think. One never finds the truth unless one is willing to look hard, neh? And I'm pretty sure Dave Clark (who was a leading light in IntServ) would be OK with you doing so too (I worked very closely with him for years, to the point where I deputized for him at meetings). I honestly don't remember exactly what my take was on IntServ and RSVP; I'd have to go look. I recollect seeing the case that _if resources were limited_, certain classes of application (I guess we called them 'inelastic') would need reservations to work properly. So I was probably susceptible to the argument that 'if we've got bandwidth to light our <insert flammable objects> with, we don't need resource reservation'. And I remember being not _thrilled_ with RSVP, but I don't recall exactly why. But, as, you said, wrong list. Maybe internet-history: http://mailman.postel.org/mailman/listinfo/internet-history if you did want to delve into it. Noel

7 years, 5 months

1
0
0 0

Re: [TUHS] MERT?

by jnc＠mercury.lcs.mit.edu

> From: Jon Steinhart > Probably the best person to ask is Heinz Lycklama. I checked my email log for my previous MERT enquiries, and that's the exact same advice I got from Brian Kernighan when I asked him (a couple of years back) if he had any suggestions for tracking it down. I guess I need to finally get a 'round tuit'... unless there's someone else here who knows him well, and wants to give it a go. Noel

7 years, 5 months

1
0
0 0

Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]

by jnc＠mercury.lcs.mit.edu

> From: George Michaelson > I don't think this list is the right place to conduct that particular > debate. Not disagreeing; my message was a very short gloss on a very complicated situation, and I wasn't trying to push any particular position, just pointing out that work (whether the right direction, or not, I didn't opine) had been done. > Its true RSVP didn't get traction, but the economics which underpin it > are pretty bad, for the current Internet model of settlement Yes, but would _any_ resource reservation system, even one that _was_ 'perfect', have caught on? Because: > it would not surprise me if there is ... more dropped packets than > strictly speaking the glass expects. This is related to something I didn't mention; if there is a lot more bandwidth (in the loose sense, not the exact original meaning) than demand, then resource reservation mechanisms buy you nothing, and are a lot of complexity. While there were bandwidth shortages in the 90s, later on they pretty much went away. So I think the perception (truth?) that there was a lot of headroom (and thus no need for resource reservation, to do applications like voice) played a really big role in the lack of interest (or so people argued at the time, in saying IntServ wasn't needed). Noel

7 years, 5 months

2
1
0 0

Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]

by jnc＠mercury.lcs.mit.edu

> From: Steve Johnson > Recently I've been attempting to Skype on a group call with 5 people in > Europe. I would LOVE to have a guaranteed bandwidth for my call. The Internet engineering community did quite a bit of work on resource guarantees. (Google 'IntServ' and 'RSVP' - the latter is the control protocol.) Unfortunately, there was never much interest in it. People started doing voice with just plain 'best effort' service, and I guess it worked 'well enough' that nobody was interested in IntServ/RSVP. Noel

7 years, 5 months

2
1
0 0

Re: [TUHS] net neutrality

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy <lm(a)mcvoy.com> > Did you read the reddit link I sent? No, because I despise Reddit. > Because if you had you wouldn't be asking this. Now that I look at it, most of what I lists is ISP's _blocking_ sites. I _already_ said I wanted to see a rule preventing that. > unregulated businesses will do whatever they can to make more money with > absolutely no concern about the consequences Sure - like content providers. Noel

7 years, 5 months

2
1
0 0

Re: [TUHS] net neutrality

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > Just like the electric company, needs to deliver electrons at some > rate/force. If you want electrons at more than X bazillion per second, you'll have to pay to have a higher-amperage service. And if you use more electrons, you pay more. What's your problem with ISPs doing the same? Noel

7 years, 5 months

3
2
0 0

Re: [TUHS] net neutrality

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy <lm(a)mcvoy.com> > look at the history, various ISPs like Verizon, Comcast, etc, have done > stuff like block bittorrent, skype, etc Bittorrent is a complex situation, some ISPs were ordered by a court to block it. As to Skype, I agree ISPs shouldn't block sites - but if you read my message, I already said that. > The problem is I paid for the bits. Bits is bits. I paid for a rate, > that's what they got paid for, why should they get to charge a second > time for the same bits? That's exactly what they want to do. Fine, you pay your money, you get X Mbits/second. If you (or the site you're getting bits from) wants _more_ than X Mbits/second, charging you - or them, which is I gather mostly what ISPs want to do - for that privilege is a problem... how? Noel

7 years, 5 months

2
1
0 0

Re: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana!

by Rudi Blom

Anyone on TUHS who made the list? Greeting from your Dutch uncle rubl For all the sound advise you don't want to hear. Date: Sun, 10 Dec 2017 13:23:13 +1100 (EST) From: Dave Horsfall <dave(a)horsfall.org> To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> Subject: Re: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana! Message-ID: <alpine.BSF.2.21.1712101314210.35694(a)aneurin.horsfall.org> Content-Type: text/plain; charset=US-ASCII; format=flowed On Sat, 9 Dec 2017, Ralph Corderoy wrote: >> Yeah, but all the same, two famous people in the same industry would >> surely lengthen the odds somewhat... > > Yeah, you're pulling my leg. :-) > https://en.wikipedia.org/wiki/List_of_computer_scientists OK, it was worth a try :-) (I'm a born stirrer, and I blame my parents for that.) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

2
1
0 0

Grace Hopper

by Dave Horsfall

(At the risk of being flamed because it's not strictly Unix...) We gained Rear Admiral Grace Hopper on this day in 1906; known as "Amazing Grace", she was a remarkable woman, both in computers and the Navy. She coined the term "debugging" when she extracted a moth from a set of relay contacts from a computer (the Harvard Mk I) and wrote "computer debugged" in the log, taping the deceased Lepidoptera in there as well. She was convinced that computers could be programmed in an English-like language and developed Flow-Matic, which in turn became, err, COBOL... She was posthumously awarded the Presidential Medal of Freedom in 2016 by Barack Obama. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

9
11
0 0

Happy birthday, Grace Hopper and J.F.Ossana!

by Dave Horsfall

As promised :-) Augusta Ada King-Noel, Countess of Lovelace (and daughter of Lord Byron), was born on this day in 1815; arguably the world's first computer programmer and a highly independent woman, she saw the potential in Charles Babbage's new-fangled invention. J.F.Ossanna was given unto us on this day in 1928; a prolific programmer, he not only had a hand in developing Unix but also gave us the ROFF series. Who'ld've thought that two computer greats would share the same birthday? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

2
4
0 0

Card reader on Unix

by Dave Horsfall

Something's been bothering me for a while... I've just remembered that our 11/40 with more peripherals than you could shake a stick at -- it had just about everything except a DECtape -- also had, so help me, a card reader! As I dimly recall, 'twas a slow CDC (?) model; we didn't have it for long, either because it was on loan or because it was so unreliable, I simply don't remember. Anyway, our driver handled it in two modes: you either got a raw image of each card (likely via DMA instead of column by column, but I could be wrong) i.e. 80 words with each column of 12 holes fitting nicely into a 16-bit word, or there was a half-arsed attempt at converting EBCDIC to ASCII, with trailing blanks replaced by a newline (i.e. think of it as a line printer in reverse). Or was it converting from whatever KRONOS used to ASCII? Now, what I *distinctly* remember was writing two scripts: "/etc/cdc" and "/etc/dec" which switched between the two modes, quite likely by patching the in-core kernel! I'd give a testicle to have that "CSU tape" back again (and no doubt so would Warren), but can anyone else remember this (or dare to call me a liar; yes, I'm still touchy about that)? The snag is, towards the end of the CSU before they were about to be engulfed by the admin suits and forced to support payroll programs in COBOL etc, I was the only senior Unix bod left, so it's unlikely that the CSU source code followed someone else home... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

1
0
0 0

AT&T 3B2/400 Emulator

by Seth Morabito

Hello everyone, A few weeks ago, I merged my work-in-progress AT&T 3B2/400 emulator into the main SIMH source tree, and I realized that I should mention it here, where there may be particular interest. The 3B2 and 3B5 were main porting platforms for AT&T System V Release 3, and when I realized how scarce the equipment has become to find, I set out to write an emulator for the 3B2. It was rough going at points due to lack of documentation, but I was able to reverse engineer quite a bit of the system through reading the SVR3 source code, and of course strapping my own 3B2/310 to a logic analyzer. The emulator is fairly complete. It certainly works well as a standalone, single-user UNIX system. Support for multiple terminals is coming very soon (as soon as I find the time, that is) so it will soon be possible to allow multiple users to telnet into virtual terminals, similar to how the SIMH PDP-11 and VAX emulators work. For now, information about the emulator lives here: https://loomcom.com/3b2/emulator/ Best Wishes, -Seth -- Seth Morabito web(a)loomcom.com

7 years, 5 months

6
6
0 0

V7 32V 3BSD dates

by Warner Losh

OK. I'm confused. Maybe people here can help me understand. Looking at the V7 sources, it looks for all the world like they were released Jan 10, 1979. This release was PDP-11 only. So far, so good. 32V, a port to the VAX, is listed as 'early 1979'. Dates in the files in the archive suggest March 26th, 1979 (though there are dates as late as May 3rd and April 30th on two files that are trivial). The tape we have in the archive has a date Feb 22, 1980 written on it. Given the dates, that's only 3 months after V7 was released. This seems very fast, but maybe it's OK since it's a swapping release.... 3BSD, The Berkeley 32V has file dates as late as Mar 22, 1980... This seems reasonable for turning V7 from swapping into paging... about a year is fast but not crazy fast. My question is: did these three events really happen in this quick succession? Did USDL folks get started with a preliminary V7 for V32 or was the port really done in 2 and a half months? Likewise with UCB and 3bsd: did they start early? Warner

7 years, 5 months

2
2
0 0

What UNIX Artifacts Are Still Missing?

by Paul Ruizendaal

> Venix/86 and Venix/86R might be interesting... I have impure versions of > both... +1 Venix/86 is the first Unix to run on PC hardware that I’m aware of. It could go together with Idris and Minix as examples of early PC Unix.

7 years, 5 months

14
22
0 0

Re: [TUHS] Grace Hopper

by Nelson H. F. Beebe

For more on Admiral Grace Murray Hopper, by one who knew her well, see Jean Sammet's remembrance: Farewell to Grace Hopper: end of an era! https://doi.org/10.1145/129852.214846 A Ph.D. thesis about her: The Contributions of Grace Murray Hopper to Computer Science and Computer Education https://digital.library.unt.edu/ark:/67531/metadc278692/m2/1/high_res_d/100… Books: Grace Hopper: Admiral of the Cyber Sea 1-59114-978-9 Grace Hopper and the Invention of the Information Age ISBN 0-262-51726-4 Grace Hopper: Computer Whiz ISBN 0-7660-2273-0 [juvenile literature] I've always found it amusing that she was a strong proponent of the work ethic: "Act first, get permission later", which is in direct opposition to the military chain of command, despite her rank as Rear Admiral of the US Navy. See also ACM Grace Murray Hopper Award https://awards.acm.org/hopper https://awards.acm.org/hopper/award-winners [Awarded to the outstanding young computer professional of the year, selected on the basis of a single recent major technical or service contribution. This award is accompanied by a prize of $35,000. The candidate must have been 35 years of age or less at the time the qualifying contribution was made. Financial support of the Grace Murray Hopper Award is provided by Microsoft.] Don Knuth of Stanford was the first GMHA winner, in 1971; other well-known people include Steve Wozniak (1971), Bob Metcalf (1980), Dan Bricklin (1981), Brian Reid (1982), Bill Joy (1986), John Ousterhout (1987), Guy Steele (1988), Richard Stallman (1990), Bjarne Stroustrup (1993), Vern Paxson (2007), Craig Gentry (2010), ... There is also a 1983 interview on a popular US news broadcast that celebrates its 50th anniversary this year: The 60 Minutes interview with Grace Murray Hopper https://www.cbsnews.com/news/the-60-minutes-interview-with-grace-murray-hop… ------------------------------------------------------------------------------- - 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/ - -------------------------------------------------------------------------------

7 years, 5 months

4
3
0 0

Re: [TUHS] V7 Addendem

by jnc＠mercury.lcs.mit.edu

> I've never seen a detailed description of UNIX/TS, although I have seen > the "Unix Program Description" (January 1976) which documents the USG > version, and of course PWB is described in the BSTJ issue, and UNIX/TS > is supposedly a merge of those two. > ... > Did the later USG versions takeup some of the PWB work, does anyone > know? (My thinking is 'if I find traces of PWB [in the MIT system], > would that be from /TS, or could it be a later USG version' - I think > there were 1-3, from something I saw online.) So I seem to have stumbled on something interesting here (or maybe it's not, and the history is just unclear - well, unclear to me at least, I'm sure someone knows). Looking at "Unix Program Description" (January 1976), it's clearly marked as "Published by the UNIX Support Group". (I have an actual hardcopy, which I don't recall how I came by, but for those who wish to follow along this document is available in the TUHS archive, at: http://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_jan… and in other TUHS mirrors). So, given the credit, I _assume_ that it documents some version of the USG system. So I started looking at that, and the PWB version that's in the archive: http://www.tuhs.org/Archive/Distributions/USDL/spencer_pwb.tar.gz to see how they compare, and it turns out (somewhat to my surprise) that the USG document describes what seems to be an older version of the system. For example, in text.c, it doesn't cover xlock()/xunlock()/xexpand(), all in the PWB system - just xalloc()/xccdec()/xfree()/xswap(). Even more telling, in sys1.c, the USG document describes the older version of exec(), where arguments are collected in a disk buffer, not (as in the PWB system) in swap space. (I had thought that this change was mentioned in the PWB paper in the BSTJ issue, but on checking, it appears my memory was incorrect. Many of the PWB changes appear to be to things like the shell, not the OS.) So it seems the USG document describes a system very close to the 'classic' V6 - not what I had expected. This may also make it hard to recognize USG source (at least, the early versions). More generally, it would be good to try and elucidate the relationship among all these early Bell/AT+T versions: Research, USG, PWB, etc. Clearly the two latter (from what we know now) are descended from V6 - but was there any interchange between USG and PWB? And did either of them feed back into V7? Or, perhaps more likely, were the improvements to text.c, exec() etc _Research_ improvements that got fed into PWB? More questions than answers, sadly... I'm not at all familiar with V7, I'll have to go read it at some point, and compare it to PWB. Not that I expect it will answer many (any?) of these questions, but maybe we'll get lucky and there will e.g. be stuff in this PWB which isn't in V7. Speaking of which, I seem to recall there's more than one PWB version. I wonder which one we have (above). Although there's another 'PWB' tape in the archive: http://www.tuhs.org/Archive/Distributions/USDL/bostic_pwb.tar.gz (much larger than the other one), when I poked around a bit through that, seeing what's there, and comparing it to the other one, the system sources I looked at there all seemed to be the same as the one on the Spencer tape. > I should look at the MIT kernel and see how much of it is USG, and see > if I can find any traces of the changes described as done for PWB. I > know the MIT version has provisions for longer exec() arguments, and > text.c is considerably more complex than the one in V6 (and IIRC matches > the description in the USG document) So, my memory was in error here; the text.c matches the one from the PWB tape, _not_ the USG document. In general, the parts of the MIT system seem to be a close match to what's on the PWB tape, with the exception that the MIT one seems to be slightly earlier (no 'register' argument types). > Perhaps the MIT system really was /TS Without a better understanding of what was really in /TS, this is totally opaque. > I've always described it as a hacked PWB1, but I might be wrong there. And for once, I think I was right. The MIT system _does_ closely match the one on the 'PWB' tapes - whatever that was! Noel

7 years, 5 months

1
0
0 0

A nice review of a retrospective paper on the PDP-11

by Arnold Robbins

https://dave.cheney.net/2017/12/04/what-have-we-learned-from-the-pdp-11 Arnold

7 years, 5 months

1
0
0 0

Re: [TUHS] how do I unsubscribe

by jnc＠mercury.lcs.mit.edu

So, I'm getting the impression, from the reactions about civility, etc, that people aren't disagreeing with the characterization of "rudeness" (which can only be meaning my posts). Can someone please point to text in my messages which they consider "rude"? Thanks. Noel

7 years, 5 months

3
2
0 0

ARPAnet now 4 nodes

by Dave Horsfall

The ARPAnet reached four nodes on this day in 1969 (anyone know which?); at least one "history" site reckoned the third node was connected in 1977 (and I'm still waiting for a reply to my correction). Well, I can believe that perhaps there were only three left by then... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

3
3
0 0

looking for a quote

by ron minnich

A long time ago, dmr wrote about something that IIRC BSD had done he did not like: unlimited length identifiers in C, maybe? His argument was that being too general was not a good thing. Can't quite find the quote, anyone remember it? Would have been ca. 1980. ron

7 years, 5 months

8
11
0 0

Re: [TUHS] V7 Addendem

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > it's direct predecessor (UNIX/TS) which was not officially released made > its way to number of places ... heavily hacked systems that were combo's > of V6, PWB [1.0], UNIX/TS plus local additions. UNIX/TS had a newer > kernel, updated FS and the compiler that was released with troff - > a.k.a. 'Typesetter C' I'm not sure quite what the MIT system was. I've never seen a detailed description of UNIX/TS, although I have seen the "Unix Program Description" (January 1976) which documents the USG version, and of course PWB is described in the BSTJ issue, and UNIX/TS is supposedly a merge of those two. (If we ever do find V6+ USG source, it should be easy to verify - that document is pretty detailed.) I should look at the MIT kernel and see how much of it is USG, and see if I can find any traces of the changes described as done for PWB. I know the MIT version has provisions for longer exec() arguments, and text.c is considerably more complex than the one in V6 (and IIRC matches the description in the USG document); but I don't recall withough careful checking, what was done where. Perhaps the MIT system really was /TS, and I didn't know that - I've always described it as a hacked PWB1, but I might be wrong there. Did the later USG versions takeup some of the PWB work, does anyone know? (My thinking is 'if I find traces of PWB, would that be from /TS, or could it be a later USG version' - I think there were 1-3, from something I saw online.) I initially got /TS mixed up with /RT, which is the system I'd _really_ like to find - well, MERT, actually. I think that's a really early micro-kernel system (although I haven't done any research to confirm that), a direction I think is important. (I think the 'THE Multiprogramming System' may be the earliest work in that direction, although I'd be interested to hear of anything else.) I actually got contact info for some of the original MERT people, and was going to contact them to see if they still retained anything, but I never got a 'round tuit'... too many other projects. :-( Noel

7 years, 5 months

2
1
0 0

how do I unsubscribe

by Deborah Scherrer

Could someone please tell me how to get off this list? I was rather appalled at the rudeness in the previous conversation... Deborah

7 years, 5 months

8
10
0 0

Re: [TUHS] What UNIX Artifacts Are Still Missing?

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy > an altruistic person trying to make things better. They aren't all bad. I would echo that. During my time on the IESG, I'd say the vast majority of the people in the IETF really did want to make things better for everyone. Of course, that statement covers a vast range of subtle variations, from people who had nothing at all to gain personally, and thus really were pushing what they thought was best; through people who did stand to gain, but truly thought that what they were advocating was in everyone's interest; etc. But the people who I felt were deliberately and knowingly putting their own interests before the community's, i.e. recommending something they knew to be harmful because it was good for them - they were very rare. My recollection is now somewhat dim (too much was happening, at too high a pace) of the details of those later days (well, 'later' only in that they were considerably later than the very early days :-), but my sense is that people like that didn't last long in the community; I have the distinct impression that people figured them out, and as an eventual result, they tended to fade from the scene. The IETF culture was not welcoming to that kind of thinking. I dunno, maybe I'm just being naive (and I would certainly welcome correction if I'm wrong), but that's how I saw it. Noel

7 years, 5 months

2
1
0 0

Misguided standsads (was What UNIX Artifacts Are Still Missing?)

by Doug McIlroy

> Standards committees are not filled with altruistic folks working to > make something great. Not only in big ways, such as to sway the market. An example from Posix is the undefined meaning of malloc(0). As I understand it, just one committee member held out for malloc(0) to be an optional error, thus confounding a harmless corner case with a fatal error. This nit has burdened conscientious programmers ever since, all so one company's easily fixable variant could be grandfathered into compliance. Doug

7 years, 5 months

1
0
0 0

Early Xenix source code (was: What UNIX Artifacts Are Still Missing?)

by Paul Ruizendaal

> They might actually. Gates isn’t in charge, and there has been a major effort to being Linux compatibility into the Windows 10 kernel. I agree that they might. Once there was strong commercial logic to disown their Unix history; that commercial logic may have reversed in the last decade. > The biggest issue will be the never ending tangle of licenses, if they had other stuff integrated into there. Let’s analyse that bit: - They could pick the Nokia solution, i.e. to simply make an undertaking not to sue and thus avoid taking a position on Unix ownership etc. - It would seem that Xenix 2 (no apparent version 1?) was more or less V7 and for internal use only (lacking a binary redistribution license, as Clem pointed out). Very little chance of 3rd party source code in there, but also of little interest for the historical record. - The first real ports occur with Xenix 2.x in 1981-83. This would appear to have been based on System III with the PDP-11, Z8000, 68000 and 8086 as targets. Considering the size of MS at the time and how busy they were with IBM and DOS I don’t think they would have had much time to do more than a basic port: they contracted out much of the work to SCO, a two man shop at the time. It would seem that MS owned the IP with SCO being a contractor & part-owned subsidiary. - This Altos manual https://web.archive.org/web/20170222131722/http://www.tenox.net/docs/xenix/… actually says that Xenix 2.x was still based on V7 and would seem to be a vanilla port, i.e. unlikely to include other stuff than V7, some 2BSD and of course MS' own stuff. - The next release, Xenix 3.0 in 83-84, still appears to be SysIII based and would remain easy from that perspective. However, given two years of polishing it may have picked up bits and pieces from the outside and the tool chains probably started to include MS’ own compilers, it would be harder to figure out what could be released. However, looking at this highly interesting leaflet http://www.os2museum.com/wp/wp-content/uploads/2012/10/IBM-Seminar-Proceedi… it would seem that it is still all SysIII, BSD and Microsoft code. In my opinion the real hurdle is finding a retired MS VP who’s interested in knocking on doors and making the case for this public relations move. Paul PS: There is scope for confusion over version numbers. It would seem that MS never directly sold Xenix, only via OEM’s. For example, IBM PC Xenix 1.0 would appear to be the same as MS Xenix 3.0

7 years, 5 months

1
0
0 0

standard types

by Larry McVoy

I have my own types.h that I carry around that has stuff like typedef unsigned char u8; typedef unsigned short u16; typedef unsigned int u32; typedef unsigned long long u64; typedef signed char i8; typedef signed short i16; typedef signed int i32; typedef signed long long i64; and I wonder why the original Unix authors didn't make something similar? Instead we have uint64_t and I don't see the added value of more chars. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

7 years, 5 months

3
2
0 0

Re: [TUHS] THANK YOU for flavors! (fwd)

by Dave Horsfall

On Thu, 7 Dec 2017, Greg 'groggy' Lehey wrote: >> On Thu, 7 Dec 2017 11:01:51 +1100 (EST), Dave Horsfall wrote: > > Since we're being pedantic, note that this should be AEDT. EST is > ambiguous, but in general refers to the east coast of the USA. That appears to be how Alpine formats it (I certainly didn't write it)... If it can be overridden then naturally I'm all ears. >>> Serious question: is "FLAVOUR" accepted as an alias, or does the rest >>> of the world have to put up with American spelling? > > Think of it as a keyword. No national origin necessary. Fair enough, I suppose. > We really have better things to think of. Indeed; in the meantime I see you finally fixed your DNS... Yes, I 4xx mail from servers with an improper chain, in the hope that they'll eventually notice (it catches a lot of spammers). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

1
0
0 0

Re: [TUHS] Dash options

by Steffen Nurpmeso

Hello. ||On Wednesday, 29 November 2017 at 20:16:43 +0100, Steffen Nurpmeso wrote: ||> Greg 'groggy' Lehey <grog(a)lemis.com> wrote: ||>> On Monday, 27 November 2017 at 21:51:13 -0800, Jon Steinhart wrote: ||>>> Does anybody know the history of dash options? Were they ||>>> a UNIX thing or did UNIX borrow them from something earlier? ||>> ||>> If you mean specificall the dash, I can't help much. But there were ||>> similar ideas elsewhere. UNIVAC EXEC-8 (for the 1108, late 1960s) had ||>> options that followed the command with a comma, like: ||>> ||>> @RUN,G GOPU,STANDARD,STANDARD ||>> @ADD,PL ASGDMS . ASSIGNIERT DATENBASIS ||> ||> "WEIßT DATENBASIS ZU" or "ZUWEISUNG DATENBASIS" ... ||>> @ASG,A PF. . PF IST PROGRAMM-FILE MIT GOPU ||> ||> "PF IST PROGRAMM-DATEI MIT GOPU" or so. ... I have apologised for this brusque and rude tone in private. Unfortunately Greg Lehey was the one who took up that thread. Puh; he is also right correcting my statements, it should have been "Weist Datenbasis zu" and "PF ist Programmdatei mit GOPU" instead of what i falsely claimed. |The question that should have been asked with mild interest and |very kind should have been "Why has German been used to comment |this code?" at first, i am afraid to realize. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

7 years, 5 months

2
1
0 0

Re: [TUHS] [groff] [UTROFF] references, summary, index

by Doug McIlroy

Ralph, > > On unjustified text, fmt (which uses an algorithm purported to be like > > Knuth-Plass) > > I wonder if that accounts for modern, coreutils 8.28-1, fmt's weirdness > that I've seen for a while but never got around to investigating? > > $ yes x | fmt | awk '{print length, $0}' | uniq -c | sed 5q You threw it something of a curve ball--an infinite paragraph. At some point I suppose it chokes, and tries its best to make a semiparagraph of equal-length lines. (Since the real paragraph is not yet complete, it would be wrong to make the last line of the semiparagraph short.) Equilibrating apparently led to the split between 69- and 71-letter lines. Whether the alternation of 11 of one and 16 of the other is an infinite pattern or a subpattern is not clear. It could be part of a continued-fraction approximation, related to the staircse appearance of a bitmap "straight line". Doug

7 years, 5 months

2
1
0 0

What UNIX Artifacts Are Still Missing?

by Rudi Blom

Regarding Theodore Bashkow I found a reference in this article http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.53.880&rep=rep1&ty… "[Jain 90a], N. Jain, M. Schwartz and T. R. Bashkov, "Transport Protocol Processing at GBPS Rates.", Computer Communications Review, Vol. 20 (4), 1990, pp. 188-199." No idea if this 'bashkov' is the 'bashkow' in the 'what's missing' discussion. Cheers, rudi

7 years, 5 months

1
0
0 0

What UNIX Artifacts Are Still Missing?

by Warren Toomey

All, it's time to nudge the conversation away from debugging 2017 OOM issues and the pre-UNIX history of the Arpanet. We've been able to recover quite a deal of UNIX artifacts in the past two decades, but what artifacts (in your opinion) are still out there that we should try and unearth? Remember that the 50th anniversary is coming up in 2019. Here's my list: - more PDP-7 source code: the shell, the rest of the utilities - more 1st Edition source code: the rest of the utilities - ditto the missing bits of 3rd, 4th and 5th Editions - the Phil Foglio artwork that became a Usenix t-shirt (Armando, any ideas?) - more details on who was Ted Bashkow, and the story behind his (+ others?) analysis of the 1st Edition kernel at http://www.tuhs.org/Archive/Distributions/Research/Dennis_v1/PreliminaryUni… - a firm date on the day that Ken added pipes to the kernel :) What else should be we looking for? What physical artifacts (drawings, artwork etc.) have we missed that should be sought after? Cheers, Warren

7 years, 5 months

8
8
0 0

Re: [TUHS] V7 Addendem

by Doug McIlroy

> Was this [v7 addenda] put out by the Labs? It is definitely Research code from the Labs. How it

7 years, 5 months

2
2
0 0

V10 spell vs. spell.old?

by Aharon Robbins

Hi. What's the difference between spell.old and spell in the V10 sources? I'm guessing spell.old is the original version for the small-address-space PDP-11 and that plain spell takes better advantage of the roomier vax... Thanks, Arnold

7 years, 5 months

1
0
0 0

Re: [TUHS] shell PS1/PS2 which survive cut-paste

by Paul Ruizendaal

>> The choice of "# " and "> " interests me. Because roots prompt of >> "hash" has a side effect of making a cut-paste over it a comment in >> most shells. > > "#" as the root prompt predates # as the comment in the Bourne shell, > not to mention predating copy/paste entirely. (My understanding is that > the do-nothing command, ":" was used for comments. Talk about minimalist!) > > Same point for ">", since copy/paste didn't exist in the late 70s when > Bourne was doing the shell, it wasn't an issue. As early as V5 the (thompson) shell prompts were “#” and “%”, and “:” for a label. As the goto command exists in V4 (there is a man page for it), I would assume that those characters were used in V4 as well. So it would seem to go back to 1974. In the V7 (bourne) shell the default non-root prompt is “$”. Goto is dropped at this point. Don’t know when or where “>” was first used on Unix as a prompt character (on my boxes it still is “$”). Paul

7 years, 5 months

2
1
0 0

What UNIX Artifacts Are Still Missing?

by Paul Ruizendaal

> We've been able to recover quite a deal of UNIX artifacts in the past two > decades, but what artifacts (in your opinion) are still out there that > we should try and unearth? Remember that the 50th anniversary is coming up > in 2019. I’d be interested in anything on Spider/Datakit networking in V4-V7. (at them moment the trail starts at V8, with just a few hints in earlier source materials, and the bits that Noel found). My thinking is that there were two main lines of early networking development on Unix (and I realise that this gross simplification excludes many other worthy projects): 1. The “sockets” lineage from UoI NCP Unix -> BBN NCP Unix -> BBN TCP Unix -> 4.1a BSD -> 4.2 BSD 2. The “device” lineage from Spider -> Datakit -> UUCP -> streams -> STREAMS In the first lineage there is much material available, in the second very little. This is probably because Datakit was AT&T confidential at the time.

7 years, 5 months

1
0
0 0

Re: [TUHS] What UNIX Artifacts Are Still Missing?

by Nelson H. F. Beebe

Warren Toomey <wkt(a)tuhs.org> asks on Wed, 6 Dec 2017 08:21:13 +1000: >> - more details on who was Ted Bashkow, and the story behind his (+ others?) I found a short obituary at http://engineering.columbia.edu/web/newsletter/spring_2010/memoriam which is, in full: >> ... >> Theodore R. Bashkow Dr. Theodore R. Bashkow, professor emeritus of >> electricial engineering and computer science, died Dec. 23, 2009, at >> his home in Katonah, N.Y. See PDF version >> >> He was born in St. Louis, Mo., and attended Washington University, >> where he received his BS degree in mechanical engineering. He went on >> to receive his master’s and doctorate degrees at Stanford >> University. He served in the U.S. Air Force as a first lieutenant >> during World War II from 1943 to 1945. >> >> While in the Air Force, he served as maintenance officer and helped to >> stage the Enola Gay. In the 1950s, while at Bell Labs, Professor >> Bashkow became well known for his development of a new method for >> analyzing linear electrical networks, Professor Bashkow’s A matrix. He >> also became involved with digital computers. He joined the faculty of >> the Columbia Electrical Engineering Department in 1958 and helped >> transform the Electrical Engineering Department into the Department of >> Electrical Engineering and Computer Science. >> >> When, in 1979, this department was divided into the Electrical >> Engineering and Computer Science departments, Bashkow became one of >> the founding faculty members of Computer Science. He taught courses in >> digital logic, computer organization, and computer programming. He did >> research on parallel processing. In collaboration with Herbert >> Sullivan, he pioneered a new approach to that subject through the >> development of CHoPP, Columbia Homogeneous Parallel Processor, a >> large-scale, homogeneous, fully distributed parallel machine. A number >> of Columbia graduate students and a junior faculty member, David >> Klappholz, were also involved at various stages. >> >> In 1980, the Computer Science Department instituted an annual award in >> his honor, the Theodore R. Bashkow Award. Among his many affiliations, >> Professor Bashkow was an active member of IEEE, ACM, and Sigma Xi >> organizations. >> ... He is apparently not in Wikipedia. I then searched our local bibliography archives and found this publication-title summary (Bashkow is an uncommon name, so I didn't attempt to disambiguate the reported articles): MariaDB [bibtex]> select filename, label, substr(title,1,80) from bibtab where (author like '%Bashkow%') order by year, filename; +-------------------------+--------------------+----------------------------------------------------------------------------------+ | filename | label | substr(title,1,80) | +-------------------------+--------------------+----------------------------------------------------------------------------------+ | jacm.bib | Bashkow:1958:CPR | A ``Curve Plotting'' Routine for the Inverse Laplace Transform of Rational Funct | | ieeetranscomput.bib | Bashkow:1963:RDA | R63-106 The D 825 Automatic Operating and Scheduling Program | | ieeetranscomput.bib | Bashkow:1963:C | Contributors | | ieeetranscomput.bib | Bashkow:1963:PSD | A Programming System for Detection and Diagnosis of Machine Malfunctions | | ieeetranscomput.bib | Bashkow:1964:SCA | A Sequential Circuit for Algebraic Statement Translation | | fortran1.bib | Bashkow:1967:SDF | System Design of a FORTRAN Machine | | ieeetranscomput.bib | Bashkow:1967:SDF | System Design of a FORTRAN Machine | | ieeetranscomput1970.bib | Bashkow:1971:BSS | B71-6 System Structure in Data, Programs, and Computers | | ieeetranscomput1970.bib | Bashkow:1971:BIC | B71-2 Introduction to Computer Organization | | ieeetranscomput1970.bib | Bashkow:1973:CRO | Comment on Review of Operating Systems Survey | | ovr.bib | Sullivan77b | A Large Scale, Homogeneous, Fully Distributed Parallel Machine | | ovr.bib | Sullivan77a | A Large Scale Homogeneous Fully Distributed Parallel Machine | | sigarch.bib | Sullivan:1977:LSHb | A Large Scale, Homogenous, Fully Distributed Parallel Machine, II | | sigarch.bib | Sullivan:1977:LSHa | A large scale, homogeneous, fully distributed parallel machine, I | | ieeetranscomput1980.bib | Ghafoor:1989:BFT | Bisectional Fault-Tolerant Communication Architecture for Supercomputer Systems | | super.bib | Ghafoor:1989:BFT | Bisectional Fault-Tolerant Communication Architecture for Supercomputer Systems | | ieeetranscomput1990.bib | Ghafoor:1991:SOG | A study of odd graphs as fault-tolerant interconnection networks | +-------------------------+--------------------+----------------------------------------------------------------------------------+ 17 rows in set (2.67 sec) ------------------------------------------------------------------------------- - 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/ - -------------------------------------------------------------------------------

7 years, 5 months

1
0
0 0

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> From: Jon Forrest > LBL has never been part of UC Berkeley. It's (always?) been a > Department of Energy laboratory managed by the Univ. Actually, I think if you go back far enough (1930's), it was part of UCB, back when Lawrence first started it. And of course the DoE didn't exist until 1977, so during the early ARPANET era if would have been under the AEC, and then I assume the Energy Research and Development Administration after 1974 (I assume it didn't go with the NRC when the AEC was split up). Noel

7 years, 5 months

1
0
0 0

Re: [TUHS] ARPAnet now 4 nodes

by Paul Ruizendaal

This page: http://www2.lbl.gov/Publications/75th/files/exhibit.html mentions 3 links between LBL and Arpanet: - In 1974, the Lab’s CDC 6600 became the first online supercomputer when it was connected to ARPANET, the Internet’s predecessor. - In 1986, when the Internet was on the verge of collapse from congestion, a Berkeley Lab researcher, Van Jacobson, co-developed the congestion control algorithms that allowed the Internet to keep growing. - In 1995, Jacobson and Steven McCanne developed MBone, the first successful software for multiparty audio and video conferencing over the Internet.

7 years, 5 months

3
2
0 0

Re: [TUHS] ARPAnet now 4 nodes

by Paul Ruizendaal

I don’t think anybody was thinking you wilfully misrepresented things, it is always interesting to hear about strands of history that might have been missed earlier. It would be helpful to better understand the time period, people involved and the scope of work. I’m a bit confused as to what time period you are referring to: I think you are referring to the initial development of Arpanet, i.e. the second half of the sixties. Is that correct? There is a page here with some info on events in that period and it may have missed some interesting development work done at LBL: https://www.livinginternet.com/i/ii_roberts.htm Paul > > Message: 7 > Date: Mon, 4 Dec 2017 19:46:21 -0800 > From: Deborah Scherrer <dscherrer(a)solar.stanford.edu> > To: tuhs(a)minnie.tuhs.org > Subject: Re: [TUHS] ARPAnet now 4 nodes > Message-ID: <8254fc85-12e6-4730-8f14-faf060ad6a70(a)solar.stanford.edu> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Yes, Van Jacobson was involved. Great guy. So sorry you feel the need > to think I am lying. Why would I make up this stuff? I was a > teeny tiny piece of it. Doesn't affect my career one way or other. I > don't care what you believe, but this really did happen. > > D

7 years, 5 months

1
0
0 0

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> From: Deborah Scherrer > I don't know about the historical record. But everything I said is true, > based on my own personal experience. ... I was there, this happened. If > people didn't write it down, I don't know why. FWIW, I was actually at many of those meetings. (You can find my name in a lot of those Meeting Notes.) Nobody from LBL, or UCB in general, was involved - and the Meeting Notes (which, you will note, are quite detailed) indicate the same thing. (Later on, of course, Van Jacobson of LBL did some imporant work on TCP congestion control, but that was in '87 or so - I can't instantly lay my hands on my copy of Van's famous e-mail, to get a more exact date - some years after the full-scale deployment of TCP/IP in January, 1983.) > Why would I misrepresent? Perhaps you are conflating several different things in your memory? Human memory is very fallible, which is why historians prefer contemporary documents (and even those sometimes have errors). Here: http://www.chiappa.net/~jnc/nontech/tmlotus.html is a mildly amusing example (from a completely different arena) of all that. Noel

7 years, 5 months

3
2
0 0

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> From: Deborah Scherrer <dscherrer(a)solar.stanford.edu> > A lot of the TCP/IP development was done at the Lab. I think this is incorrect. The "Birth of the Internet" plaque: http://ana-3.lcs.mit.edu/~jnc/history/BirthInternetL.jpg mentions a number of organizations, but not UCB. Also, if you look at early TCP/IP Meeting Notes, which list all the meeting attendees, e.g.: http://www.postel.org/ien/txt/ien3.txt http://www.postel.org/ien/txt/ien121.txt http://www.postel.org/ien/txt/ien134.txt http://www.postel.org/ien/txt/ien121.txt http://www.postel.org/ien/txt/ien160.txt http://www.postel.org/ien/txt/ien175.txt (plus a bunch more only available in PDF form here: http://www.postel.org/ien/pdf which I couldn't be bothered to look at, since they are huge scans which take a while to download - see the IEN Index for the numbers) you won't find anyone from UCB listed in any of them. Berkeley did produce a now-common _implementation_ of TCP/IP, it's true, but it had nothing to do with the "development" of TCP/IP. Noel

7 years, 5 months

2
1
0 0

signals and blocked in I/O

by Larry McVoy

Does anyone remember the reason that processes blocked in I/O don't catch signals? When did that become a thing, was that part of the original design or did that happen in BSD? I'm asking because I'm banging on FreeBSD and I can wedge it hard, to the point that it won't recover, by just beating on tons of memory. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

7 years, 5 months

13
29
0 0

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> From: Deborah Scherrer > the initial research on the arpanet was done at Lawrence Berkeley Lab I was interested to find out more about this: I looked in Hafner, "Where Wizards Stay Up Late" (the popular, but well-researched, book on the ARPANET) but couldn't find 'Lawrence Berkeley' or 'LBL' in the index (although it did have Lawrence Livermore); there were a couple of 'Californa, University of (at Berkeley' listings, but none covered this. In Abbate, "Inventing the Internet" (the first half of which covers the ARPANET), nothing under any of 'Lawrence Berkeley', 'LBL', 'Berkeley' or 'California'. In Norberg/O'Neill, "Transforming Computer Technology" (the standard ARPA history, which has extensive coverage of the ARPANET project), there was one entry for 'Californa, University (Berkeley)', which might be about the work you refer to: "IPTO issued a contract for a 'network' project at the Berkeley campus of the University of California ... because of the presence at Berkeley of specialists in programming languages and heuristic programming". But there's nothing about what was produced. Is there anything you can point me at that provides more detail? Thanks! Noel

7 years, 5 months

3
3
0 0

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> SRI, UCSD, UCLA, Utah: Ooops, typo: UCS_B_. Noel

7 years, 5 months

1
0
0 0

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > The ARPAnet reached four nodes on this day in 1969 (anyone know which?) SRI, UCSD, UCLA, Utah: http://www.chiappa.net/~jnc/tech/arpageo.html All West Coast, plus Utah. Next was BBN; if you look at the IMP numbers, in HOSTS.TXT, they were assigned in order of installation. > at least one "history" site reckoned the third node was connected in > 1977 ... Well, I can believe that perhaps there were only three left by > then... No: http://www.chiappa.net/~jnc/tech/arpalog.html 1977 was not too many years before the peak in size (with the MILNET split coming in October, 1983). Per: http://www.chiappa.net/~jnc/tech/arpanet.html "Prior to the split, in 1983, there were 113 IMPs in the ARPANET; after the ARPANET/MILNET split, the MILNET consisted of 65 nodes, leaving the ARPANET with 68 nodes." Noel

7 years, 5 months

1
0
0 0

Re: [TUHS] RIP J.F.Ossanna

by Larry McVoy

On Wed, Nov 29, 2017 at 08:00:55PM +0100, Steffen Nurpmeso wrote: > Larry McVoy <lm(a)mcvoy.com> wrote: > |On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote: > |> 1977 marks my entry into the world of UNIX. I've always stated there was > |> only one person who truly understood nroff and he was dead. > |> I mourn the fact that of all the UNIX greats I've met, I missed out on > |> Ossanna. > > |I think one could argue that James Clark has a pretty good handle on > |roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc). > > And Werner Lemberg, who carried the torch for the last almost two > decades. He brought in some really great improvements, like > arguments for strings, which allows to write pretty much TeX like > a.k.a. inline if you want to (as in "this is \*[I talic] text"). Yep. James exited stage left and Werner stepped in. I mean no disrespect to anyone, I was just saying that James has a really good handle on roff, he redid it all. I admire him for doing so (even though I curse the fact that he did it in C++).

7 years, 5 months

3
3
0 0

Unix on PDP8?

by Will Senn

All, Was Unix ever ported to a PDP8, or any other 12 bit environment, for that matter? If not, why not? My understanding, such as it is, is that Unix was created on the PDP7 - btw, thank you very much, Ken Thompson, you definitely changed my world :), which is an 18bit machine, and that it soon found its first real home on the 16 bit PDP11 series of machines (an 11/20), and from there, ever upward or at least ever onward. I'm curious about it for historical reasons, of course, but also because I've been messing around in the PDP8 emulation world and enjoying the excursion into simplified ISA and memory architectures. -will

7 years, 5 months

8
12
0 0

Re: [TUHS] UNIX on S/370

by Larry McVoy

So tape I can see being more weird, but isn't raw disk just "don't put it in buffer cache"? >From what I've been able to gather early tape in Unix was dicey, something about the driver doing seek. Was there more to it than that? On Tue, Nov 21, 2017 at 02:33:55AM +0000, Clem Cole wrote: > It???s not so much that they don???t mix, it???s not quite the same. Some > coprocessor ideas work really well into the Unix I/O model, others don't. > Raw disk and tape I/O ala a PDP11 or VAX for instance is not easy on an > IBM channel controller or a CDC PPU. > > > > > > > > > On Mon, Nov 20, 2017 at 6:45 PM Larry McVoy <lm(a)mcvoy.com> wrote: > > > On Mon, Nov 20, 2017 at 06:43:28PM -0500, Ron Natalie wrote: > > > > > > > > > > I get that PDP-11 and VAX used memory mapped I/O but was that somehow > > > exposed above the device driver layer? If so, I missed that, because I > > had > > > no conceptual or technical problem with talking to an I/O > > > > > > > channel, it was pretty easy. And I suck at writing drivers. > > > > > > There's nothing that restricts a device driver to memory mapped I/O. > > You > > > do what ever you have to do to initiate the I/O. Even the x86's > > originally > > > used special instructions to start the I/O (in/out). The DENELCOR HEP > > > supercomputer (we did this port around 1983) we had to bounce I/O > > requests > > > off a separate I/O processor different from where the kernel was running. > > > Similar constucts were used on other machines. > > > > Yeah, that's what I thought. But other people were saying that I/O > > processors and Unix didn't mix. I don't get that, seems like whatever > > the model is is hidden under the driver, that's the whole point of the > > driver design is it not? > > > -- > Sent from a handheld expect more typos than usual -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

7 years, 5 months

3
2
0 0

Re: [TUHS] Dash options

by jnc＠mercury.lcs.mit.edu

> From: Charles Anthony > Entry points are usually defined as "foo$bar", where "foo" is the > segment name, and "bar" an entry point in the segment symbol table. I > believe that the degerate case of "foo$" is treated as "foo$foo" by the > shell. So I'm curious about how this, and additional names, interact. (For those who aren't familiar with Multics, a segment [file, sort of] can have multiple names. This is sort of like 'hard links' in Unix, except that in Multics one name, the "primary name" is very slightly preeminent. See here: http://web.mit.edu/multics-history/source/Multics/mdds/mdd006.compout page 2-5, for more, if you're interested.) So if I have a segment with primary name 'foo', and additional names 'bar' and 'zap', and I say 'zap' to the Multics shell, I assume it does a call to zap$zap, which finds the segment with the primary name 'foo', and calls the 'zap' entry therein? > Multics rulez; UNIX droolz Dude, you clearly have Very Large brass ones to send that to this list! :-) Noel

7 years, 5 months

2
1
0 0

Dash options

by Jon Steinhart

Does anybody know the history of dash options? Were they a UNIX thing or did UNIX borrow them from something earlier? Jon

7 years, 5 months

10
10
0 0

Re: [TUHS] Dash options

by Doug McIlroy

Early on, when multics was understood to have one big, segemented address space, it was expected that PL/I name qualification ($) would serve to address segments. I do not know whether that idea was actually implemented. Doug

7 years, 5 months

3
2
0 0

/bin/true (was [TUHS] basic tools / Universal Unix)

by Ron Natalie

My favorite reduction to absurdity was /bin/true. Someone decided we needed shell commands for true and false. Easy enough to add a script that said "exit 0" or exit 1" as its only line. Then someone realized that the "exit 0" in /bin true was superfluous, the default return was 0. /bin/true turned into an empty, yet executable, file. Then the lawyers got involved. We got a version of a packaged UNIX (I think it was Interactive Systems). Every shell script got twelve lines of copyright/license boilerplate. Including /bin true. The file had nothing but useless comment in it.

7 years, 5 months

15
22
0 0

Re: [TUHS] Dash options

by jnc＠mercury.lcs.mit.edu

> Multics had some kind of `attach' and `detach' of I/O streams, well > known to Ossanna, so perhaps dup(2), and a Thompson-shell syntax to go > with it meant `>' was earmarked early on. According to "The Evolution of the Unix Timesharing System", full path names arrived later than I/O redirection, so by they time they needed a separator, '>' and '<' were gone. '/' also has the advantage of being a non-shift character! Noel PS: Re-reading that, I see that early Unix did not have an exec() call (as I was just discussing); it was done in user mode, with normal read and write calls.

7 years, 5 months

3
2
0 0

Re: [TUHS] Dash options

by Paul Ruizendaal

> On Tue, Nov 28, 2017 at 2:36 PM, Paul Winalski <paul.winalski(a)gmail.com> > wrote: > >> MS/DOS patterned its command line >> >> syntax after RT-11 and inherited the slash as a command option >> introduction from there. > > Minor correction... To do a CDC style patient zero history ;-) RT11 took > it from DOS/8, CP/M took it from RT11, then finally DOS-86 which became > PC-DOS ney MS/DOS took it from CP/M. I think Gary Kildall was very much into the PDP-8 when teaching at the Naval Post Graduate School in the early 70's (doing the FORTRAN/8 compiler for instance). Can't find the link now, but I read somewhere that his work with the 8008 and 8080 was guided by the idea of having a PDP-8 like machine in his home office. For CP/M's command syntax RT11 probably did not come into it. I just had a quick glance through the CP/M 1.4 - 2.2 manuals, and I did not see slash options (or any other option character). Microsoft bought QDOS as a base for PC-DOS/MS-DOS. The QDOS system calls were done such that converting existing 8080 CP/M code with Intel's source level 8080-to-8086 asm converter would generate the correct code. The FAT file system was modeled after the one used by MS Disk BASIC for the 8086. Not sure where the QDOS command line came from, other than CP/M. MS did a lot of its early development on a PDP-10: perhaps that was an inspiration too. Sorry for getting off-Unix-topic...

7 years, 5 months

1
0
0 0

Re: [TUHS] Harvard and Von Neumann Architectures and Unix

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy > But if that had been in D space, it couldn't have been executed. Along those lines, I was wondering about modern OS's, which I gather for security reasons prevent execution of data, and prevent writing to code. Programs which emit these little 'custom code fragments' (I prefer that term, since they aren't really 'self-modifying code' - which I define as 'a program which _changes_ _existing_ instructions) must have some way of having a chunk of memory into which they can write, but which can also be executed. > Where is the boundary between changing one instruction and changing them > all? Or is this boundary a figment of imagination? Well, the exec() call only overwrites existing instruction memory because of the semantics of process address space in Unix - there's only one, so it has to be over-written. An OS operating in a large segmented single-level memory could implement an exec() as a jump.... BTW, note that although exec() in a single address-space OS is conventionally something the OS does, this functionality _could_ be moved into the user space, provided the right address space primitives were provided by the OS, e.g. 'expand instruction space'. So the exec() code in user space would i) find the executable, ii) see how much of each kind of memory it needs, iii) get the OS to give it a block of memory/address space where the exec() code can live while it's reading in the new code, iv) move itself there, v) use standard read() calls to read the new image in, and then vi) jump to it. Yes, it's probably simpler to implement it in the OS, but if one's goal is to minimize the functionality in the kernel... Noel

7 years, 5 months

9
9
0 0

A sober reminder of why distributed archiving is important

by Will Senn

In case you missed it: https://www.spectrum.ieee.org/view-from-the-valley/tech-history/silicon-rev… It is important to keep the conversations alive and not to file your memory boxes away in the attic. Thanks for sharing what you know and especially for making your documents and bits available. -will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

7 years, 5 months

2
1
0 0

TTY8

by Ron Natalie

OK, we were discussing terminals this morning with some other old guys. If I knew the answer to this I've forgotten. Every PDP-11 UNIX I ever used had the console KL-11 as /dev/tty8. The question is why. My guess is that for some reason an 8 terminal multiplexor (DZ-11?) was stuck at tty0, but why?

7 years, 5 months

4
3
0 0

Re: [TUHS] Harvard and Von Neumann Architectures and Unix

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy >> they aren't really 'self-modifying code' - which I define as 'a program >> which _changes_ _existing_ instructions > Isn't that how dtrace works? I'm not familiar with dtrace(), but if it modifies some other routine's code, then it would not be "self" modifying, right? Oh, another category, sort of like biological viruses (which are in a grey zone between 'alive' and not): the PDP-11 paper tape bootstrap: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/bootloader.mac in which the program's own code _is_ modified - but not by program instructions, but by data on the paper tape it is reading in. It's entertainingly convoluted (the copy above should be well-enough commented to make it pretty easy to understand what's going on). Noel

7 years, 5 months

2
1
0 0

RIP J.F.Ossanna

by Dave Horsfall

We lost J.F. Ossanna on this day in 1977; he had a hand in developing Unix, and was responsible for "roff" and its descendants. Remember him, the next time you see "jfo" in Unix documentation. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

3
3
0 0

Re: [TUHS] UNIX on S/370

by jnc＠mercury.lcs.mit.edu

> From: Kevin Bowling > The earliest stuff may be covered by Novell's grant of early code. > ... > Would be fun to run *ix on any of them. Alas, the Bell port of Unix to the /370 needs that underlying layer of code from IBM, and that's probably not going to escape. Too bad, it would be pretty cool. Noel

7 years, 5 months

2
1
0 0

Harvard and Von Neumann Architectures and Unix

by Will Senn

I am curious about how the Harvard Architecture relates to Unix, historically. If the Harvard Architecture is predicated on the separation of code from data in order to prevent self-modifying code (my interpretation), then it would seem to me to be somewhat at odds with a Unix philosophy of extreme abstraction (code, data, it's all 0's and 1's, after all). In my naive understanding, the PDP-11 itself, with the Unibus and apparently agnostic ISA seem to summarily reject the Harvard Architecure... My question is - was there tension around Harvard and Von Neumann architectures in Unix circles and if so, how was it resolved? Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

7 years, 5 months

3
2
0 0

Datakit in V7

by Paul Ruizendaal

There are some little bits in the public V7 source code that suggest that it had support for Datakit, but that it was scrubbed from the public release: There is a Datakit header file: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/dk.h and Datakit state bits are defined in 'sys/tty.h': http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/sys/tty.h Does anyone know if this assumption (Datakit support in V7) is correct? Perhaps more specific, was there a remote login program for V7/Datakit, of for V6/Spider? For V8/Datakit there was 'dcon', but perhaps this was built on earlier programs. (I'm aware of 'cu' of course, but that does not support Datakit or Spider). Being able to login to another host on the network seems so useful that it is hard to believe that a precursor to 'dcon' did not exist for V6 and/or V7.

7 years, 5 months

1
0
0 0

Re: [TUHS] TCP/IP networking in 8th edition unix

by Paul Ruizendaal

Thanks for explaining that. I think it may be for 10th edition though. I searched for ipcopen() and 'gated' in the 8th edition source and could not find them. In that search I did find a few bits that strongly suggest that IP over Datakit was what was used in late '85 (when dmr posted about this). In /usr/src/cmd/inet/READ_ME there is an example configuration that seems to match with dmr's example. In that file an IP over a Datakit channel appears to be configured. (see http://chiselapp.com/user/pnr/repository/v8unix/artifact/6d09b05c7f06a2cc?l…) The program 'dkipconfig' sets up a circuit and pushes the IP discipline on the stream, both on the local end and on the remote end. It sets fixed local and remote addresses, much the same as with a 'slip' line. (see http://chiselapp.com/user/pnr/repository/v8unix/artifact/6c5f3267b58721a6?l…) On Sat, Nov 25, 2017 at 4:50 PM, William Cheswick <ches at cheswick.com> wrote: > > Nope, not IP over Datakit, as I recall. It was quite interesting to work at > a site (Bell Labs) where there were two distinct network technologies. > > [--snip--] > > This library was socks about seven years before socks, originally written by > Presotto and Howard Trickey. The relay program was originally called > “gated”, but that wouldn’t do after a while. I renamed it “proxyd”, and > that is the first use of “proxy" in this context that I am aware of. > > If you were on AT&T’s intranet and wanted to connect externally, you ripped > out the entire socket dance and replaced it with an ipcopen call. I also > distributed common modified clients, like ptelnet, pftp, pfinger, etc. > > I still have all this code, and I suppose it ought to go in an archival > repository. I can’t imagine that AT&T/Lucent/Alcatel/Nokia would care at > this point. Anyone want it? >

7 years, 5 months

1
0
0 0

TCP/IP networking in 8th edition unix

by Paul Ruizendaal

I'm trying to figure out how tcp/ip networking worked in 8th edition Unix. I'm starting from dmr's paper about streams (http://cm.bell-labs.co/who/dmr/st.html) the V8 man pages (http://man.cat-v.org/unix_8th/3/) and browsing the source code (tarball here http://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/) In the below I use 'socket' to mean a file descriptor bound to a network connection. My current understanding is like this: - The hardware interface is exposed as a character device; for tcp/ip only ethernet is supported. Directly accessing this device reads/writes ethernet frames. - One can push an 'ip' module (only) onto an ethernet device; this module also handles ARP. Once this is done IP messages are queued to the virtual ip devices, /dev/ipXX. The device minor number XX equals the protocol number, i.e. the ip packets are demultiplexed into separate virtual devices. IP packets from multiple ethernet cards all end up on the same virtual ip devices. I'm not sure if one can still read/write to the ethernet device after pushing the ip module, but I think you can, creating a raw IP interface so to say. - On /dev/ip6 one can push a TCP module. The TCP module handles the TCP protocol and demultiplexes incoming traffic to the virtual /dev/tcpXX devices. On /dev/ip17 one can push a UDP module. The UDP module handles the UDP protocol and demultiplexes incoming traffic to the virtual /dev/udpXX devices. Not sure wether the ip6 and ip17 devices can still be read/written after pushing these disciplines. - There are 100 udp devices, /dev/updXX. To open a UPD socket, one opens an unused udp device (through linear search). This socket accepts binary commands ('struct upduser') through the read()/write() system calls. There is a command to set the local port (effectively 'bind') and a comment to also set the foreign address and port (effectively 'bind+connect'). As long as the socket is not connected actual datagrams are preceded by a command header with the address/port information (effectively 'sendto'/'recvfrom'). Once the socket is connected, it is no longer possible to send further commands, but each write/read is a datagram. For udp sockets it is not possible to specify the local address: it is chosen by the system to match with the given foreign address. - There are 100 tcp devices /dev/tcpXX. Initial connection is always over an odd numbered device. To open a TCP socket, one opens an unused tcp device (through linear search). This socket accepts binary commands ('struct tcpuser') through the read()/write() system calls. There is a command to actively connect (effectively 'connect' with optional 'bind'), and a command to passively listen (effectively 'bind'+'listen'). If the connect command is sent, one can read one more response block and then the socket becomes a regular tcp socket. If the listen command is sent, one can read multiple response blocks, one for each new client (effectively 'accept'). Those response blocks contain a device number for the new client connection, i.e. one has to subsequently open device /dev/tcpXY to talk to the client. This number is always even, i.e. locally initiated tcp connections are over odd numbered tcp devices, and remotely initiated connections are over even numbered tcp devices - not sure what the significance of this is. - The above seems to be modeled on the Datakit setup, where the network is exposed as 520 virtual devices, one for each channel, as /dev/dk/dkXXX. These channels than also seem to accept binary command blocks through the read()/write() interface, with a 'connect' type command changing the connection into a data only channel. Anybody on the list with 8th edition experience who can confirm that the above understanding is about correct? Paul

7 years, 5 months

4
4
0 0

Re: [TUHS] Harvard and Von Neumann Architectures and Unix

by jnc＠mercury.lcs.mit.edu

> From: Will Senn <will.senn(a)gmail.com> > I am curious about how the Harvard Architecture relates to Unix, > historically. If the Harvard Architecture is predicated on the > separation of code from data in order to prevent self-modifying code (my > interpretation) That's not the 'dictionary' definition, which is 'separate paths for instructions and data'. But let's go with the 'no self-modifying code' one for the moment. The thing is that self-modifying code is pretty much an artifact of the dawn of computers, before the economics of gates moved from that of tubes, to transistors, and also before people understood how important good support for subroutines was. (This latter is a reference to how Whirlwind did subroutines, with self-modifying code.) Once people had index registers, and lots of registers in general, self-modifying code (except for a few small, special hacks like bootstraps which had to fit in tiny spaces) became as dead as the dodo. It's just a Bad Idea. > then it would seem to me to be somewhat at odds with a Unix philosophy > of extreme abstraction (code, data, it's all 0's and 1's, after all). The people who built Unix were fundamentally very practical. Self-modifing code is not 'practical'. (And note that Unix from V4: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/text.c onward has support for pure text - for practical reasons). > the PDP-11 itself, with the Unibus and apparently agnostic ISA seem to > summarily reject the Harvard Architecure... You could say that of a zillion computers. The only recent computer I can think of offhand with separate instruction and data paths was the AMD 42K (nice chip, I used it in a product we built at Proteon). They had separate ports for instructions and data purely for performance reasons. (Our card had a pathway which allowed the CPU to write the instruction memory, needed during booting, obviously; the details as to how we did it escape me now.) > From: Jon Steinhart > For all intents and purposes instructions were separate from data from > the PDP 11/70 on. s/70/45/. And the other -11 memory management (as on the /40, /23, etc) does allow for execute-only 'segments' (they call them 'pages' in the later versions of the manual, but they're not) - again, separating code from data. Unix used this for shared pure texts. And note that those machines with separate I+D space don't meet the dictionary definition either, because they only have one bus from the CPU to memory, shared between data and instruction fetches. Noel

7 years, 5 months

5
5
0 0

Re: [TUHS] Harvard and Von Neumann Architectures and Unix

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy > Optimal code for bitblt (raster block transfers) in the Blit Interesting case. I'm not familiar with BitBLT codes, do they actually modify the existing program, or rather do they build small custom ones? Only the former is what I was thinking of. Noel

7 years, 5 months

5
4
0 0

Re: [TUHS] Harvard and Von Neumann Architectures and Unix

by Doug McIlroy

>From the discussion of self-modifying code: >> Optimal code for bitblt (raster block transfers) in the Blit > > Interesting case. I'm not familiar with BitBLT codes, do they actually modify > the existing program, or rather do they build small custom ones? Only the > > former is what I was thinking of. > It built small custom fragments of code. But if that had been in D space, it couldn't have been executed. >> Surely JIT compiling must count as self-modifying code. > > If it does, then my computer just runs one program from when I turn it > on. It switches memory formats and then is forever extending itself and > throwing chunks away. Exactly. That is the essence of stored-program computers. The exec system call is self-modification with a vengeance. Fill memory-and-execute is the grandest coercion I know. What is data one instant is code the next. It's all a matter of viewpoint and scale. Where is the boundary between changing one instruction and changing them all? Or is this boundary a figment of imagination? Doug

7 years, 5 months

1
0
0 0

Re: [TUHS] TTY8

by jnc＠mercury.lcs.mit.edu

> From: "Ron Natalie" > Every PDP-11 UNIX I ever used had the console KL-11 as /dev/tty8. > The question is why. Blast! I have this memory of reading an explanation for that somewhere - but I cannot remember what it was, or where! I've done a grep through my hoard of Unix documents, looking for "tty8", but no hits. Noel

7 years, 5 months

1
0
0 0

Re: [TUHS] Harvard and Von Neumann Architectures and Unix

by Doug McIlroy

> The thing is that self-modifying code is pretty much an artifact of the dawn > of computers, [...] > > It's just a Bad Idea. Surely JIT compiling must count as self-modifying code. Optimal code for bitblt (raster block transfers) in the Blit

7 years, 5 months

4
3
0 0

Re: [TUHS] Spell - was tmac: Move macro diagnostics away from `quotes'

by Doug McIlroy

Repeat, slightly modified, of a previous post that got shunted to the attachment heap. > I am curious if anyone on the list remembers much > about the development of the first spell checkers in Unix? Yes, intimately. They had no relationship to the PDP 10. The first one was a fantastic tour de force by Bob Morris, called "typo". Aside from the file "eign" of the very most common English words, it had no vocabulary. Instead it evaluated the likelihood that any particular word came from a source with the same letter-trigram frequencies as the document as a whole. The words were then printed in increasing order of likelihood. Typos tended to come early in the list. Typo, introduced in v3, was very popular until Steve Johnson wrote "spell", a remarkably short shell script that (efficiently) looks up a document's words in the wordlist of Webster's Collegiate Dictionary, which we had on line. The only "real" coding he did was to write a simple affix-stripping program to make it possible to look up plurals, past tenses, etc. If memory serves, Steve's program is described in Kernighan and Pike. It appeared in v5. Steve's program was good, but the dictionary isn't an ideal source for real text, which abounds in proper names and terms of art. It also has a lot of rare words that don't pull their weight in a spell checker, and some attractive nuisances, especially obscure short words from Scots, botany, etc, which are more likely to arise in everyday text as typos than by intent. Given the basic success of Steve's program, I undertook to make a more useful spelling list, along with more vigorous affix stripping (and a stop list to avert associated traps, e.g. "presenation" = pre+senate+ion"). That has been described in Bentley's "Programming Pearls" and in http://www.cs.dartmouth.edu/~doug/spell.pdf. Morris's program and mine labored under space constraints, so have some pretty ingenious coding tricks. In fact Morris has a patent on the way he counted frequencies of the 26^3 trigrams in 26^3 bytes, even though the counts could exceed 255. I did some heroic (and probabilistic) encoding to squeeze a 30,000 word dictionary into a 64K data space, without severely affecting lookup time. Doug

7 years, 6 months

4
3
0 0

Re: [TUHS] Spell - was tmac: Move macro diagnostics away from `quotes'

by Nelson H. F. Beebe

BibTeX entries for the complete contents of the Bell System Technical Journal family are in the TeX User Group archives at http://www.math.utah.edu/pub/tex/bib/bstj1970.bib [change 1970 to other decades, and .bib to .html for live hyperlinks]. The PDF URLs for bstj.bell-labs.com no longer work, and the ones for www.alcatel-lucent.com, such as http://www.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-2155.pdf now redirect to an HTML page. Otherwise, articles are available from the Wiley site at http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)1538-7305/issues/ but are behind a paywall. There are also copies in the IEEE eXplore database at http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?reload=true&punumber=6731002 I tried to find the URLs at https://web.archive.org/, but it does appear to have them. ------------------------------------------------------------------------------- - 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/ - -------------------------------------------------------------------------------

7 years, 6 months

8
8
0 0

Re: [TUHS] Spell - was tmac: Move macro diagnostics away from `quotes'

by jnc＠mercury.lcs.mit.edu

> From: "Nelson H. F. Beebe" > The PDF URLs for bstj.bell-labs.com no longer work, and the ones for > www.alcatel-lucent.com ... now redirect to an HTML page. With any luck, someone scraped them before they went. I've gotten in the habit of scraping all the Web content I look at, since it has (as above) a distressing tendency to vapourize. Noel

7 years, 6 months

2
1
0 0

Re: [TUHS] A man easter-egg (gimme gimme gimme)

by Nemo

On 24 November 2017 at 10:11, Nemo <cym224(a)gmail.com> wrote: > On 22 November 2017 at 03:48, <arnold(a)skeeve.com> wrote (in part): >>> As a former developer and manager, I would be really pissed off if my >>> programmers wasted their time on writing useless frippery instead of >>> quality code, and I would certainly have a little chat with them... >> >> I think that this is totally appropriate for code being developed >> for a paid product. > > I would say this is context-sensitive (industry, customers, ...). One > version of MS Word had an animation of a cartoon monster crushing "WP' > (somewhere in the credits, I recall). > > N. I really must be more careful with replies. The above was meant for TUHS, not just Arnold. N.

7 years, 6 months

1
0
0 0

First CRT terminal on Unix?

by Nigel Williams

I stumbled into a reddit post on Unix with the claim about early Unices only being accessed via printing terminals, and it suggested a question to me as to the first “glass teletype” or CRT terminal to be used with Unix. Given the DEC-centric nature of early Unix I would guess perhaps a VT05 or VT52 but I’m keen to know if anyone from those early years recollects what happened and when regarding Unix terminal access alternatives aside from the venerable 33KSR or 33ASR.

7 years, 6 months

10
19
0 0

A man easter-egg (gimme gimme gimme)

by Edouard KLEIN

Hi all, An easter-egg in the version of man that is installed on the most popular Linux distros has recently been discovered after being there for 6 years: https://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gi… It is for example discussed here: https://news.ycombinator.com/item?id=15747313 It makes man print 'gimme gimme gimme' if called at "Half past twelve", as in the ABBA song. I check on BSD, but man seems to be a shell script on FreeBSD, so it's immune from the easter egg: https://github.com/freebsd/freebsd/blob/master/usr.bin/man/man.sh Do you have any UNIX easter-egg stories ? Putting some in, or discovering one... Was this kind of humor tolerated in the professional settings where UNIX first circulated, or was it frowned upon ?

7 years, 6 months

10
13
0 0

Re: [TUHS] A man easter-egg (gimme gimme gimme)

by jnc＠mercury.lcs.mit.edu

> From: "Ron Natalie" > After making a stink about it, Proteon removed (or just changed) the > password. We added a 'disable field service password' option to the configuration (for those who wanted to keep FS out), changed the password (since the old one was blown), and stored the new one in encrypted form - hence the message! :-) Noel

7 years, 6 months

1
0
0 0

OT: XPL compiler available

by Arnold Robbins

Path: eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!adore2!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Shoefoot <shoefoot(a)gmail.com> Newsgroups: comp.compilers Subject: Announcing the initial release of an XPL Compiler Date: Tue, 21 Nov 2017 09:25:43 -0800 (PST) Organization: Compilers Central Sender: news(a)iecc.com Approved: comp.compilers(a)iecc.com Message-ID: <17-11-001(a)comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="19370"; mail-complaints-to="abuse(a)iecc.com" Keywords: history, translator Posted-Date: 21 Nov 2017 14:37:00 EST X-submission-address: compilers(a)iecc.com X-moderator-address: compilers-request(a)iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: feeder.eternal-september.org comp.compilers:3921 Announcing the initial release of the XPL to C source translator. The XPL language is a dialect of PL/I created by McKeeman, Horning and Wortman and documented in their book "A Compiler Generator" published in 1970. XPL is a procedural language with structured program flow. The language supports integer arithmetic and logical operations. XPL supports dynamic string variables and powerful character string manipulation features. The compiler and the runtime are written in C. The compiler generates C source so anyone with a working C compiler can compile and execute code written in XPL. XPL and the BNF analyzer were the cutting edge of compiler technology 50 years ago. This release includes both the compiler and the BNF analyzer written in the late 60s. You can download the source here: https://sourceforge.net/projects/xpl-compiler

7 years, 6 months

1
0
0 0

Re: [TUHS] A man easter-egg (gimme gimme gimme)

by arnold＠skeeve.com

Warner Losh <imp(a)bsdimp.com> wrote: > On Wed, Nov 22, 2017 at 9:11 AM, <arnold(a)skeeve.com> wrote: > > > Ian Zimmerman <itz(a)very.loosely.org> wrote: > > > > > On 2017-11-22 01:48, arnold(a)skeeve.com wrote: > > > > > > > Try: > > > > > > > > gawk --nostalgia > > > > > > ~$ gawk --nostalgia > > > awk: bailing out near line 1 > > > Aborted > > > > > > Maybe it still needs a program? > > > > No, that was the joke. Early Unix awk used to say exactly that > > message, on almost any problem, often followed by a core dump. > > > > (I never claimed the easter egg was non-lame.) > > > > There were T-Shirts of this at early conferences as well. Showed a picture > of a vaguely puffin-like bird baling of an airplane made up of what looked > like ascii characters {}()|/... Google is unable find one though, so my > memory may be rusty here... > > Warner I have such a shirt. Maybe I can scan it. :-) Arnold

7 years, 6 months

1
0
0 0

Re: [TUHS] APPLIX-L EPROM programmers

by Dave Horsfall

On Thu, 23 Nov 2017, Matthew Geier wrote: > There is a brake computer for the centre bogie and a microprocessor in > the auxillary converter too. Centre bogie? How does that work on curves? Or is it part of the coupler? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 6 months

1
0
0 0

UNIX on S/370

by Nemo

Recent commentary on porting led me to read the article on porting UNIX to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf) to support 5ESS development because the existing PDP11s were being overwhelmed. I confess to not having this read this before and find it interesting. Any recollections from anyone on the matter. And whatever happened to it? N.

7 years, 6 months

13
36
0 0

Spell - was tmac: Move macro diagnostics away from

by Doug McIlroy

`quotes' > rules used ... to create British spelling from an American > English database often leave a lot to be desired. Among the BUGS listed for spell(1) in v7 was "Britsh spelling was done by an American". Nevertheless, at least one British expat thanked me for spell -b. He had been using the original "spell", and ignoring its reports of British "misspellings". But, he said, long exposure to American writing had infected his writing. Spell -b was a blessing, for revealed where his usage wobbled between traditions.

7 years, 6 months

5
6
0 0

Re: [TUHS] Spell - was tmac: Move macro diagnostics away from `quotes\'

by Doug McIlroy

> I am curious if anyone on the list remembers much > about the development of the first spell checkers in Unix? Yes, intimately. They had no relationship to the PDP 10. The first one was a fantastic tour de force by Bob Morris, called "typo". Aside from the file "eign" of the very most common English words, it had no vocabulary. Instead it evaluated the likelihood that any particular word came from a source with the same letter-trigram frequencies as the document as a whole. The words were then printed in increasing order of likelihood. Typos tended to come early in the list. Typo, introduced in v3, was very popular until Steve Johnson wrote "spell", a remarkably short shell script that (efficiciently) looks up a document's words in the wordlist of Webster's Collegiate Dictionary, which we had on line. The only "real" coding he did was to write a simple affix-stripping program to make it possible to look up plurals, past tenses, etc. If memory serves, Steve's program is described in Kernighan and Pike. It appeared in v5. Steve's program was good, but the dictionary isn't an ideal source for real text, which abounds in proper names and terms of art. It also has a lot of rare words that don't pull their weight in a spell checker, and some attractive nuisances, especially obscure short words from Scots, botany, etc, which are more likely to arise in everyday text as typos than by intent. Given the basic success of Steve's program, I undertook to make a more useful spelling list, along with more vigorous affix stripping (and a stop list to avert associated traps, e.g. "presenation" = pre+senate+ion"). That has been described in Bentley's "Programming Pearls" and in http://www.cs.dartmouth.edu/~doug/spell.pdf. Morris's program and mine labored under space constraints, so have some pretty ingenious coding tricks. In fact Morris has a patent on the way he counted frequencies of the 26^3 trigrams in 26^3 byes, even though the counts could exceed 256. I did some heroic (and probabilistic) encoding to squeeze a 30,000 word dictionary into a 64K data space." Doug

7 years, 6 months

1
0
0 0

Re: [TUHS] Spell - was tmac: Move macro diagnostics away from

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > I see the man page for it in v6, but no executable. The MIT V6+ system had it. They probably took it out of the distro because it was useless without the dictionary, which they didn't have the rights to distribute. Here's the source: http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/spell.c http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/spell1.c http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/spell2.c http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/spell3.c Noel

7 years, 6 months

1
0
0 0

TROFF made trivial

by Leah Neukirchen

Hi, I found this paper by bwk referenced in the Unix manpages, in v4 as: TROFF Made Trivial (unpublished), in v5 as: TROFF Made Trivial (internal memorandom), also in the v6 "Unix Reading List", but not anymore in v7. Anyone have a copy or a scan? -- Leah Neukirchen <leah(a)vuxu.org> http://leah.zone

7 years, 6 months

5
5
0 0

Re: [TUHS] UNIX on S/370

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy > So tape I can see being more weird, but isn't raw disk just "don't put > it in buffer cache"? One machines/controllers which are capable of it, with raw devices DMA happens directly into the buffers in the process (which obviously has to be resident while the I/O is happening). Noel

7 years, 6 months

4
4
0 0

DEC Born 60 years ago

by Clem Cole

Cute article from a few days ago in the Telegram about DEC with some since pics that I thought I would pass on to this group. http://www.telegram.com/news/20171118/digital-equipment-born-60-years-ago-i…

7 years, 6 months

3
3
0 0

Re: [TUHS] Determining what was on a tape back in the day

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > I don't quite no how to investigate this other than to pore through the > pdp11/40 instruction manual. One of these: https://www.ebay.com/itm/Digital-pdp-Programming-Card-8-Pages/142565890514 is useful; it has a list of all the opcodes in numerical order; something none of the CPU manuals have, to my recollection. Usually there are a flock of these "pdp11 Programming Cards" on eBait, but I only see this one at the moment. If you do any amount of work with PDP-11 binary, you'll soon find yourself recognizing the common instructions. E.g. MOV is 01msmr (octal), where 'm' is a mode specifier, and s and r are source and destination register numbers. (That's why PDP-11 people are big on octal; the instructions are easy to read in octal.) More here: http://gunkies.org/wiki/PDP-11_architecture#Operands So 0127xx is a move of an immediate operand. >> You don't need to mount it on DECTape drive - it's just blocks. Mount >> it as an RK05 image, or a magtape, or whatever. > I thought disk (RK05) and tape (magtape) blocks were different... Well, you need to differentiate between DECtape and magtape - very different beasts. DECtape on a PDP-11 _only_ supports 256 word (i.e. 512 byte) blocks, the same as most disks. (Floppies are an exception when it comes to disks - sort of. The hardware supports 128/256 byte sectors, but the usual driver - not in V6 or V7 - invisibly makes them look like 512-byte blocks.) Magtapes are complicated, and I don't remember all the details of how Unix handles them, but the _hardware_ is prepared to write very long 'blocks', and there are also separate 'file marks' which the hardware can write, and notice. But a magtape written in 512-byte blocks, with no file marks, can be treated like a disk; that's what the V6 distribution tapes look like: http://gunkies.org/wiki/Installing_UNIX_Sixth_Edition#Installation_tape_con… and IIRC 'tp' format magtape tapes are written the same way, hardware-wise (so they look just like DECtapes). Noel

7 years, 6 months

11
15
0 0

Re: [TUHS] Some resources for V6/PDP/SIMH newbs like me

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > (e) UNIX assembler uses the characters $ and "*" where the DEC > assemblers use "#" and "@" respectively. Amusing: the "UNIX Assembler Reference Manual" says: The syntax of the address forms is identical to that in DEC assemblers, except that "*" has been substituted for "@" and "$" for "#"; the UNIX typing conventions make "@" and "#" rather inconvenient. What's amusing is that in almost 40 years, it had never dawned on me that _that_ was why they'd made the @->*, etc change! "Duhhhh" indeed! Interesting side note: the UNIX erase/kill characters are described as being the same as Multics', but since Bell pulled out of the Multics project fairly early, I wonder if they'd used it long enough to get '@' and '#' hardwired into their fingers. So I recently has the thought 'Multics was a follow-on to CTSS, maybe CTSS used the same characters, and that's how they got burned in'. So I looked in the "CTSS Programmer's Guide" (2nd edition), and no, according to it (pg. AC.2.02), the erase and kill characters on CTSS were '"' and '?'. So, so much for that theory! > (l) The names "_edata" and "_end" are loader pseudo variables which > define the size of the data segment, and the data segment plus the bss > segment respectively. That one threw me, too, when I first started looking at the kernel! I don't recall if I found documentation about it, or just worked it out: it is in the UPM, although not in ld(1) like one might expect (at least, not in the V6 UPM; although in V7: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/man/man1/ld.1 it is there), but in end(3): http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man3/end.3 Noel

7 years, 6 months

2
1
0 0

redirection wildness in v7

by Will Senn

Why does the first of these incantations not present text, but the second does (word is a file)? Neither errors out. $ <word | sed 20q $ <word sed 20q Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

7 years, 6 months

5
8
0 0

Re: [TUHS] UNIX on S/370

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole <clemc(a)ccc.com> > IIRC Tom Lyons started a 370 port at Princeton and finished it at > Amdahl. But I think that was using VM Maybe this is my lack of knowledge of VM showing, but how did having VM help you over running on the bare hardware? Noel

7 years, 6 months

10
14
0 0

First permanent ARPAnet link

by Dave Horsfall

https://en.wikipedia.org/wiki/Leonard_Kleinrock#ARPANET ``The first permanent ARPANET link was established on November 21, 1969, between the IMP at UCLA and the IMP at the Stanford Research Institute.'' And thus from little acorns... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 6 months

1
0
0 0

Re: [TUHS] Some resources for V6/PDP/SIMH newbs like me

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > he is addressing an aspect that was not addressed in either of the > manual's entries and is very helpful for making the translation between > PDP-11 Macro Assembler and unix as. I'm curious - what aspect was that? Noel

7 years, 6 months

1
0
0 0

Re: [TUHS] Some resources for V6/PDP/SIMH newbs like me

by jnc＠mercury.lcs.mit.edu

> From: Will Senn <will.senn(a)gmail.com> > To bone up on assembly language, Lions's commentary is exceptionally > helpful in explaining assembly as it is implemented in V6. The manual > itself is really thin Err, which manual are you referring to there? Not the "UNIX Assembler Reference Manual": http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/doc/as/as I would assume, but the 'as(I)' page in the UPM? Noel

7 years, 6 months

2
1
0 0

Re: [TUHS] Determining what was on a tape back in the day

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > I'm off to refreshing my pdp-11 assembly language skills... A couple of things that might help: - assemble mboot.s and 'od' the result, so when you see something that matches in the dump of the 0th block, you can look back at the assembler source, to see what the source looks like - read the boot block into a PDP-11 debugger ('db' or 'cdb' on V6, 'adb' on V7; I _think_ 'adb' was available on V7, if not, there are some BSD's that have it) and use that to disassmble the code Noel

7 years, 6 months

1
0
0 0

Re: [TUHS] Determining what was on a tape back in the day

by jnc＠mercury.lcs.mit.edu

> The 0th block does seem to contain some PDP-11 binary - a bootstrap of > some sort. I'll look in more detail in a bit. OK, I had a quick look, and it seems to be a modified version of mboot.s: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/mdec/mboot.s I had a look through the rest of the likely files in 'mdec', and I didn't find a better match. I'm too lazy busy to do a complete dis-assembly, and work out exactly how it's different, though.. A few observations: 000: 000407 000606 000000 000000 000000 000000 000000 000001 An a.out header, with the 0407 'magic' here performing its original intended function - to branch past the header. 314: 105737 177560 002375 Some console I/O stuff - this two instruction loop waits for the input ready bit to be set. 326: 042700 177600 020027 000101 103405 020027 000132 101002 More character processing - the first instruction clears the high bits of R0, and the next two sets of two instructions compare the contents with two characters (0101 and 0132), and branch. 444: 000207 005000 021027 000407 001004 016020 460: 000020 020006 103774 012746 137000 005007 This seems like the code that checks to see if the thing is an a.out file (note the 'cmp *r0, $0407'), but the code is different from that code in mboot.s; in that, the instruction before the 'clr r0' (at 0446 here) is a 'jsr', whereas in this it's an 'rts pc'. And the code after the 'cmp r0, sp' and branch is different too. I love the '05007' - not very often you see _that_ instruction! 502: 012700 177350 012701 177342 012711 000003 105711 Clearly the code at 'taper:' (TC11 version). Noel

7 years, 6 months

2
1
0 0

Re: [TUHS] Determining what was on a tape back in the day

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > I don't see this file in the tuhs source code index OK, here it is: http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/stp.h http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/stp1.c http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/stp2.c http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/stp3.c That MIT PWB1+ tape has so many treasures on it! (We've already seen all the early networking software.) I really must getting around to curating it, and making the whole works available. Noel

7 years, 6 months

1
0
0 0

Determining what was on a tape back in the day

by Will Senn

So, I came across this tape: http://bitsavers.trailing-edge.com/bits/DEC/pdp11/dectape/TU_DECtapes/unix6… I was curious what was on it, so I read the description at: http://bitsavers.trailing-edge.com/bits/DEC/pdp11/dectape/TU_DECtapes.txt UNIX1 PURDUE UNIX TAPES UNIX2 UNIX4 UNIX6 HARBA1 HARVARD BASIC TAPE 1 HARBA2 HARVARD BASIC TAPE 2 MEGTEK MEGATEK UNIX DRIVER RAMTEK RAMTEK UNIX DRIVER Cool, sounds interesting, so I downloaded the unix6.dta file and fired up simh - after some fiddling, I figured out that I could get a boot prompt (is that actually from the tape?) if I: set cpu 11/40 set en tc att tc0 unix6.dta boot tc0 = At that point, I was stuck - the usual tmrk, htrk, and the logical corollary tcrk didn't do anything except return me to the boot prompt. I was thinking this was a sixth edition install tape of some sort, but if it is, I'm not able to figure it out. I thought I would load the tape into v7 and look at its content using tm or tp, but then I realized that I didn't have a device set up for TU56 and even if I did, I didn't know how to do a dir on a tape - yeah, I know, I will go read the manual(s) in chagrin. In the meantime, my question for y'all is similar to my other recent questions, and it goes like this: When you received an unmarked tape back in the day, how did you go about figuring out what was on it? What was your process (open the box, know by looking at it that it was an x rather than a y, load it into the tape reader and read some bytes off it and know that it was a z, use unix to read the tape using tm, tp, tar, dd, cpio or what, and so on)? What advice would you give a future archivist to help them quickly classify bit copies of tapes :). Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

7 years, 6 months

8
12
0 0

The Fourth Research Edition Unix Programmer's Manual

by Diomidis Spinellis

I don't think we had the Fourth Research Edition Unix Programmer's Manual available in typeset form. I played a bit with the troff manual pages on TUHS and managed to typeset it into PDF. You can find the PDF document at https://dspinellis.github.io/unix-v4man/v4man.pdf. I modernized the old shell scripts and corrected some minor markup glitches through commits that are recorded on a GitHub repository: https://github.com/dspinellis/unix-v4man. The process was surprisingly smooth. The scripts for generating the table of contents and the permuted index are based on the original ones. The few problems I encountered in the troff source had to do with missing spaces after requests, the ^F hyphenation character causing groff to complain, a failure of groff to honor .li requests followed by a line starting with a ., and two uses of a lowercase letter for specifying a font. I wrote from scratch a script to typeset everything into one volume. I could not find a shell script for typesetting the whole manual in any of the Research Editions. I assume the process of running the typesetter was so cumbersome, error prone, and time-consuming that it was manually performed on a page-by-page basis. Correct me if I'm wrong here. Diomidis Spinellis

7 years, 6 months

2
1
0 0

Re: [TUHS] Determining what was on a tape back in the day

by Steve Simon

It can be hard to visualise what is on a tape when you have no idea what is on there. Attached is a simple tool I wrote "back then", shamlessly copying an idea by Paul Scorer at Leeds Poly (My video systems lecturer). It is called tm (tape mark). -Steve

7 years, 6 months

1
0
0 0

Re: [TUHS] Determining what was on a tape back in the day

by jnc＠mercury.lcs.mit.edu

> From: Arthur Krewat > For anyone reading old tapes, I implore you to attempt to read data past > the soft EOT ;) The guy who read my tape does in fact do that; you'll notice my program has an option for looking for data after the soft EOT. Noel

7 years, 6 months

1
0
0 0

Re: [TUHS] Determining what was on a tape back in the day

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > I think I understand- the bytes that we have on hand are not device > faithful representations, but rather are failthful representations of > what is presented to the OS. That is, back in the day, a tape would be > stored in various formats as would disks, but unix would show these > devices as streams of bytes, and those are the streams of bytes are what > have been preserved. Yes and no. To start with, one needs to differentiate three different levels; i) what's actually on the medium; ii) what the device controller presented to the CPU; and iii) what the OS (Unix in this case) presented to the users. With the exception of magtapes (which had some semantics available through Unix for larger records, and file marks, the details of which escape me - but try looking at the man page for 'dd' in V6 for a flavour of it), you're correct about what Unix presented to the users. As to what is preserved; for disks and DECtapes, I think you are broadly correct. For magtapes, it depends. E.g. SIMH apparently can consume files which _represent_ magtape contents (i, above), and which include 'in band' (i.e. part of the byte stream in the file) meta-data for things like file marks, etc. At least one of the people who reads old media for a living, when asked to read an old tape, gives you back one of these files with meta-data in it. Here: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tools/rdsmt.c is a program which reads one of those files and convert the contents to a file containing just the data bytes. (I had a tape with a 'dd' save of a file-system on it, and wanted just the file-system image, on which I deployed a tool I wrote to grok 4.2 filesystems.) Also, for disks, it should be remembered that i) and ii) were usually quite different, as what was actually on the disk included thing like preambles, headers, CRCs, etc, none of which the CPU usually could even see. (See here: http://gunkies.org/wiki/RX0x_floppy_drive#Low-level_format for an example. Each physical drive type would have its own specific low-level hardware format.) So what's preserved is just an image of what the CPU saw, which is, for disks and DECtapes, generally the same as what was presented to the user - i.e. a pile of bytes. Noel

7 years, 6 months

2
1
0 0

Re: [TUHS] Determining what was on a tape back in the day

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > So, I came across this tape: > ... > I was curious what was on it 'od' is your friend! If you look here: http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#dumpf there's a thing which is basically 'od' and 'dd' rolled in together, which allows you to dump any block you want in a variety of formats (ASCII, 16-bit words in octal [very useful for PDP-11 binary], etc). I wrote it under CygWin, for Windows, but it only uses the StdIO library, and similar programs (e.g. my usassembler) written that way work fine under Losenux. Try downloading it and compiling it - if it doesn't work, please let me know; it'd be worth fixing it so it does work on Linux. > after some fiddling, I figured out that I could get a boot prompt (is > that actually from the tape?) The 0th block does seem to contain some PDP-11 binary - a bootstrap of some sort. I'll look in more detail in a bit. > I was thinking this was a sixth edition install tape of some sort, but > if it is, I'm not able to figure it out. >From what I can see, it's probably a tp-format tape: the 1st block contains some filenames which I can see in an ASCII dump of it: speakez/sbrk.s dcheck.c df.c intel/as80.c intel/optab.8080 > v7 and look at its content using tm or tp, but then I realized that I > didn't have a device set up for TU56 You don't need to mount it on DECTape drive - it's just blocks. Mount it as an RK05 image, or a magtape, or whatever. > When you received an unmarked tape back in the day, how did you go about > figuring out what was on it? Generally there would have been some prior communication, and the person sending it would have told you what it was (e.g. '800 bpi tar', or whatever). > What advice would you give a future archivist to help them quickly > classify bit copies of tapes :). Like I said: "'od' is your friend!"!! :-) Noel

7 years, 6 months

5
6
0 0

197[78] usenix conf. at columbia, magtapes "found in the street"?

by ron minnich

Random memories, possibly wrong. In 1977/78 I was at udel and had done a fair amount of work on unix but as a lowly undergrad did not get to go to the Columbia Usenix meeting. Ed Szurkowski of udel went. Ed was the grad student who did hardware design for 11s for Autotote (another story) but also stood up a lot of the early unix 11s at udel starting in 1976, starting with an 11/70. Mike Muus used to come up and visit us at udel and Mike and Ed would try to ask questions the other could not answer. Mike always had a funny story or two. Ed later went to Bell Labs and I lost track of him. The directions for the MTA were fairly clear: it listed a stop that you under no circumstances should get off at, and if you did get off at, you should not go up to the street, lest you never return. This was no joke. Some places in NY were pretty hazardous in those days. I *think* this was the meeting where Ken showed up with a bunch of magtapes, and Ed claimed that, in Ken's word, they were "... found in the street." This part I remember well: Ed returning with two magtapes and our desire to upgrade. We at udel, like many places, had done lots of our own mods to the kernel, which we wanted to keep. So we ran a diff between trees, and I wrote a merge with TECO and ed which got it all put together. I later realized this was a very early form of 'patch', as it used patterns, not line numbers, to figure out how to paste things back together. I really got to love regex in those years. Except for one file: the tools just would not merge them. Ed later realized there was one key difference that we had not noticed, a missing comment, namely, the Western Electric copyright notice ... I'm kinda sorry that our "udel Unix" is lost to the great /dev/null, it would be interesting to see it now. ron

7 years, 6 months

2
2
0 0

Re: [TUHS] Determining what was on a tape back in the day

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > stp is from the Harvard distribution. The MIT PWB1 system I have has the source; the header says: M. Ferentz Brooklyn College of CUNY September 1976 If it can't be found on TUHS, I can upload it. No man page, though. :-( Noel

7 years, 6 months

3
2
0 0

ed(1) and Pipes.

by Norman Wilson

Ralph Corderoy: ed(1) pre-dates pipes. When pipes came along, stderr was needed, and lots of new idioms were found to make use of them. Why didn't ed gain a `filter' command to accompany `r !foo' and `w !bar'? === I sometimes wonder that too. When I use `ed,' it is usually really qed, an extended ed written by the late-1970s UNIX crowd here at U of T. (Rob Pike, Tom Duff, David Tilbrook, and Hugh Redelmeier, I think.) qed is something of a kitchen sink, full of clumsy programmability features that I never use. The things that keep me using it are: -- Multiple buffers, each possibly associated with a different file or just anonymous -- The ability to copy or move text (the traditional t and m commands) between buffers as well as within one -- The ability to send part or all of a buffer to a shell command, to read data in from a shell command, or to send data out and replace it with that from the shell command: >mail user ... <ps -ef |tr a-z A-Z I use the last quite often; it makes qed sort of a workbench for manipulating and mining text. One can do the same with the shell and temporary files, but using an editor buffer is much handier. sam has similar abilities (but without all the needless programmability). Were sam less clumsy to use in its non-graphical mode, I'd probably have abandoned qed for sam. Norman Wilson Toronto ON (for real now)

7 years, 6 months

2
1
0 0

Re: [TUHS] basic tools / Universal Unix

by jnc＠mercury.lcs.mit.edu

> From: Ralph Corderoy > Then the real definition, ending in an execution of the empty `q'. > qq/4$^Ma2^[@qq Gah. That reminds me of nothing so much as TECO (may it long Rest in Peace). Noel

7 years, 6 months

34
63
0 0

Re: [TUHS] Happy birthday, Morris Worm!

by Doug McIlroy

> let's not forget that amazing vi-trainer called rogue. Also amazing is its robust survival at angband.org.

7 years, 6 months

2
1
0 0

Re: [TUHS] TECO was: Re: basic tools / Universal Unix

by Doug McIlroy

>Speaking of which, am I the only one annoyed by Penguin/OS' silly coloured "ls" output? Syntax coloring, of which IDE's seem to be enamored, always looks to me like a ransom note. For folks who like colorized text, Writers Workbench had a tool that can be harnessed to do a bang-up job of syntax colorizing for English: "parts" did a remarkable job of inferring parts of spechc in running text. Doug

7 years, 6 months

1
0
0 0

A Human 'Make' Program (almost)

by Forrest, Jon

I started with V6 Unix at UC Santa Barbara in 1977. I remember that when V7 came out, I learned about the 'make' program and started using it with great success to help me build a large Fortran package for signal processing. For its size, there was a lot going on in Santa Barbara at that time. It was one of the first 4 Arpanet nodes, and there were a bunch of companies making networking products and doing speech research as a result. I was a student at UC Santa Barbara but I started toying with the idea of finding a real job, mostly to make more money. I found several possibilities and went to interview at one. This place had an a need for somebody to, in essence, be a human 'make' program. The computer they used, some kind of Data General, was so slow that they couldn't do a build more that once or twice a day. So, in an attempt to speed up the build, they wanted to hire somebody who would, by hand, keep track of the last modification date of all the components in the package they sold, and do a build that only performed the necessary steps to generate the package - in other words a human make program. Apparently they figured that this would save enough time to justify the $24K salary they were willing to pay. $24K in 1978 wasn't a bad salary at all. I didn't take the job, but I've often thought that what I should have done would have been to take the job under the condition that I could mostly work remotely. Then, I could have used the 'make' program on our V7 Unix system to generate the optimal script to build the package, and then taken the script back to the company to run on the Data General computer. I figure this would have taken maybe an hour a day. The rest of the time I could have spent on the beach thinking about ways to spend that $24K. Jon Forrest

7 years, 6 months

1
0
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