TUHS

tuhs@tuhs.org

43 participants
6501 discussions

by jnc＠mercury.lcs.mit.edu

> From: Ron Natalie > We had NCP running on the JHU kernel Which NCP implementation was that, the one from UIUC, or something else? (I'm curious about the one that someone here - I forget who - mentioned, where IIRC they thought it was a new one, not the UIUC one. I'm a little boggled that with so little use for one - there weren't many NCP sites - someone would have gone to all the work to do another one. But it's possible...) If you all used the UIUC one, what did you call it? I looked through the email about releases from NOSC (who seemed to be the focal point for maintaining it at one point): https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/new/dist.log but it doesn't give a name for it. The documentation: https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/doc/IllinoisNCP.nr doesn't either (other than 'Illinois NCP'). It does seem that they were semi-using V7; see e.g.: https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/green/c.c but the code looks very V6-ish; see e.g.: https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ken/text.c Noel

2 years, 10 months

Re: Unix V8 Chaosnet, any takers?

by jnc＠mercury.lcs.mit.edu

> From: Warner Losh >> What's "net unix" anyway? > I'm referring to the University of Illinois distribution Ah, OK. > I have seen references to it in the ARPAnet census documents running on > both V6 and V7 (though mostly they were silent about which version). Well, V7 came out in January, 1979, and NCP wasn't turned off until January, 1983, so people had a lot of time to get it running under V7. > I thought this was the normal nomenclature of the time, but I may be > mistaken. I'm not sure what it was usually called; we didn't have much contact with it at MIT (although I had the source; I'm the one that provided it to TUHS). The problem was that although MIT had two IMPs, all the ports on them were spoken for, for big time-sharing mainframes (4 PDP-10's running ITS; 1 running TWENEX; a Multics), so there were no ports available to plug in a lowly PDP-11. (We were unable to get an IP gateway (router) onto the ARPANET until MIT got some of the first C/30 IMPs.) So we had no use for the NCP Unix (which I vaguely recall was described as 'the ARPANET Unix from UIll'). Noel

2 years, 10 months

Re: Unix V8 Chaosnet, any takers?

by Paul Ruizendaal

Apologies for being off-topic > What did people with PDP-11 V7 who wanted TCP/IP do, anyway? Taking it slightly broader (PDP-11 instead of V7), there is a lot of discussion about that on Mike Meuss’ TCP-digest mailing list: https://ftp.ripe.net/rfc/museum/tcp-ip-digest/ There is a 1985 index of available implementations as well ( https://ftp.ripe.net/rfc/museum/tcp-ip-implementations.txt.1 ). It includes the following options for PDP-11 systems: 1.7.5. UNIX 2.9BSD DESCRIPTION: 2.9BSD TCP/IP is an adaptation of Berkeley's original VAX TCP/IP (running under BSD 4.1B UNIX) which in turn is an offshoot of BBN's VAX TCP/IP. 2.9BSD TCP/IP runs on PDP-11/44s and PDP-11/70s. The 2.8 version from SRI was adapted by Bill Croft (formerly at SRI), then Tektronix adapted it for 2.9. Berkeley took over modification of the software and brought it back to SRI where Dan Chernikoff and Greg Satz adapted it for a later release of 2.9. In addition to TCP/IP, UDP, ARP and the raw packet interface is available. ICMP redirects are not supported. User software implementations include Telnet and FTP, plus Berkeley-developed local net protocols, RWHO, RSH, RLOGIN, and RCP. 2.9BSD with TCP/IP support could probably be made to run on smaller PDP-11s although the address space would be very tight and might present problems. 1.7.6. Venix/11 TCP/IP DESCRIPTION: This is based on the "PDP-11/45" implementation available from the MIT Laboratory for Computer Science. It has been ported to a V7 UNIX system, in particular VenturCom's Venix/11 V2.0. As little of the processing as possible takes place in the kernel, to minimize the code space required. It fits comfortably on I&D machines, but is almost hopeless on the smaller machines. The kernel includes a proNET device driver, IP fragment reassembly, IP header processing, local-net header processing, and simple routing. The rest of the IP processing, and all of the UDP and TCP functions, are in user libraries. The psuedo-teletype driver is also in the kernel, and is used by Server TELNET. User programs handle ICMP processing; User and Server TELNET, SMTP, TFTP, Finger, and Discard. There are User programs for Nicname and Hostname. IEN-116 nameservers are used by all programs, and an IEN-116 nameserver is also provided. The TCP used is very simple, not very fast, and lies about windows. No FTP is available, nor is one currently planned. 1.7.8. BBN-V6-UNIX DESCRIPTION: This TCP/IP/ICMP implementation runs as a user process in version 6 UNIX, with modifications obtained from BBN for network access. IP reassembles fragments into datagrams, but has no separate IP user interface. TCP supports user and server Telnet, echo, discard, internet SMTP mail, and FTP. ICMP generates replies to Echo Requests, and sends Source-Quench when reassembly buffers are full. 1. Hardware - PDP-11/70 and PDP-11/45 running UNIX version 6, with BBN IPC additions. 2. Software - written in C, requiring 25K instruction space, 20K data space. Supports 10 connections (including "listeners"). 3. Unimplemented protocol features: - TCP - Discards out-of-order segments. - IP - Does not handle some options and ICMP messages. 1.7.9. v 3COM-UNET DESCRIPTION: UNET is a communication software package which enables UNIX systems to communicate using TCP/IP protocols. UNET will utilize any physical communications media, from low speed links such as twisted pair RS-232C to high speed coaxial links such as Ethernet. All layers of the UNET package are directly available to the user. The highest layer provides user programs implementing ARPA standard File Transfer Protocol (UFTP), Virtual Terminal Protocol (UVTP), and Mail Transfer Protocols (UMTP). These programs in turn utilize the virtual circuit services of the TCP. The TCP protocol is implemented on top of the IP. Finally, IP can simultaneously interface to multiple local networks. UNET implements 5 of the 7 layers of the International Standards Organization Open Systems Interconnection Reference Model, layers 2 through 6: Link, Network, Transport, Session, and Presentation. Features of TCP 6 not yet implemented are Precedence and Security, End-of-Letter, and Urgent. Feature of IP 4 not yet implemented is Options. Of these, we have 2.9BSD and (a forerunner of) BBN-V6-Unix available on the TUHS Unix Tree. The Venix/11 source and the 3COM source appear lost. These (unfortunately) are the ones that were implemented on top of V7. Also, BBN back-ported the TCP/IP code of BBN VAX-TCP to V7 for their C/70 Unix.

2 years, 10 months

Re: V8 4BSD or 32V Based? (was: Unix V8 Chaosnet, any takers?)

by Paul Ruizendaal

> Regarding select, I recall that Dennis implemented it and passed it to > Berkeley*, but maybe not. He certainly had a hand in its design; I > distinctly remember talking to him about it after one of his trips out > west. That is an interesting comment. DMR was on the steering committee for what would become 4.2BSD. I once spoke with Kirk McKusick about the origins of the sockets API and I think he told me that there was a lot of debate in the committee whether descriptor readiness API should be stateful (like Haverty’s await() https://www.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/ken/awaitr.c ) or stateless (like select). According to Sam Leffler (who I think added select() to 4.1c BSD) the select system call was somewhat modelled after the ADA select statement. I am speculating now, but I would not be surprised if dmr favoured the stateless design and contributed to its design. Paul

2 years, 10 months

Re: Unix V8 Chaosnet, any takers?

by jnc＠mercury.lcs.mit.edu

> From: Warner Losh > V7 could mean a modification of net unix What's "net unix" anyway? I know of the Net releases from CSRG, but this much precedes that. What did people with PDP-11 V7 who wanted TCP/IP do, anyway? Noel

2 years, 10 months

Unix V8 Chaosnet, any takers?

by Lars Brinkhoff

Hello, Unix V8 has some code for Chaosnet support. There is a small hobbyist Chaos network going with Lispm, PDP-10, PDP-11, and Berkeley Unix nodes. Is there anyone who would be interested in trying to see if the V8 code is in a workable state, and get it running? Best regards, Lars Brinkhoff

2 years, 10 months

V8 4BSD or 32V Based? (was: Unix V8 Chaosnet, any takers?)

by segaloco

Re-subject'd as this part of the conversation diverges. Found the quote that I was thinking of when I said that: https://yarchive.net/comp/bsd.html "Research Unix 8th Edition started from (I think) BSD 4.1c, but with enormous amounts scooped out and replaced by our own stuff." - Dennis Ritchie The "I think" adds some murkiness for sure. There's definitely a good chunk of code from 4BSD. Compare init, getty, locore.c (as opposed to .s in V7 back). Heck, even the main.c between the two kernels are more similar to each other than V7. I would almost opt towards calling that being rebased on 4BSD rather than V7 with bits and pieces of BSD added. I could see it being more beneficial to start with 4BSD and tack on necessary Bell bits rather than take V7/32V and try and shoehorn in the VM implementation for VAX. The 4.1cBSD copy on the archive does appear to be pretty different, so in terms of raw comparison, I suspect the basis is 4BSD rather than 4.1cBSD. I don't know that we have a clean copy of 4.1BSD gold, I'd be interested to see if the structure of the source code changed between 4.1 and 4.1c, as 4.1c does exhibit the new organization by the BSD folks, 4BSD still shows folders like cmd, lib, and so on. Not trying to be combative by any means, but I've been doing a bit of research lately into when V8 was snapped from BSD and where Bell and Berkeley then diverged from that last major confluence, especially with a focus on init and other early stages of userland. - Matt G. ------- Original Message ------- On Friday, July 15th, 2022 at 1:51 AM, Paul Ruizendaal via TUHS <tuhs(a)tuhs.org> wrote: > > Message: 6 > > Date: Thu, 14 Jul 2022 17:51:39 +0000 > > From: segaloco segaloco(a)protonmail.com > > > > Given V8 being rebased on 4(.1?)BSD, I suspect the path of least resistance would be to just start grafting V8 code onto the working 4.1BSD. > > > I doubt that V8 is "rebased on 4(.1?)BSD": in my understanding it ported some code from 4xBSD, but it is a different code base. > > As I currently understand it, the V8 kernel: > > - is a further development from 32V > - retains the code organisation of the V5..32V versions > - adds virtual memory code from BSD > - adds select() from BSD > > and then adds all the V8 innovation on top of that (streams, file system switch, virtual proc file system, networking, remote file system, support for the Blit terminal, etc.) > > In particular in the area of networking the V8 kernel is organised quite differently from the 4xBSD kernel, including the Chaosnet driver (i.e. it is streams based). > > Paul

2 years, 10 months

Re: Unix V8 Chaosnet, any takers?

by jnc＠mercury.lcs.mit.edu

> From: Lars Brinkhoff > There is a small hobbyist Chaos network going What encapsulation are they using to transmit CHAOS packets (over the Internet, I assume)? I know there was an IP protocol number assigned for CHAOS (16.), but I don't recall if there was ever a spec? (Which is kind of amusing, since in 'Assigned Numbers', the person responsible for 16. is .... me! :-) There was a spec for encapsulating IP in CHAOS, and that actually _was_ implemented at MIT BITD; it was used for a while to get IP traffic to a Unix machine (V7, IIRC) over on main campus, at a stage when only CHAOS hardware (very confusing that the same name was applied to hardware, and a protocol suite) ran across to main campus from Tech Square. > From: Grant Taylor > I wonder if there is an opportunity for something that pretends to be > the remote side locally, sends the data via some other > non-latency-sensitive protocol to a counter part where the counter part > pretends to be the near side. Let's think through the details. The near-end 'invisibility box' (let's call it) is going to have to send acks to the original source machine, otherwise that will time out, abort the connection, etc. The originating machine is its own thing, and this behaviour can't be controlled/stopped. (This, BTW, shows a key difference between 'local' and 'across network' modes, a recent topic here; in a situation where two distinct machines are cooperating across a network, the other machine is its own entity, and can't be expected/guaranteed to do anything in particular at all.) In addition, the near-end invisibility box is going to have to keep a copy of each packet, until the destination machine sends an ack to the invisibility box - because if the packet is lost, the invisibility box is going to have to retransmit it. (The original source is not going to - it's already gotten an ack, so as far as it's concerned, that packet is done and dusted.) And the near-end invisibility box is also going to have to have to have a time-out timer, so that when the ack isn't seen, it will know to retransmit the packet. There's no point to _also_ sending the acks on to the originating machine; they won't do anything useful, and might just confuse it. So, let's see now: the near-end invisibility box buffers the packet, looks for an ack, times out when it doesn't see it, re-transmits the packet - that sounds familiar? Oh, right, it's a reliable connection. And presumably there's an invisibility box at the far end too, so the same can happen for any data packets the destination machine sends. The only question is whether, when doing the detailed design, there's any point to having the destination machine's acks sent to the near-end invisibility box - or just use them at the far-end invisibility box. (I.e. create three reliable connections: i) a CHAOS connection originating machine<->near-end invisibility box; ii) {whatever} near-end invisibility ox<->far-end invisibility box; iii) CHAOS far-end invisibility box<->original destination machine - and glue them together.) That is in some sense simpler than creating an extra-ordinary mechanism to have a 'helper' box in the middle of the connection (to terminate the CHAOS connection from the original machine, and have another CHAOS connection, but with an enhanced time-out mechanism which can cope with larger RTT's, from there to the original destination); and the same in the other direction. The amusing thing is that the CHAOS protocol stack actually already had something very similar to this, BITD. If one were sitting at a machine that only had CHAOS, and one wanted to (say) TELNET to an ARPANET host, there was a CHAOS service which ARPANET hosts on the CHAOSNET provided: open a CHAOS connection to that serrver, and it would open an NCP connection to one's intended ultimate destination, and glue the byte streams together. (The ultimate destination was passed as data over the CHAOS connection, when opening it.) Noel

2 years, 10 months

Re: Unix V8 Chaosnet, any takers?

by Paul Ruizendaal

> Message: 6 > Date: Thu, 14 Jul 2022 17:51:39 +0000 > From: segaloco <segaloco(a)protonmail.com> > > Given V8 being rebased on 4(.1?)BSD, I suspect the path of least resistance would be to just start grafting V8 code onto the working 4.1BSD. I doubt that V8 is "rebased on 4(.1?)BSD": in my understanding it ported some code from 4xBSD, but it is a different code base. As I currently understand it, the V8 kernel: - is a further development from 32V - retains the code organisation of the V5..32V versions - adds virtual memory code from BSD - adds select() from BSD and then adds all the V8 innovation on top of that (streams, file system switch, virtual proc file system, networking, remote file system, support for the Blit terminal, etc.) In particular in the area of networking the V8 kernel is organised quite differently from the 4xBSD kernel, including the Chaosnet driver (i.e. it is streams based). Paul

2 years, 10 months

Re: LSX issues and musing

by Paul Ruizendaal

> If I can get this working, I have a long laundry list of modifications and > experiments that I want to run with LSX, but as it stands, this is where I > am stuck at. Once upon a time there was a Soviet home computer that was based on the PDP-11, the BK0010: https://en.wikipedia.org/wiki/Electronika_BK (it is actually mostly a copy of the Terak 8510a -- https://en.wikipedia.org/wiki/Terak_8510/a ) The guy that found the surviving floppy with LSX source code (Leonid Broukhis) for the PDP-11 immediately ported it to the BK0010 and created a fair amount of infrastructure around it: https://github.com/ignusius/bkunix He used the 2.11BSD toolchain to create a cross-compiler. As that compiler had progressed significantly from the 5th Edition era compiler, the kernel became smaller and he could squeeze some stripped functionality back in. The repo says that the code there still works on a normal PDP-11. I’ve never communicated with Leonid, but maybe Warren has contact details for him. Also, the person who created LSX unix (Heinz Lycklama) is reading this list -- but of course it has been 40+ years since he last touched the code. Note that LSX only holds one process in core and swaps other processes (NPROC = 3) out to floppy. It reportedly took several hours for the Terak to self-compile LSX from source. At one point I added debugger support to my own port of LSX to a TI-990 with just floppies ... let’s just say, now I understand deeply why the original Unix debug interface was an improvement opportunity :^)

2 years, 10 months

Re: LSX issues and musing

by jnc＠mercury.lcs.mit.edu

> From: Gavin Tersteeg > I spent a lot of time getting UNIX V6 working on my PDP-11/23 system. > It took a lot of tinkering with the kernel and drivers to make it work > in the way I wanted to You must have made a lot of changes for it to take "a lot of tinkering". Bringing V6 up on the /23 has been done several times, and when I did it, it only took about 2 dozen lines of code in about 2 files. What all did you wind up changing? > From my research, it seems like there were two different UNIX variants > that could run on a system like this. These variants were LSX and > MINI-UNIX. MINI-UNIX seems to require a decent mass-storage device like > a RK05 and some porting to work on an 11/03, while LSX is designed to > work on exactly the hardware specs that I have on hand. Bringing up MINI-UNIX on the /03 has been done at least twice; once historically (now lost, AFAIK), and again recently: http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/Mini.html I'm not sure what you're basing the "MINI-UNIX seems to require a decent mass-storage device like a RK05" on - it should run as well on whatever you're running LSX on as LSX does. I haven't run LSX myself, but from what I've seen, the only significant difference between the two is that LSX will run with less main memory than MINI-UNIX (which really kind of needs 56KB; LSX you can probably get away with 40KB).That was a significant issue when the LSI-11 was originally released, but these days one has to really work to have a QBUS PDP-11 with less than 56KB. > my EIS-less 11/03 EIS chips can be found on eBait for not much money (I just bought a couple myself), and it's worth investing in one, so on can dispense with the emulator, which takes real memory for which a better use can be found. > The first issue is that the C compiler will randomly spit out a "0: > Missing temp file" when attempting to compile something. This is > annoying, but circumventable by just running the same command over and > over until it works. Schaeffer's Law (from Larry Niven): anything you don't understand might be dangerous. I'd track down why this is happening. Noel

2 years, 10 months

Re: LSX issues and musing

by jnc＠mercury.lcs.mit.edu

It would be really appreciated if people replying to messages like this would take 10 minutes (or so - that's about how lonfg it took me to find the actual answer to this person's question) to do some research, instead of just replying off the top of their heads with whatever they happen to think they know. > From: Gavin Tersteeg > I can't seem to get the kernel to actually link together once > everything is compiled. When the final "ld -X" is executed, I always > get the following errors: > "Undefined: > _end > _edata > _decmch" The first two are automagically defined by the linker after a successful read-through of the files+libraries, i.e. when then are no un-defined symbols. Ignore them; they will go away when you fix the problem. The real issue is the missing 'decmch'. That apparently comes from decfd.c, which I assume is the DEC floppy disk driver. Depending on the setting of the EIS conditional compilation flag (a different one for C files, from the PDP-11 assembler files, please note - and I haven't worked out what its definitiion means; whether if defined, it means the machine _does_ have the EIS, or _does not_x), it will be called for. 'decmch' is in low.s (rather oddly; that usualy holds just interrupt vectors and interrupt toeholds), conditionally assembled on: .if DEC .if EIS-1 The first line presumably adds it if there _is_ a DEC floppy disk, the second I don't know _for sure_ the sense of (although I'm guessing that EIS=1 means there _is_ an EIS chip, so this line says 'assemble if there it _not_ an EIS chip'). Although you'd think that whatever calculation it is doing, it would need to do if there's an EIS chip or not, so with an EIS chip it must calculate it some other way; you'll have to read decfd.c and see how it works. Note that you'll have to make sure the EIS flags (note plural) are set to the same sense, when compiling the C and assembler files... Let me send this off, and I'll reply to some other points in a separate message. Noel

2 years, 10 months

LSX issues and musing

by Gavin Tersteeg

Hello, and greetings! I guess as this is my first post here, I should give some background on what I have been working on. Last summer I spent a lot of time getting UNIX V6 working on my PDP-11/23 system. It took a lot of tinkering with the kernel and drivers to make it work in the way I wanted to, but in the end I was left with a system that ran well enough to do some demonstrations at VCFMW. This year I want to do more stuff with 1970s era UNIX, but now with even more technical restrictions. I have had a Heathkit H-11 (consumer grade PDP-11/03) for a while now, and I have been looking for something interesting to do with it. From my research, it seems like there were two different UNIX variants that could run on a system like this. These variants were LSX and MINI-UNIX. MINI-UNIX seems to require a decent mass-storage device like a RK05 and some porting to work on an 11/03, while LSX is designed to work on exactly the hardware specs that I have on hand. So on to the actual issues I am having at the moment: I have put together a SIMH instance to get the ball rolling in building a kernel that will boot on my EIS-less 11/03, but I am having significant difficulty actually getting the kernel to build. The first issue is that the C compiler will randomly spit out a "0: Missing temp file" when attempting to compile something. This is annoying, but circumventable by just running the same command over and over until it works. The second issue, however, is much more of a road block for me. I can't seem to get the kernel to actually link together once everything is compiled. When the final "ld -X" is executed, I always get the following errors: " Undefined: _end _edata _decmch " (This is from the build script found in the "shlsx" file) https://minnie.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/shlsx I am assuming that this is some sort of issue with the object file orderings, but I simply do not know enough about V6 ld to properly debug this issue. I am hoping that somebody here has already run into this issue, and knows what I am doing wrong. If I can get this working, I have a long laundry list of modifications and experiments that I want to run with LSX, but as it stands, this is where I am stuck at. Thank you, Gavin

2 years, 10 months

Re: ed: multiple addresses (with semicolons)

by Douglas McIlroy

> I wasn't able to find the ``Multics Condensed Guide'' on multicians.org multicians.org points to http://www.bitsavers.org/pdf/honeywell/multics/swenson/6906.multics-condens… It also has https://www.multicians.org/mspm/bx-9-06.681115.qed-editor.pdf Amusingly, the "condensed guide" is many pages longer than the MSPM (Multics system programmer's manual--the gospel) Neither tells about extra address fields or semicolons > In ex(1) the " comment command reappeared. And in sed the y command reappeared. Doug

2 years, 10 months

ed: multiple addresses (with semicolons)

by Douglas McIlroy

The interpretation of a string of addresses separated by commas and/or semicolons was already defined in the v1 man page for ed. Ed was essentially a stripped-down version of Multics qed. The latter was originally written by Ken. Unfortunately the "Multics Condensed Guide" online at multicians.org describes how strings of addresses were interpreted only by canonical examples for the various editing requests. I have no specific memory of semicolons in qed. I have a vague recollection that semicolons originated in ed, however you should put no trust in this. Maybe Ken remembers. Doug

2 years, 10 months

Documents for UNIX Collections

by Warren Toomey

All, Matt e-mailed this to me and the TUHS list, but it doesn't seem to have made it through so I'm punting on a copy ... Warren ----- Forwarded message from Matt Gilmore ----- Subject: Documents for UNIX Collections Good afternoon everyone, my name is Matt Gilmore, and I recently worked with some folks here to help facilitate the scanning and release of the "Documents for UNIX" package as well as a few odds and ends pertinent to UNIX/TS 4.0. I've been researching pretty heavily the history of published memoranda and how they ultimately became the formal documents that Western Electric first published with UNIX/TS 5.0 and System V. Think the User's Guide, Graphics Guide, etc. In my research, I've found that document sets in a similar spirit have been published since at least Research Version 6. I've been able to track down a few that are on the TUHS source archive in original *ROFF format (Links given as path in the tree to avoid hyperlink mangling): Research V6: V6/usr/doc Mini-UNIX: Mini-Unix/usr/doc PWB/UNIX 1.0: PWB1/usr/man/man0/documents (note, I'm not sure where the actual docs are, this is just a TOC, Operators Manual is in op in the base man folder) Wollongong 7/32 Version: Interdata732/usr/doc (only 7/32 relevant docs, allegedly) Research V7: V7/usr/doc UNIX/32V: 32V/usr/doc There are probably others, but these are the ones I'm aware of on the archive for Bell-aligned revisions prior to the commercialization of UNIX/TS as System III. On the note of System III, I seem to have an archive that is slightly different than what is on TUHS, namely in that it has this same documents collection. I can't find it in the System III section on the site, so I'm assuming it isn't hosted anywhere presently. One of the projects I'm working on (slowly) is comparing these documents with the 4.0 docs I scanned for Arnold and making edits to the *ROFF sources with the hopes I could then use them to produce 1:1 clean copies of the 4.0 docs, while providing an easy means for diff'ing the documents as well (to flush out changes between 3.0 and 4.0). Happy to provide this dump to Warren for comparison with what is currently hosted. Usenix also published documentation sets for 4.2 and 4.3BSD in the 80's which served the same purpose for BSD users. There seems to be a 4.4BSD set as well, although I haven't looked at these yet, I've got a random smattering between 4.2 and 4.3 of the comb-bound Usenix manuals, but I assume the 4.4 set is in a similar vein, with reference guides and supplementary documents. Looks like a lot of the same, but with added documents regarding developments at Berkeley. Now for my reasons for mailing, there are a couple: 1. Is anyone aware of whether similar document sets were compiled for MERT, UNIX/RT, USG Program Generic, or CB-UNIX? Or would users of those systems have simply been referred to the collection most closely matching the version they're forked from? 2. Was there ever any such document set published in this nature as "Documents for UNIX" consistent of memoranda for 5.0/System V? Or did USG immediately begin by providing just the published trade manuals? The implication here is if USG published no such documents, then the Documents for UNIX 4.0 represents the last time USG compiled the memoranda as they were written (of course with version-related edits) with original authorship and references as a documentation set. 3. Have there been any known efforts to analyze the history and authorship of these documents, explicitly denote errata and revisions, and map out the evolution of the system from a documentation perspective like this? Thanks for any insight anyone can provide! - Matt G. P.S. I'd be interested in doing more preservation work, if anyone else has documents that need preserving, I'll happily coordinate shipment and scanning. P.P.S. Ccing Warren, I don't know if I'm able to send emails to this list or not, so pardon the extraneous email if not necessary. ----- End forwarded message -----

2 years, 10 months

ed: multiple addresses (with semicolons)

by markus schnalke

Hoi, via a recent message from Chris Pinnock to the list I became aware of the book ``Ed Mastery'' by Michael W. Lucas. At once I bought and read it. Although it is not on the mastery level it claims and I would have liked it to be, it still was fun to read. This brought me back to my ed interest. I like ed a lot and despite my young age, I've actually programmed with ed for fun and have prepared the troff slides for a talk on early Unix tools (like ed) with ed alone. I use the Heirloom version of ed. Anyways, I wondered about the possibility to give multiple addresses ... more than two for relative address searches. For example, to print the context of the first occurance of `argv' within the main function, you can use: /^main(/;/\<argv\>/-2;+4n For the last occurance it's even one level more: /^main(/;/^}/;?\<argv\>?-2;+4n (The semicolons mean that the next search or relative addressing starts at the result of the previous one. I.e. in this case: We go to the `main' function, from there go to the function end, then backwards to `argv' minus two lines and print (with line numbers) this line and four lines more.) The manpage of 6th Edition mentiones this possibility to give more than two addresses: Commands may require zero, one, or two addresses. Commands which require no addresses regard the presence of an address as an error. Commands which accept one or two addresses assume default addresses when insufficient are given. If more addresses are given than such a command requires, the last one or two (depending on what is accepted) are used. http://man.cat-v.org/unix-6th/1/ed You can see it in the sources as well: https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s1/ed.c (Search for ';' to find the line. There's a loop processing the addresses.) V5 ed(1) is in assembler, however, which I cannot read. Thus there must have been a complete rewrite, maybe introducing this feature at that point. (I don't know where to find v5 manpage to check that as well.) I wonder how using multiple addresses for setting starting points for relative searches came to be. When was it implemented and what use cases drove this features back in the days? Or was it more an accident that was introduced by the implementation, which turned out to be useful? Or maybe it existed already in earlier versions of ed, althoug maybe undocumented. For reference, POSIX writes: Commands accept zero, one, or two addresses. If more than the required number of addresses are provided to a command that requires zero addresses, it shall be an error. Otherwise, if more than the required number of addresses are provided to a command, the addresses specified first shall be evaluated and then discarded until the maximum number of valid addresses remain, for the specified command. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ed.html Here more explanation rom the rationale section: Any number of addresses can be provided to commands taking addresses; for example, "1,2,3,4,5p" prints lines 4 and 5, because two is the greatest valid number of addresses accepted by the print command. This, in combination with the <semicolon> delimiter, permits users to create commands based on ordered patterns in the file. For example, the command "3;/foo/;+2p" will display the first line after line 3 that contains the pattern foo, plus the next two lines. Note that the address "3;" must still be evaluated before being discarded, because the search origin for the "/foo/" command depends on this. As far as I can see, multiple addresses make only sense with the semicolon separator, because the comma separator does not change the state, thus previous addresses can have no effect on later addresses. The implementation just does not forbid them, for simplicity reasons. meillo

2 years, 10 months

Stuart Feldman's EFL

by arnold＠skeeve.com

Hi. EFL was definitely a part of BSD Unix. But I don't see it in the V7 stuff in the TUHS archives. When did it first appear? Was it part of 32V and I should look there? It is definitely in the V8 and V10 stuff. Did anyone actually use it? I have the feeling that ratfor had already caught on and spread far, and that it met people's needs, and so EFL didn't really catch on that much, even though it provided more features on top of Fortran. Thanks, Arnold

2 years, 10 months

Re: EFL

by Steve Simon

I remember reading the EFL docs in the paper manuals for a sysv.3.2 honeywell 68k tower machine i worked on circa 1987. i never tried it though.

2 years, 10 months

Re.: is networking different?

by Paul Ruizendaal

> On Sun, Jul 3, 2022 at 1:33 PM Marc Donner wrote: > > I've been ruminating on the question of whether networks are different from > disks (and other devices). Here are a couple of observations: [...] From my perspective most of these things are not unique to networks, they happen with disks and/or terminals. Only out-of-order delivery seems new. However, in many early networking contexts (Spider/Arpanet/Datakit/UUCP) this aspect was not visible to the host (and the same holds for a single segment ethernet). To me, in some ways networks are like tty’s (e.g. completing i/o can take arbitrarily long, doing a seek() does not make sense), in other ways they are like disks (raw devices are organised into byte streams, they have a name space). Uniquely, they have two end-points, only one of which is local (but pipes come close). Conceptually, a file system does two things: (i) it organises raw blocks into multiple files; these are the i-nodes and (ii) it provides a name space; these are directories and the namei routine. A network stack certainly does the first: a raw network device is organised into multiple pipe-like connections; depending on the network, it optionally offers a naming service. With the first aspect one could refer to any file by “major device number, minor device number, i-node number”. This is not very different from referring to a network stream by “network number, host number, port number” in tcp/ip (and in fact this is what bind() and connect() in the sockets API do), or “switch / host / channel” in Datakit. For disks, Unix offers a clean way to organise the name spaces of multiple devices into a unified whole. How to do this with networks is not so easy, prior to the invention of the file system switch. Early on (Arpanet Unix), it was tried to incorporate host names into a net directory by name (RFC 681) but this is not scalable. Another way would be to have a virtual directory and include only names for active connections. The simple way would be to use a text version of the numeric name as described above - but that is not much of an improvement. Better to have a network variant of namei that looks up symbolic names in a hosts file or in a network naming service. The latter does not look very performant on the hardware of 40 years ago, but it appears to have worked well on the Alto / PuPs network at Xerox PARC. With the above one could do open(“/net/inet/org.tuhs.www:80”, O_RDWR | O_STREAM) to connect to the TUHS web server, and do open(“/net/inet/any:80”, O_RDWR | O_STREAM | O_CREAT, 0600) to create a ‘listening’ (rendez-vous) socket. Paul

2 years, 10 months

Re: Thoughts on Licenses

by Larry McVoy

On Sun, Jul 03, 2022 at 05:55:15PM +1000, steve jenkin wrote: > > > On 3 Jul 2022, at 12:27, Larry McVoy <lm(a)mcvoy.com> wrote: > > > > I love the early Unix releases because they were so simple, processors > > were simple then as well. > > > Bell???s Observation on Computer Classes has brought surprises > - we???ve had some very popular new devices appear at the bottom end of the market and sell in the billions. Yes, and they all run Linux or some tiny OS. Has anyone ported v7 to any of these devices and seen it take off? Of course not, it doesn't have TCP/IP.

2 years, 10 months

is networking different?

by Marc Donner

On June 28 Rob Pike wrote: "One of the reasons I'm not a networking expert may be relevant here. With networks, I never found an abstraction to hang my hat on. Unlike with file systems and files, or even Unix character devices, which provide a level of remove from the underlying blocks and sectors and so on, the Unix networking interface always seemed too low-level and fiddly, analogous to making users write files by managing the blocks and sectors themselves." I've been ruminating on the question of whether networks are different from disks (and other devices). Here are a couple of observations: 1 - Two different packets may take two different paths from the sender to the receiver. 1a - The transit time for one packet may vary widely from that of the other. 1b - The two packets may arrive in an order different from the order in which they were transmitted. (Note - recently I have been reading Bob Gezelter's monograph [and PhD dissertation] and I've learned that modern high-performance disk systems behave more like networks in 1a and 1b.) 2 - A packet may never arrive. 3 - Behavior 2 not a sign of hard failure for networks, whereas it is generally considered so for other I/O devices. There is probably more to why networks are weird, but these are some of the big dissonances that seem to me to make Rob's comment resonate so loudly to me. Best, Marc ===== nygeek.net mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>

2 years, 10 months

Thoughts on Licenses

by Clem Cole

As part of some of simh work, I've been immersed in some licensing discussions. Thanks for the V8-10, Plan-9 and Inferno notes - they are relevant. Anyway, WRT to TUHS, I'm thinking that at least in the case of the Unix style bits, I propose a small change to Waren's top-level directory. Add a new dir called something like 'Legal Docs' or 'Copyrights+Licenses'. Then move the Caldera document and Warren's current note into that area. Then add copies of anything we can collect like the Dan Cross's V8-10, anything WRT to Plan9/Inferno or anything we from the UNIX world - such as something Sun, DEC or HP or like might have added. Maybe add a subdirectory with the AT&T/USL case details. And maybe add a sub-directory with known FOSS licenses used by the UNIX community and add a copy of the 3-clause BSD and maybe even the two GPLs. Then update the README in the current top-level dir. Adding to the contents something like "*the IP contained on this website is covered by different licenses depending on the specific IP. Copies of these can be found with the source code itself, but have also been all collected together in the top-level directory: ...*." I think these all have both historical values, as well as practical values. As I said, I was not sure myself and I think other would be less ignorant if they could find it all easily. In the case of the practical, a for instance, in an email with some lawyers last week, I had pointed them at the Caldera document. I'ld have loved to have been able to say look in this directory. The Caldera and later Nokia Licenses are what we are considering as examples. Thoughts?

2 years, 10 months

Research Datakit notes

by Geoff Pool

I've enjoyed reading this thread as networking has always been a passion of mine. Lawrence Livermore had, at one time, their own networking system they called Spider. Is this the same Spider technology that Sandy Fraiser references in his Datakit notes? Geoff

2 years, 10 months

Re: "9 skills our grandkids won't have" - Is this a TUHS topic?

by Nelson H. F. Beebe

>> I don't know the answer to Ctrl-D. The Unix command "man ascii" has the answer: Oct Dec Hex Char Oct Dec Hex Char ------------------------------------------------------------------------ 000 0 00 NUL '\0' 100 64 40 @ 001 1 01 SOH (start of heading) 101 65 41 A 002 2 02 STX (start of text) 102 66 42 B 003 3 03 ETX (end of text) 103 67 43 C 004 4 04 EOT (end of transmission) 104 68 44 D .... Ctrl-D signifies end of transmission. Some other O/Ses have used Ctrl-Z for that purpose, presumably because Z is the final letter of numerous alphabets. There is a good book about the history of character sets (pre-Unicode) in the book described at this URL: http://www.math.utah.edu/pub/tex/bib/master.html#Mackenzie:1980:CCS Bob Bemer (1920--2004), known as Dr. ASCII to some of us, was a key person in the standardization of character sets: https://en.wikipedia.org/wiki/Bob_Bemer https://en.wikipedia.org/wiki/ASCII ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - 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/ - -------------------------------------------------------------------------------

2 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS