TUHS July 2022

tuhs@tuhs.org

63 participants
40 discussions

by Warner Losh

Greetings, What's the canonical source for patches to 2.9BSD and 2.11BSD? I see we have 2.11BSD patch 469 dated last month in the archive. Where does it come from? Has anybody climbed the hill to import all the patches into a git repo? I've found some mirrors, but moe.2bsd.org has been down for me for ages... How does Warren keep things up to date? I also have a (maybe faulty) memory of a similar series of patches to 2.9BSD because it was the last BSD to support non-split I&D space machines. yet a quick google search turns up nothing other than a set of patches dated August 1985 (also in our archive) and some changes for variants of hardware (pro, mscp). Is that it? Warner

1 month, 3 weeks

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

by Matthias Bruestle

I know something! On Fri, Jul 01, 2022 at 04:05:30PM +0300, Ori Idan wrote: > > o why CTRL/S and CTRL/Q are used for flow control in a shell command > > line session > > > Also would be happy to know. https://en.wikipedia.org/wiki/Software_flow_control But I don't know the answer to Ctrl-D. :( And also the bus error and maybe the segmentation fault if it hasn't to do with a segment register. Matthias -- When You Find Out Your Normal Daily Lifestyle Is Called Quarantine

8 months, 2 weeks

Line Numbers Before SysIII nl? BSD num?

by segaloco

I've been looking into the history of the nl command lately, which has gotten me curious as to what facilities folks have used at various points in UNIX history for line numbering. The earliest version of nl I've found is in System III, and it does not derive from Research, PWB, or CB. Neither does it come from BSD, although BSD has the num command which, according to the source commentary, aims to replicate the '#' behavior of ex. Were there any other facilities for printing back arbitrary lines from a file with line numbers? Also, would anyone happen to know if the above appearance of nl might have been from the USG line given none of the others feature it? It neither seems to be in V8-V10. nl has managed to find its way into the POSIX standard, so it definitely has some staying power wherever it came from. - Matt G.

9 months, 3 weeks

Re: LSX issues and musing

by jnc＠mercury.lcs.mit.edu

{I was going to reply to an earlier message, but my CFS left me with insufficient energy; I'll try and catch up on the points I was goibf to make here.} > From: Gavin Tersteeg > This leaves me with about 1.9kb of space left in the kernel for > additional drivers I'm curious how much memory you have in your target system; it must not be a lot, if you're targeting LSX. I ask because LSX has been somewhat 'lobotimized' (I don't mean that in a negative way; it's just recognition that LSX has had a lot of corners trimmed, to squeeze it down as much as possible), and some of those trims behind some of the issues you're having (below). At the time the LSI-11 came out, semiconductor DRAM was just getting started, so an LSI-11 with 8KB onboard and a 32KB DRAM card (or four 8KB MMV11 core memory cards :-), to produce the 40KB target for LSX systems, was then a reasonable configuration. These days, one has to really search to find anything smaller than 64KB... It might be easier to just run MINI-UNIX (which is much closer to V6, and thus a known quantity), than add a lot of things back in to LSX to produce what will effectively be MINI-UNIX; even if you have to buy a bit more QBUS memory for the machine. > the LSX "mkfs" was hardcoded to create filesystems with 6 blocks of > inodes. This maxed the number of files on a disk to 96, but even with > the maximum circumvented LSX would only tolerate a maximum of 101 files. And here you're seeing the 'lobotomizing' of LSX come into play. That '101' made me suspicious, as the base V6 'caches' 100 free inodes in the super-block; once those are used, it scans the ilist on disk to refill it. The code in alloc$ialloc in LSX is hard to understand (there are a lot of #ifdef's), and it's very different from the V6 code, but I'm pretty sure it doesn't refill the 'cache' after it uses the cached 100 free inodes. So, you can have as many free inodes on a disk as you want, but LSX will never use more than the first 100. (Note that the comment in the LSX source "up to 100 spare I nodes in the super block. When this runs out, a linear search through the I list is instituted to pick up 100 more." is inaccurate; it probably wasn't updated after the code was changed. ISTR tis is true of a lot of the comments.) Use MINI-UNIX. > A fresh filesystem that was mkfs'd on stock V6 can be mounted on LSX, > but any attempt to create files on it will fail. The V6 'mkfs' does not fill the free inode cache in the super-block. So, it's empty when you start out. The LSX ialloc() says: if(fp->s_ninode > 0) { ... } u.u_error = ENOSPC; return(NULL); which would produce what you're seeing. Also, another problem with trying to 'push' LSX into a previously un-handled operating regions (e.g. large disks, but there are likely others) is that there are probably things that are un-tested in that previously unused operating mode, and there may be un-found bugs that you trip across. Use MINI-UNIX. > Interestingly enough, existing large V6 RK05 images can be mounted, > read from, and written to. The only limitations on these pre existing > images is that if enough files are deleted, the system will randomly crash. I had a look at the source (in sys4.c, nami.c, iget.c, rdwri.c, and alloc.c), but I couldn't quickly find the cause; it isn't obvious. (When unlinking a file, the blocks in the file have to be freed - that's inode 'ip' - and the directory - inode 'pp' - has to be updated; so it's pretty complicated.) Use MINI-UNIX. > The information there about continuous files ... will be extremely > helpful if I ever try to make those work in the future. My recollection is that the LSX kernel doesn't have code to create contiguous files; the LSX page at the CHWiki says "the paper describing LSX indicates there were two separate programs, one to allocate space for such files, and one to move a file into such an area, but they do not seem to be extant". If you find them, could you let me know? Thanks. Noel

10 months

Re: LSX issues and musing

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > 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. If one is working in a simulator, and not a real hardware PDP-11, there's a 'trick' one can use to make life a lot easier - for MINI-UNIX, at least; I'll comment on LSX below. As I report in the MINI-UNIX Computer History Wiki article: "MINI-UNIX uses the same file system as V6; this allows MINI-UNIX packs to be 'mounted' on V6 systems (either real, or simulated), which is very convenient for working on them." So just spin up a V6 in the simulator, mount the LSX/MINI-UNIX pack, and away you go. The V6 toolchain can be used to compile/link kernels; to link user commands one will need to import the LSX/MINI-UNIX loader (which, since V6 is source compatible with LSX/MINI-UNIX, is trivial). LSX is potentially more complex, as it supports _two different_ file system formats: the standard V6 one, and a 'contiguous' one which is very similar to the V6 one (rdwri.c has no conditionals on CONTIG; not so alloc.c, though), but is not fully compatible. So non-contiguous LSX file systems can be mounted under V6, but not contiguous ones. Noel

10 months

RUNCOM and Multics: the origin of "rc" file

by Michelangelo De Simone

Hi, long time lurker here. Today I ended up on an article by Christian Lee Seibold about the origin of shells [1]. Coincidentally the article explained how the “rc” files came to be and why they’re called “rc”: everything started with RUNCOM and Multics. An excerpt from the article: ==== Unix Shells have had a very long history, and it all starts with a program written by Louis Pouzin for the MIT CTSS Operating System, called RUNCOM (which stood for “run commands”). It executed commands from a file, called “a runcom”. According to Kernighan and Ritchie[1], “rc” configuration files from Unix descended from this. Tom Van Vleck also gives origins of Unix’s use of “rc” to RUNCOM [2], and notes that the first time he read the term “shell” was from Multics documentation created by Doug Eastwood. According to Louis Pouzin, he coined the word “shell”. ==== Well, now I know… [1] https://portal.mozz.us/gemini/auragem.space/~krixano/ShellHistory-Unix.pdf — Michelangelo

10 months, 1 week

Mailing list archives

by Warner Losh

So where are the mailing list archives? I found one with google on minnie, but it stops a few weeks ago... Warner

10 months, 1 week

Line Numbers Before SysIII nl? BSD num?

by Douglas McIlroy

I've not seen an earlier post of mine on this topic; apologies if this is a duplicate. Roff was probably the earliest way to get a line-numbered file listing. Of course it took a bit of chicanery to apply it to a roff input file, but even that was not a big shell script. As has often been told, Joe Ossanna used to promise of line numbers (required by USPTO) to attract the Bell Labs patent department as the first Unix "customer". Doug

10 months, 1 week

Re: ed: multiple addresses (with semicolons)

by Douglas McIlroy

> More was I curious about the documentation of address chains in books. It was even discussed in Lomutu and Lomuto, "A Unix Primer", a pleasant book whose level is accurately described in the title. Doug

10 months, 1 week

Re: Unix V8 Chaosnet, any takers?

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

10 months, 2 weeks

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 July 2022