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
> From: Will Senn
> I was thinking that Multics was a failed predecessor of unix
> ... straighten me out :)
I'd start with:
https://multicians.org/myths.html
> From: Clem Cole <clemc(a)ccc.com>
> https://www.quora.com/Why-did-Unix-succeed-and-not-Multics/answer/Clem-Cole
Clem, I think that's too limited in scope.
Like a lot of 'big' 'failures' (defined in Multics' case as 'failure to grow
to significant market share, and continue in the long term'), I don't think
Multics 'failed' for a single reason.
In general, in large failures, there are a number of causes, all doing their
bit. Now, if there are M causes, ranked in priority, maybe the first N1 are
_each_ big enough that _any one_ of them could have led to that outcome. Or
maybe not; maybe it needed the first N2, all acting in concert.
My crystal ball isn't that accurate. But here's my take on _some_ of Multics'
main issues.
- Management: if you look at:
https://multicians.org/hill-mgt.html
it's clear that Honeywell top management didn't understand Multics, and
didn't understand that it had a long-term potential. They terminated
investment in new hardware, and that was what finally killed Multics.
- Non-portability: the system was too tied to a specific platform; it
couldn't really be moved elsewhere. (E.g. the code is riddled with 'fixed bin
18'; yes, that could be changed with a program to edit the source, but there
are lots of dependencies on the specifics of the machine's architecture.) It
would be possible to re-write it to run on, say, a 386, but you'd pretty much
have to start from scratch.
- Built for the wrong future: a key assumption was that people would continue
to get their computes from large centralized machines. Clearly, that was
wrong (and it played into the issues with Honeywell management)>. Multics
_could_ have made the transition to today's 'small' (physically) machines, in
which case it would have been really good to have - e.g. if we could run
browsers in AIM boxes a lot of malware simply would not be an issue. But the
point above prevented that.
Those are some of the big ones; I may come up with more. I've CC'd a couple
of Multicians - perhaps they can add additional insight.
Noel
