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
So, it looks like someone has gone and started running a multics instance:
http://lists.nycbug.org/pipermail/semibug/2018-August/000288.html
That’s interesting, and y’all may even have been aware of it. But, I was thinking that Multics was a failed predecessor of unix and it’s craziness an inspiration for how unix isn’t multics... straighten me out :)
Will
Sent from my iPhone
So I just read this
https://www.usenix.org/legacy/event/usenix99/full_papers/cranor/cranor.pdf
and it looks encouraging. Apparently NetBSD is using it. Does anyone
know if they are happy with it?
Has FreeBSD considered this?
Has anyone benchmarked FreeBSD against NetBSD to see which is faster
for VM stuff?
Greetings,
Multics, while not a 'massive' sales success in retrospect, was certainly not the failure commonly believed and wasn't treated as one in the press of the time - at least not until after the decision was made by Honeywell-Bull to phase out the the Multics (and CP-6) products to focus on GCOS - GCOS7/GCOS8 is still a major player today.
"Honeywell is having considerable — and surprising — success with the ultra-secure Multics operating system … Besides 3-5 systems within Honeywell, Multics has been installed or committed within Nippon Electric, Rome Air Development Center, USAF Data Services Center, and Ford." from mid-1970's industry press.
See also https://multicians.org/myths.html
We have about 120 members on BAN - including many original and new Multicians who make the project possible. We're always working on new things and projects - see "pmotd -a" when logged in for some of the most recent activity.
I'd be happy to answer any questions on BAN.AI if anyone has particular questions - or just ssh to dps8(a)m.trnsz.com - feel free to use the guest account. I don't want to take the list too off-topic. We have many exclusive features that I hope makes BAN.AI a 'special' (and loved) system, a lot more coming.
--
https://ban.ai/multics
