TUHS November 2020

tuhs@tuhs.org

62 participants
36 discussions

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by Paul Ruizendaal

> V6, as distributed, had no networking at all. There are two V6 systems with > networking in TUHS: > > https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC <https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC> > https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6 <https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6> > > The first is an 'NCP' Unix (unless unless you have an ARPANet); the second is > a fairly early TCP/IP from BBN (ditto, out of the box; although one could write > an Ethernet driver for it). I’ve also done a port of the BBN VAX stack to V6 (running on a TI990 clone), using a serial PPP interface to connect. Experimental, but may have the OP's interest: https://www.jslite.net/cgi-bin/9995/dir?ci=tip > There's also a fairly nice Internet-capable V6 (well, PWB1, actually) from MIT > which I keep meaning to upload; it includes SMTP, FTP, etc, etc. I also have > visions of porting an ARP I wrote to it, and bringing up an Ethernet driver > for the DEQNA/DELQA, but I've yet to get to any of that. I’d love to have a look at that and compare and contrast the approaches. I’m finding that BBN’s original design, with a separate kernel thread for the network stack, is elegant but difficult to tune: too much priority and it crowds out user processes, too little and the slow PPP line is not kept busy. I think I’m beginning to understand why CSRG (and later also BBN) moved to the interrupt driven structure of 4.2BSD: perhaps it was also difficult to tune for a VAX with ethernet.

3 years, 10 months

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by jnc＠mercury.lcs.mit.edu

> From: Paul Riley > In the bootable images archive, there's the "Unknown V6" RL02 > image. I've tried that on SimH configured as an 11/23+ with 256kB of RAM > and it seems to work fine. Sorry, where's this archive? Somewhere in: https://www.tuhs.org/Archive/Distributions/Research/ I assume? From the description, that might be from the 'Shoppa disks'; didn't realize that was a /23 on those. > I would assume that Ethernet boards are available, but not supported on > V6. V6, as distributed, had no networking at all. There are two V6 systems with networking in TUHS: https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6 The first is an 'NCP' Unix (unless unless you have an ARPANet); the second is a fairly early TCP/IP from BBN (ditto, out of the box; although one could write an Ethernet driver for it). There's also a fairly nice Internet-capable V6 (well, PWB1, actually) from MIT which I keep meaning to upload; it includes SMTP, FTP, etc, etc. I also have visions of porting an ARP I wrote to it, and bringing up an Ethernet driver for the DEQNA/DELQA, but I've yet to get to any of that. > it's hard to glean that wisdom from reading the manual. Yeah, DEC manuals went through a phase-change around about the time of the /23. Old DEC manuals are wonderful; stuffed to the gills with deep technical details. Suitable for engineers... Later, they turned into manuals for 'ordinary people' - 'plug cable C1 into plug P1'. Semi-useless; although one can often glean a few useful morsels if you trawl through the entire thing. That's why I've been doing PDP-11 pages on the CHWiki which attempt to cover a lot of technical detail, in a high technical content/size way. If you need something that's not there, let me know, and I'll get to adding it. Noel

3 years, 10 months

reboot(2) system call

by Warner Losh

I've done some research for a friend about when the reboot() system call was added, and how it related to the sync, sync, sync dance. https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html may be of interest. Please do let me know if I've gotten something wrong... Warner

3 years, 10 months

Re: [TUHS] Memory management in Dennis Ritchie's C Compiler

by jnc＠mercury.lcs.mit.edu

> From: Jim Geist > When did mmap(2) come about? Pretty sure it's a Berserkleyism. I think it came in with the VM stuff that DARPA mandated for VAX Unix (for the research project they funded). Noel

3 years, 10 months

/bin vs /sbin

by Grant Taylor

One of the things that I've noticed in my explorations into the H.J. Lu bootable root disks is that some of them predate the /sbin split in Linux. One of them has exactly one file in /sbin and other commands spread across /bin, /usr/bin, and /etc. The single file in /sbin is sln. To me, this makes it fairly self evident that /sbin was originally for statically linked binaries. At least in Linux. Does anyone have any history of /sbin from other traditional Unixes? I'd be quite interested in learning more. I also noticed that (at least) one of the early versions of the H.J. Lu disks had root's home directory in /usr/root. I seem to recall that one version used an atypical of /users vs /usr. Which as I understand it, goes back to the original / vs /usr split in Unix, before /home became a thing. -- Grant. . . . unix || die

3 years, 10 months

Troff to ps

by Will Senn

All, So... I've moved on from v7 to 2.11bsd - shucks, vi and tar and co. just work there and everything else seems to be similar enough for what I'm interested in anyway. So yay, I won't be pestering y'all about vi anymore :). One the other hand, now I'm interested in printing the docs. 2.11bsd comes with docs in, of all places, /usr/doc. In there are makefiles for making the docs - ok, make nroff will make ascii docs, and troff will make troff? docs using Ossana's 'original' troff. So, after adding -t to it so it didn't complain about 'typesetter busy', I got no errors. I mounted a tape, tar'ed my .out file and untar'ed it on my macbook (did it for the nroff and troff output). Then I hit the first snag, groff -Tps -ms troff.out > whatever.ps resulted in cannot adjust line and cannot break line errors and groff -Tps -ms nroff.out > whatever.ps resulted in a bunch of double vision. I seem to recall doing this in v6 and it working ok (at least for nroff). My questions: 1. Is there a troff to postcript conversion utility present in a stock 2.11 system (or even patch level 4xx system)? 2. Is there a way to build postscript directly on the system? 3. Is there an alternative modern way to get to ps or pdf output from the nroff/troff that 2.11 has? I'm still digging into the nroff stuff as that may be just minor diffs between ancient nroff macros and "modern" macros or even just errors (.sp -2 rather than .sp or .sp -1, .in -2 instead of .in +2), etc. Although, the files display ok in 2.11bsd using nroff -ms nroff.out... Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

3 years, 10 months

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by jnc＠mercury.lcs.mit.edu

> From: Paul Riley > Is LSX the only option on the 11/03, or could I run V6 or Mini-Unix with > more RAM? All PDP-11 Unix versions from V4 on require the MMU, so the -11/03 is out for them. We don't have the code for V2-V4, though. So V1 (mostly all assembler, no C :-), LSW and Mini-Unix are the only options for it. V6 can be run on an -11/23 (I've done it), but not straight out of the box; it requires a few minor tweaks first: http://gunkies.org/wiki/Running_UNIX_V6_on_an_-11/23 Noel

3 years, 11 months

Apple IIe Unix?

by Will Senn

Hi All, So, I'm about to get my very own Apple IIe and while it's an incredibly versatile machine for assembly language and hardware hackery, I'm not aware of any Unices that run on the machine, natively. Does anybody know of any from back in the day? It's got a 65c02 processor and somewhere around 128k of RAM, but it's also pretty expandable w/7 slots and a huge amount of literature about how to do stuff w/those slots. Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

4 years

Re: [TUHS] Apple IIe Unix?

by jnc＠mercury.lcs.mit.edu

> From: Steve Nickolas > there's no easy way to do preemptive multitasking without extra > hardware. Perhaps you're using some idiosyncratic definition of "preemptive" and "multitasking", but to me that statement's not accurate. Let's take the "multitasking" part first: that just means 'two or more computations can run at the same time, sharing the machine' - and that's not hard to do, without special hardware, provided there's some way (in the organization of the software) to save the state of one when the other is running. Many simple systems do this; e.g. the MOS system that I used on LSI-11's, BITD. "Preemptive" is a bit trickier, because things have to be organized so that one 'task' can be temporarily stopped arbitrarily (i.e. without it explicitly giving up the processor, which is what e.g.MOS did) to let another run. There does need to be some asynchronous way of inciting the second 'task' to run, but interrupts (either clock, or device) do that, and pretty much every machine has those. MINI-UNIX, for example, has premptive multitasking. The thing that takes special hardware is _protecting_ one task from a bug in another - a bug which could trash the first tasks's (or the system's!) memory. One has to have memory management of some kind to do that. > From: Dave Horsfall > I would start with something like Mini-Unix MINI-UNIX would be a good place to start if one wanted to bring up a system on a machine without memory management; there's nothing in the kernel which is PDP-11 dependent that I can think of (unlike V6, which had a fairly heavy dependency on the PDP-11 memory management hardware - although one could of course rip that all out, as MINI-UNIX did). However, one's still looking at a fair amount of work, both to get rid of any traces of PDP-11isms (e.g. stack growth direction), and translate the assembler part (startup, and access to non-C operations). Something like FUZIX might be an easier option. Noel

4 years

Why do compress(1) and pack(1) use the .Z / .z extension?

by Hans Wennborg

I'm trying to find out why compress(1) uses .Z as filename extension. My theory is that it was inspired by pack(1), which uses the .z extension. However, I haven't been able to find any info on why pack(1) uses that extension. Does anyone here know? Some searching led me to [1] which is a man page for pack from AUSAM. It's written by Steve Zucker in 1975, so perhaps the extension is z for Zucker? Was Zucker's pack(1) the first, though? This message [2] talks about a Bell version. Does anyone here have any information about this? Cheers, Hans 1. https://minnie.tuhs.org/cgi-bin/utree.pl?file=AUSAM/doc/man/man1/pack.1 2. https://tech-insider.org/unix/research/1984/0319.html

4 years

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 November 2020