Should have copied the list...
-----Original Message-----
From: William Pechter <pechter(a)gmail.com>
To: Henry Bent <henry.r.bent(a)gmail.com>
Sent: Wed, 26 Sep 2018 11:59
Subject: Re: [TUHS] SPARC is CRAPS spelled backwards.
There was Xenix-86 which ran on the AT&T 6300, and IBM PC/XT. I ran it on an 8MHz NEC V30 cpu on the 6300. I would love to install it on my Panasonic Sr. Partner but lost the install key.
-----Original Message-----
From: Henry Bent <henry.r.bent(a)gmail.com>
To: TUHS main list <tuhs(a)minnie.tuhs.org>
Sent: Wed, 26 Sep 2018 11:45
Subject: Re: [TUHS] SPARC is CRAPS spelled backwards.
On Wed, 26 Sep 2018 at 02:21, Peter Jeremy <peter(a)rulingia.com> wrote:
>
> An 8-bit memory bus means half as many RAM chips and buffers. Keep in mind
> that the IBM 5150 was intentionally crippled to ensure it didn't compete
> with
> IBM's low-end minis.
>
Did the 5150 have a UNIX available anywhere near its launch date? I know
that it had DOS, CP/M-86, and the UCSD p-System relatively early on. It's
not clear to me whether Xenix ever supported the original PC; were there
other early porting efforts?
-Henry
> From: Tony Finch
> This paper has a nice survey of instruction set densities
And the winner is.... the PDP-11!
I'm not too surprised by this; back in the days of core memory (and limited,
at that - the first PDP-11's came standard with ... 8KB of memory :-), having
the denset possible code had real savings.
Noel
> From: Paul Winalski
> In general, a CISC instruction set encoding can express the same
> algorithm more compactly than a RISC instruction set.
I have often pointed to memory bandwidth as one of the key factors in the
evolution of CISC and RISC. When it was low, compared to CPU speeds (most of
the core era), CISC made sense. When it increased (with DRAM), RISC made more
sense, because it allowed CPUs to run faster (via simpler instructions).
Caching made the picture a little more complex; and today, with the incredible
mismatch between memory speeds and CPU speeds, caching dominates, whether you
have RISC or CISC.
Noel
Hi,
I'm hoping to run System V Release 1 on my pdp11/45, provided I can find
a controller that'll emulate one of the few disks it supports. I've been
looking around trying to find the installation manual to no avail. The
programmers manual, user's manual and error manual are all readily
available, but nothing about install aside from some anecdotal lines from a
simh install. Would anyone have a hint on where to find it or perhaps a
real copy to lend? Happy to scan and mail back if so.
thx
jake
On Sun, 2 Sep 2018, Peter Jeremy wrote:
> [2] This is good enough because Australian ISPs don't believe in IPv6
If I go to a site that reports my IP address, I get IPv6 (I have a static
IPv4 address), which appears to be the default used by my router (a
Fastnet 5355 or something, which T$ appear to be unloading on us).
I tried asking T$ for a static IPv6 range, but was unable to find anyone
who even knew what I was talking about.
-- Dave
Today, a great scientist Dennis Ritchie was born, he did too much for humanity! I can't describe him in words, Dennis wishes you a happy birthday!
Caipenghui
Co-inventor of Unix, and sadly lost to us in 2011, he was born on this day
in 1941.
Thank you Dennis (and of course Ken), for that wonderful OS that we still
use to this day, and imitated by others.
-- Dave
> you can't tell me
> this system was designed with the idea of running it using text terminal
> and no mouse. There is also no cursor addressing, no curses.
The well named Curses and the associated vi were an ugly outgrowth
of glass screens--an outgrowth many of us in the Unix lab never
adopted. That branch of evolution was unrelated to the Blit branch that
essentially preserved the old TTY interface, except that one could have
multiple terminals on screen and a mouse was available to give mechanical
help for manual cut/paste/edit activities. Plan 9 terminal-handling
smoothly continued that evolutionary branch.
Mouse support could have been used to take off in a radical direction,
but it wasn't. To my mind, the primary innovation in Plan 9 was not
terminal support, nor everything-is-a-file. Rather it was an advance in
what Vyssotsky called "distributable computing", where components can
collaborate in a uniform way, no matter where they are. The key was the 9P
protocol that unpacked the notion of file type--a unifying principle
that brought simplicity and generality to a diversity of particulars.
Hello all,
I'm beta-testing a service I've set up to allow public access to a network of computers running System V UNIX Release 3.2. This is only tangentially related to RetroNet, and we hope to peer with them once RetroNet has UUCP peering going!
The network consists of three emulated 3B2/400s linked by UUCP, and connected to the Internet through a gateway system. E-mail (UUCP, UUCP-to-SMTP, and SMTP-to-UUCP) works in and out of the network.
There is a small private Net News setup running BNews for that true historic flair. All machines have access to the "retronet.*" news hierarchy. (There is no public Usenet access, sorry!)
If you're interested in reliving some UNIX history, consider signing up for an account. You'll be randomly assigned a home host in the network.
Account signup form is here:
https://loomcom.net/
Access is via SSH-to-Telnet gateway, by connecting to:
$ ssh access(a)loomcom.net
(No password is needed for the SSH gateway, it is a captive portal)
-Seth
--
Seth Morabito
Poulsbo, WA
web(a)loomcom.com
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
> 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
> From: jcs
> The real mystery is what it's running on. ... It's=20 probably a
> simulator but I've never heard of one for the H6000.
Per:
https://multicians.org/multics.htmlhttps://multicians.org/multics.html
"Harry Reed and Charles Anthony reached a major milestone on the Multics
simulator on Saturday 08 November, 2014. Their SIMH-based simulator booted
Multics MR 12.5, came to operator command level, entered admin mode, created a
small PL/I program, compiled and executed it, and shut down. Release 1.0 of
the simulator is now available."
Noel
> On 1 Sep 2018, at 19:18,Warner Losh <imp(a)bsdimp.com <mailto:imp@bsdimp.com>> wrote:
>
> I recall a more knowledgeable friend complaining about FreeBSD VM in 1994 or so.
>
> It used to be downright aweful.
>
That sounds like a GOOD thing: full of awe!
At least it wasn’t offal: decomposing animal flesh.
-Don
