TUHS October 2020

tuhs@tuhs.org

23 participants
34 discussions

off-topic: Nominating Chet Ramey for USENIX flame award

by arnold＠skeeve.com

Hi All. I know this is off topic, but this list is full of the people who can help me with this. I'd like to nomimate Chet Ramey for the USENIX lifetime achievement award (yes, he's aware). I need 2-4 letters of support for this; anyone who agrees that he deserves it should send me such a letter, please (PDF, I guess) and I'll send in the whole package. See the details below. The deadline is October 19; please send a letter sooner rather than later. Let's start by sending me "yes, I'll write a letter" and then if there are lots, I'll pick four. PLEASE reply directly to me; no need to inundate TUHS with mail on this. Thanks, Arnold > Date: Wed, 30 Sep 2020 16:00:19 -0700 (PDT) > From: Casey Henderson <casey.henderson(a)usenix.org> > To: Arnold Robbins <arnold(a)skeeve.com> > Subject: Call for Nominations for the USENIX Lifetime Achievement Award > > Dear Arnold: > > USENIX offers several awards that recognize public service and technical > excellence in the fields, including the USENIX Lifetime Achievement Award > ("The Flame"): https://www.usenix.org/about/flame > > The Flame recognizes and celebrates singular contributions to the USENIX > community of both intellectual achievement and service that are not > recognized in any other forum. Please consider nominating a deserving > colleague! > > We invite you to submit nominations for USENIX's awards at any > time. However, to help us offer the award this year, we strongly encourage > nominations for The Flame by October 19. > > A nomination should include: > *Name and contact information of the person making the nomination > *Name(s) and contact information of the nominee(s) > *A citation, approximately 100 words long > *A statement, at most one page long, on why the candidate(s) should receive the award > *Between two and four supporting letters, no longer than one page each > > Please submit your nominations to the Awards Committee via awards(a)usenix.org. > > Best Wishes, > Casey Henderson > Executive Director > USENIX Association

2 years, 5 months

Status of Space Travel

by Warner Losh

What's the current state of efforts to get space travel working again? Warner

2 years, 5 months

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

by jnc＠mercury.lcs.mit.edu

> At some point, I'll produce a 'MiniUnix ld' on vanilla V6, so I can > build MiniUnix versions of applications there; the first will be the > shell, so I don't have to keep typing 'chdir' instead of 'cd'! :-) OK, that was pretty smooth. I now have (on the main V6 system) a linker in V6 binary form that outputs MX binary files, so I can do things like: mld sh.o /mnt/lib/lib[ca].a to produce a new shell (which worked fine). (I think to build 'mld' all I had to do was 'cc ld.c', in usr/sys/source on the MX disk.) This whole 'futz with MX by mounting the MX disk under V6' thing works really well. > Then on to trying to find out why MiniUnix crashes whenever I try and do > anything significant. I decided I wasn't up to tackling that, so instead I did all the edits to produce an LSI-11 version of MX. Doesn't boot, though; tries to do a panic, I think. I'm too burned out to keep going, I will continue tomorrow morning (US East Coast time). Once I get it running, before I make it available for download, I need to go back and put conditional assembly flags in mch.s so there's only one source file for both kinds of system; I had originally planned on doing that, but I was in such a 'code attack' mode I forgot all about it. Noel

2 years, 5 months

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

by jnc＠mercury.lcs.mit.edu

> From: Paul Riley > So mounting Mini-Unix on a running V6 system I guess allows you to run > Mini-Unix user mode binaries stuff Ah, no. They are all link-loaded to run at TOPSYS (060000), so won't run on V6 native. > Or do you plan to recompile on a stable system? Well, I need to find out what the problem is, first. Still, notable progress: using my 'mount the Mini-Unix RK pack on a V6 system' hack (which woked fine; the native V6 'icheck' and 'dcheck' work on that pack), I was able to sucessfully compile a few tweaked system modules (to get my usual line-editing chars, and turn off that irritating lower-case mode), and then build an OS load which could sucessfully boot. So good progress there. A couple of things I learned: - MiniUnix tools use the 'new' archive format, so the V6 vanilla 'ar' doen't grok MiniUnix archives (e.g. lib1/lib2). I have a 'nar', which I found on the 'Shoppa disks', which can deal with them. (We don't have source for it, but I'll bet the MIT PWB1 system has that; I'll get to that eventuallly. There's also an 'ar.c' on the MiniUnix disk; between the two, we'll be able to reconstitute source for 'nar'.) - Also, the vanilla V6 linker, 'ld', _also_ doesn't understand new archives; so the shell file to build a new system, 'shld': ld -a -x low.o conf.o lib1 lib2 blows out because it doesn't grok the libraries. Also, the '-a' flag, which says 'link starting at 0, not TOPSYS', doesn't exist in the V6 'ld'. I got around all that by unpacking lib1 (using 'nar', above) - it only contains two files - and then listing the files to link directly: ld -x low.o conf.o syso emulo dev/kl.o dev/devstart.o dev/rk.o The vanilla V6 linker of course produces an output linked at 0 without the -a flag. At some point, I'll produce a 'MiniUnix ld' on vanilla V6, so I can build MiniUnix versions of applications there; the first will be the shell, so I don't have to keep typing 'chdir' instead of 'cd'! :-) Then on to trying to find out why MiniUnix crashes whenever I try and do anything significant. Noel

2 years, 5 months

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