We lost J.F. Ossanna on this day in 1977; he had a hand in developing
Unix, and was responsible for "roff" and its descendants. Remember him,
the next time you see "jfo" in Unix documentation.
-- Dave
Hello,
For your information (and to reduce my guilt for posting off topic
sometimes), I have 4.1BSD running with Chaosnet patches from MIT. I'm
adding a Unibus CH11 network interface to SIMH. It's not working fully
yet, but it's close.
Best regards,
Lars Brinkhoff
> From: Larry McVoy
> (*) I know that nroff was "new run off" and it came from somewhere, MIT?
> Some old system ... I've never seen docs for the previous system and I
> kinda think Joe took it to the next level.
Definitely!
The original 'runoff' was on CTSS, written by Jerry Saltzer. It had a
companion program, 'typset', which was an editor for preparing runoff input. A
memo describing them is available here:
http://web.mit.edu/Saltzer/www/publications/ctss/AH.9.01.html
>From the look of things, it didn't have any macro capability.
Runoff was moved to Multics fairly early: here's its entry from the Multics
glossary:
A Multics BCPL version of runoff was written by Doug McIlroy and Bob
Morris. A version of runoff in PL/I was written by Dennis Capps in
1974.
...
Multics documentation was transitioned from the Flexowriters to use of
runoff when the system became self-hosting about 1968. runoff was used for
manuals, release bulletins, internal memos and other documentation for most
of the 70s. To support this use, Multics runoff had many features such as
multi-pass execution and variable definition and expansion that went far
beyond the CTSS version. Multics manuals were formatted with complex macros,
included by the document source, that handled tables of contents and
standard formatting, and supported the single sourcing of the commands
manual and the info files for commands.
So the BCPL version would have been before Bell exited the project. I'm not
sure if the 'macros' comment refers to the BCPL version, or the PL/I. Here's
the Multics 'info' segment about runoff:
http://web.mit.edu/multics-history/source/Multics/doc/info_segments/runoff.…
which doesn't mention macros, but lists a few things that might be used for
macros. It refers to "the runoff command in the MPM Commands" volume (a
reference to "Multics Programmer's manual: Commands and Active Functions") for
details; this is available on bitsavers, see page 3-619 in "AG92-03A",
February 1980 edition.
Noel
> From: Lars Brinkhoff
> Emacs is very much divorced from the Unix philosopy. However, it's
> perfectly in synch with how things are done in ITS.
Hmm. It is complicated, but... the vast majority of my keystrokes are typed
into Epsilon (a wonderful, small, fast EMACS-type editor for Windows, etc
which one can customize in C) - especially since I started, very early on (V6)
to run my shell in an EMACS window, so I could edit commands, and thus I was
pretty much always typing to EMACS. So, it makes sense to me to have it be
powerful - albeit potentially a bit complex.
I say 'potentially' because one could after all restrict oneself to the 4
basic motion commands, and 'delete character'; you don't have to learn what
CRTL-ALT-SHIFT-Q does.
> Stallman .. developing GNU Emacs (from Gosling's version)
Err, I'm not sure how much influence Gosling's was. He had, after all, done
the original EMACS on ITS; I got the impression he just set off on his own
path to do GNU Emacs. (Why else would it be implemented in LISP? :-).
Noel
Hello, everyone:
Recommend a few c language to write on the computer that do not have a network, best can compile to run with GCC. This will kill my time. I like to play with greedy snake written in c language, which is really interesting. Thank you very much!
Caipenghui
Nov 17, 2018
> From: Clem Cole
> Actually I blame the VAX and larger address spaces for much of that and
> no enough real teaching of what I refer to as 'good taste.' When you
> had to think about keeping it small and decomposable, you did. ...
> Truth is, it is a tough call, learning when 'good enough' is all you
> need. ... The argument of course is - "well look how well it works and I
> can do this X" -- sorry not good enough.
Exactly; the bloat in the later Unix versions killed what I feel was the
_single best thing_ about early Unix - which was its awesome, un-matched
bang/buck ratio.
_That_ is what made me such a huge fan of Unix, even though as an operating
system person, I was, and remain, a big fan of Multics (maybe the only person
in the world who really likes both :-), which I still think was a better
long-term path for OSes (long discussion of why elided to keep this short).
I mean, as an operating system, I don't find Unix that memorable; it's (until
recently) a monolithic kernel, with all that entails. Doing networking work on
it was a total PITA! When I looked across as what Dave Clark was able to do on
Multics, with its single-level memory, and layered OS, doing TCP/IP, I was
sky-blue pink with envy.
Noel
Sorry about the recent post. It may seem peripherally
connected to tuhs, but it got there due to overtrained
fingers (or overaged mind). It was intended for another list.
Doug
Hi All.
In https://www.youtube.com/watch?v=_2NI6t2r_Hs&feature=youtu.be Rob Pike
mentions that DMR and Norman Wilson ported Unix to the Cray 1 and that
it was not straightforward.
This sounds interesting. Norman: would you be kind enough to elaborate
on this?
Thanks,
Arnold
On Wed, 14 Nov 2018, Warren Toomey wrote:
>> Hell, I wish I still had that "CSU Tape"; it was Edition 6 with as much
>> of Edition 7 (and AUSAM) that I could shoe-horn in, such as XON/XOFF
>> for the TTY driver. I was known as "Mr Unix 6-1/2" at the time...
>
> Definitely look at the UNSW tapes I have:
> https://minnie.tuhs.org/cgi-bin/utree.pl?file=AUSAM
> and https://www.tuhs.org/Archive/Distributions/UNSW/
> in case any of these are what you are looking for.
I think I did before, but I confess I didn't spend much time on it. My
pride and joy was certainly the rewritten ei.c driver (implementing the
200-UT batch protocol), and the clever workaround to an egregious KRONOS
bug where it would get stuck in a POLL/REJECT loop (I merely sent a dummy
command viz "Q,I" -- discarding the response -- because KRONOS was
expecting a command instead of the correct REJECT being nothing to send
from the batch emulator).
At the time, Unix got blamed because the smaller non-Unix /40s (running a
standalone program) worked fine for some reason; my guess is that it
implemented the broken protocol somehow.
-- Dave