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