Andy Kosela:
One still cannot ignore the fact that Unix and Plan 9 offer two
completely different approaches to displaying text.
I admit I've never actually used Plan 9. Can you elaborate on
the different approaches?
One difference from most of what passes for UNIX these days is
probably that the basic terminal model allows one to edit anything
on the screen, using the mouse and keyboard and a simple button-2
menu similar to that of sam. You can edit what some program has
already printed, then pick it up and send it back as input. You
can even edit text in the current line that hasn't been sent yet
(because you haven't hit a return yet); in effect the canonical-line
part of the tty driver is in the terminal.
But you probably don't mean that, both because it's not really
such a radical difference, and because it doesn't conflict at all
with UNIX. In fact it originated on UNIX, five or six years before
Plan 9 was thought of: it's the model from the terminal program
in mux, the more-advanced version of the Blit/Jerq window manager
that nearly everybody used in 1127 by the time I arrived in 1984.
And I still use it every day, even on Linux (and in years past
on Solaris and IRIX and Digital UNIX and Ultrix). The modern
version of the program to do that is called 9term. It doesn't
work quite as well as I'd like on Linux due to changes in the
tty driver that make it hard for a program to learn right away
when tty modes are changed (in particular when echo is turned off
or on), and it does conflict with the GNU readline junk because
that turns off canonical processing, but to those of us who have
a taste for it it's still just fine.
As I say, I don't think that's the difference you mean, so please
step in and supersede me.
(And feel free to use my referring to something that is part of
the latter-day Research editions as an excuse to continue discussing
it. I think of Plan 9 as a successor to those systems anyway, and
therefore related to UNIX heritage, at least as long as we're
comparing and contrasting the systems.)
Norman Wilson
Toronto ON
On 08/29/2018 07:46 AM, William Pechter wrote:
> Also... If you run on the internet remember documented security exploits
> are decades old. I recommend no open ports except for ssh if it will
> build and maybe UUCP.
I'm working on a Retro Computing Networking project with a few other
people and I think it would be a benefit for things like running 4.3 BSD
and other old OSs in a relatively safe environment.
I'm bringing this up on TUSH for two reasons:
1) I think THUS members could benefit from RetroNet
2) I (we) would very much appreciate any suggestions or desires that
the THUS community would like to see in such a network.
The idea behind RetroNet is two fold:
1) Create a network of interconnected VPNs between interested parties.
2) Provide ISP like services over said interconnections.
Our hopes are for RetroNet to be able to provide a sandbox / small pool
/ isolated network where members can interconnect with each other (if
they want to) similar to the Internet, but with much less exposure. (We
are planing on RetroNet not having direct Internet connectivity.) We
are also hoping and planing to be able to carry any Ethernet based
traffic between sites, routed or not.
I (we) would be very interested in any input that THUS members might be
able to provide. Particularly what you might like to see in such a network.
--
Grant. . . .
unix || die
> From: Warner Losh
> The trouble, as I was given to understand when I worked at Solbourne,
> was that ... There were a number of third party bits and pieces in there
> that could not be relicensed ... if there are other IP issues, not
> limited ... It's that quagmire that efforts like this will run up
> against.
Oh, we'll just ask Oracle for a license 'for all parts of SunOS for which they
have the ability to grant a licence'.
There's no way I'd want them to have to chase down all the corner cases,
that's just a way to guarantee it will never happen. I'd want to ask for the
bare minimum of time/effort on their part.
Anything above that, probably the SCCS stuff would be next on the priority
list, sounds like.
Noel
> From: Henry Bent
> just because you can find source (or binaries, or CD images, etc.) on
> the internet, that doesn't make it the least bit legal. ... The concept
> of "abandonware" has no legal footing whatsoever.
True; but if all the copies of a particular item are discarded, one can make
all the lawyers on the planet as happy as clams, and it won't do a bit of
good. Save the bits, _then_ work out the legal issues, is my thinking on
priorities.
Noel
(PS: 'Internet' is spelled with a capital; there are many internets, but only
one Internet, just as there are many white houses, but only one White House. If
the technical community, which _does_ understand the difference, can't get it's
act together, how can we expect the media, etc, to do the right thing?)
I have a question...
I'm trying to recreate "a" source representation of the Venix for Rainbow
that I have. It's a v7 port, and I have all the .o's for it.
Most of the .o's compile, with the proper compiler, to the same code that
are in the .o's, at least judging from the .c file of the same name in the
TUHS archive.
The question is, what are the legal ramifications of publishing my
reconstruction?
Warner
Ron Natalie:
I use the numbers but I think it stems from the days when kill didn't take
the names. It's easier for me to remember -1 and -9 than to remember what
the mnemonics are.
====
Me too. And not just the kill command; the (real) shell's
trap command too.
It's all just muscle memory, not a desire to save keystrokes.
On the rare occasions when I need to send a post-modern signal
like SIGSTOP or SIGCONT, I use the name.
As an aside, why do modern kill and sh accept only the
abbreviated form of the signal name, not the full name;
e.g. kill -STOP is OK, kill -SIGSTOP an error? When we
taught kill about that sometime in (I think) the 9th Edition
era at Research, we allowed either form. I think it was
Doug who insisted on it, and he was right.
All this applies to shell commands, not to programs.
It is just plain wrong to code
kill(9, pid)
in C.
Norman Wilson
Toronto ON
After the past several years of focusing on 3B2 preservation and emulation, I've begun to wonder whether 3B2 hardware was used very much inside of Bell Labs. Has anyone ever heard whether Research UNIX was ever ported to the WE32100? I've certainly never seen anything that would suggest it was, but I'd love to be proven wrong.
-Seth
--
Seth Morabito
Poulsbo, WA
web(a)loomcom.com
> Was Algol 60 any kind of viable alternative at the time?
The operating system for the Burroughs B5000 had been written in
Burroughs Algol. That punctured the widespread belief that OS's
were so particular to the hardware that they had to be written
in machine language. I don't recall how far Burroughs Algol
went beyond Algol 60, nor why Multics did not want to follow
that lead. ("Viable" is a slippery concept when choosing
among Turing-complete alternatives.)
Doug
Caveat: As a member of the PL/I committee, and the person who brought
the new and unimplemented language to the attention of Multics, let a
disastrous contract for a compiler, and finally helped cobble together
a rudimentary compiler that got the project off the ground, I am not
exactly an unbiased observer.
A ground tenet of Multics was that it would be programmed in a higher
level language. A subsidiary requirement, which was generally agreed
upon, was language-level access to the logical operators and address
manipulation inherent in the hardware. No widely used language of the
time met this requirement. And they didn't want to get sidetracked into
language design.
Discussions finally boiled down to AED, developed at MIT by Doug Ross, and
PL/I. Ross was a brilliant software innovator with a mystical outlook that
made it difficult to distinguish his vision of what could be done from
what actually existed. AED was definitely a moving target. By contrast
PL/I had a written spec, so you knew exactly what could be done in it,
though not how well the compiler would do it.
PL/I was very big; we deliberately (and explicitly) omitted about
half the spec. The remainder was definitely seen as a "plausible
systems programming language".
>From the perspective of the time, why do you think the contrary?
Doug
