actually not an early clone but a late(r), Philips MPX
(Multi-processor UNIX) based on SystemV running on Moterola CPUs.
Mostly sold in the (Retail) Banking Industry as branch server. The "M"
was more related to having various boards running their own UNIX. That
would be an Ethernet board and one Networking board for SDLC and X.25.
These boards run their own copy of unix to 'offload' the main CPU.
I've worked with this UNIX but more a system tester, interface to
National Sales Organisations. No idea where the source is, but guess
it would be IP of Philips (or DEC, or Compaq, or HP, or HPE) if anyone
still remembers that is.
For a (very) short while there was also an Intel CPU based version,
but dropped in favour of SCO UNIX when DEC bought Philips Computer
division.
A very little bit in this 1987 article.
https://www.cbronline.com/news/better_late_philips_enters_the_uk_unix_marke…
Cheers,
uncle rubl
> From: Warner Losh
> So at some point you had to hack things in to make 20xx work, no?
I had a number of date issues with V6; more here:
http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#Issues
That one was the easiest to fix! (Although this one will probably also be
pretty easy, too.)
Noel
> From: Clem Cole
> IP and datagrams were very much built on no central control
Well, yes and no. One can easily have a centrally controlled datagram network
(q.v. the ARPANET) - although it's true that its path-selection algorithms,
etc were not centrally controlled - but other aspects of the network were.
(Interestingly, after various routing disasters the Internet caused by
improper configuration, some aspects of path selection in _parts_ of it are
now effectively centrally controlled; but I digress.)
The IP Internet was designed with no _overall_ central control, but as a
collection of autonomous entities.
> In the end, it was MetCalfe's law (which was formulated on observations
> about the phone system) that caused IP to win
Over any and all comers, including other decentralized datagram networks like
CLNP. MetCalfe's law doesn't talk about decentralized, it's just about 'first
to field'.
> all want to see the net neutrality go away
This whole 'net neutrality' campaign drives me completely crazy.
If all people wanted was a rule saying 'ISPs can't give third parties _worse_
service, or - more importantly - deny service altogether, unless those parties
pay up' (i.e. what would amount to targeted extortion), I'd be _all for_ a
rule like that.
But the 'net neutrality' aficionados (most of whom, I'm fairly sure, are not
aware of/thinking about these details) are all signing up for a much more
expansive rule, one that says 'no ISP can offer anyone _better_ service for
paying more money' - which is quite different. My problems with this latter
form are two-fold.
First, what's wrong with that anyway? Do we have a rule saying you can't get
better road service if you pay? Absolutely not - restricted toll lanes are
becoming more and more common. So there's clearly no societal agreement on
this principle. (I suspect this 'net netrality' campaign has as a goal some
sort of 'forced equality' thing - unless the people behind it simply don't
even understand the difference.)
Second, that rule is, with a little extra work on the ISPs' part, ineffective
anyway. All they have to do is build _two_ networks, one better provisioned
than the other - and priced accordingly. You want better service? Sign up for
the second network; you'll pay more, but it's your choice.
Noel
> From: George Michaelson
> I didn't mean to disrespect the people who did the models or the
> protocol or standards work btw.
Oh, I personally have no problem with you saying hard things about this work,
as long as it's what you really think. One never finds the truth unless one is
willing to look hard, neh? And I'm pretty sure Dave Clark (who was a leading
light in IntServ) would be OK with you doing so too (I worked very closely
with him for years, to the point where I deputized for him at meetings).
I honestly don't remember exactly what my take was on IntServ and RSVP; I'd
have to go look. I recollect seeing the case that _if resources were limited_,
certain classes of application (I guess we called them 'inelastic') would need
reservations to work properly. So I was probably susceptible to the argument
that 'if we've got bandwidth to light our <insert flammable objects> with, we
don't need resource reservation'. And I remember being not _thrilled_ with
RSVP, but I don't recall exactly why.
But, as, you said, wrong list. Maybe internet-history:
http://mailman.postel.org/mailman/listinfo/internet-history
if you did want to delve into it.
Noel
> From: Jon Steinhart
> Probably the best person to ask is Heinz Lycklama.
I checked my email log for my previous MERT enquiries, and that's the exact
same advice I got from Brian Kernighan when I asked him (a couple of years
back) if he had any suggestions for tracking it down.
I guess I need to finally get a 'round tuit'... unless there's someone else
here who knows him well, and wants to give it a go.
Noel
> From: George Michaelson
> I don't think this list is the right place to conduct that particular
> debate.
Not disagreeing; my message was a very short gloss on a very complicated
situation, and I wasn't trying to push any particular position, just pointing
out that work (whether the right direction, or not, I didn't opine) had been
done.
> Its true RSVP didn't get traction, but the economics which underpin it
> are pretty bad, for the current Internet model of settlement
Yes, but would _any_ resource reservation system, even one that _was_
'perfect', have caught on? Because:
> it would not surprise me if there is ... more dropped packets than
> strictly speaking the glass expects.
This is related to something I didn't mention; if there is a lot more
bandwidth (in the loose sense, not the exact original meaning) than demand,
then resource reservation mechanisms buy you nothing, and are a lot of
complexity.
While there were bandwidth shortages in the 90s, later on they pretty much
went away. So I think the perception (truth?) that there was a lot of headroom
(and thus no need for resource reservation, to do applications like voice)
played a really big role in the lack of interest (or so people argued at the
time, in saying IntServ wasn't needed).
Noel
> From: Steve Johnson
> Recently I've been attempting to Skype on a group call with 5 people in
> Europe. I would LOVE to have a guaranteed bandwidth for my call.
The Internet engineering community did quite a bit of work on resource
guarantees. (Google 'IntServ' and 'RSVP' - the latter is the control
protocol.)
Unfortunately, there was never much interest in it. People started doing
voice with just plain 'best effort' service, and I guess it worked 'well
enough' that nobody was interested in IntServ/RSVP.
Noel
> From: Larry McVoy <lm(a)mcvoy.com>
> Did you read the reddit link I sent?
No, because I despise Reddit.
> Because if you had you wouldn't be asking this.
Now that I look at it, most of what I lists is ISP's _blocking_ sites.
I _already_ said I wanted to see a rule preventing that.
> unregulated businesses will do whatever they can to make more money with
> absolutely no concern about the consequences
Sure - like content providers.
Noel
> From: Clem Cole
> Just like the electric company, needs to deliver electrons at some
> rate/force.
If you want electrons at more than X bazillion per second, you'll have to pay
to have a higher-amperage service. And if you use more electrons, you pay
more. What's your problem with ISPs doing the same?
Noel
> From: Larry McVoy <lm(a)mcvoy.com>
> look at the history, various ISPs like Verizon, Comcast, etc, have done
> stuff like block bittorrent, skype, etc
Bittorrent is a complex situation, some ISPs were ordered by a court to block
it.
As to Skype, I agree ISPs shouldn't block sites - but if you read my message,
I already said that.
> The problem is I paid for the bits. Bits is bits. I paid for a rate,
> that's what they got paid for, why should they get to charge a second
> time for the same bits? That's exactly what they want to do.
Fine, you pay your money, you get X Mbits/second.
If you (or the site you're getting bits from) wants _more_ than X
Mbits/second, charging you - or them, which is I gather mostly what ISPs want
to do - for that privilege is a problem... how?
Noel
Anyone on TUHS who made the list?
Greeting from your Dutch uncle rubl
For all the sound advise you don't want to hear.
Date: Sun, 10 Dec 2017 13:23:13 +1100 (EST)
From: Dave Horsfall <dave(a)horsfall.org>
To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org>
Subject: Re: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana!
Message-ID: <alpine.BSF.2.21.1712101314210.35694(a)aneurin.horsfall.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
On Sat, 9 Dec 2017, Ralph Corderoy wrote:
>> Yeah, but all the same, two famous people in the same industry would
>> surely lengthen the odds somewhat...
>
> Yeah, you're pulling my leg. :-)
> https://en.wikipedia.org/wiki/List_of_computer_scientists
OK, it was worth a try :-) (I'm a born stirrer, and I blame my parents
for that.)
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
(At the risk of being flamed because it's not strictly Unix...)
We gained Rear Admiral Grace Hopper on this day in 1906; known as "Amazing
Grace", she was a remarkable woman, both in computers and the Navy. She
coined the term "debugging" when she extracted a moth from a set of relay
contacts from a computer (the Harvard Mk I) and wrote "computer debugged"
in the log, taping the deceased Lepidoptera in there as well. She was
convinced that computers could be programmed in an English-like language
and developed Flow-Matic, which in turn became, err, COBOL... She was
posthumously awarded the Presidential Medal of Freedom in 2016 by Barack
Obama.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
As promised :-)
Augusta Ada King-Noel, Countess of Lovelace (and daughter of Lord Byron),
was born on this day in 1815; arguably the world's first computer
programmer and a highly independent woman, she saw the potential in
Charles Babbage's new-fangled invention.
J.F.Ossanna was given unto us on this day in 1928; a prolific programmer,
he not only had a hand in developing Unix but also gave us the ROFF
series.
Who'ld've thought that two computer greats would share the same birthday?
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Something's been bothering me for a while... I've just remembered that
our 11/40 with more peripherals than you could shake a stick at -- it had
just about everything except a DECtape -- also had, so help me, a card
reader! As I dimly recall, 'twas a slow CDC (?) model; we didn't have it
for long, either because it was on loan or because it was so unreliable, I
simply don't remember.
Anyway, our driver handled it in two modes: you either got a raw image of
each card (likely via DMA instead of column by column, but I could be
wrong) i.e. 80 words with each column of 12 holes fitting nicely into a
16-bit word, or there was a half-arsed attempt at converting EBCDIC to
ASCII, with trailing blanks replaced by a newline (i.e. think of it as a
line printer in reverse). Or was it converting from whatever KRONOS used
to ASCII?
Now, what I *distinctly* remember was writing two scripts: "/etc/cdc" and
"/etc/dec" which switched between the two modes, quite likely by patching
the in-core kernel!
I'd give a testicle to have that "CSU tape" back again (and no doubt so
would Warren), but can anyone else remember this (or dare to call me a
liar; yes, I'm still touchy about that)? The snag is, towards the end of
the CSU before they were about to be engulfed by the admin suits and
forced to support payroll programs in COBOL etc, I was the only senior
Unix bod left, so it's unlikely that the CSU source code followed someone
else home...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Hello everyone,
A few weeks ago, I merged my work-in-progress AT&T 3B2/400 emulator
into the main SIMH source tree, and I realized that I should mention
it here, where there may be particular interest.
The 3B2 and 3B5 were main porting platforms for AT&T System V Release
3, and when I realized how scarce the equipment has become to find, I
set out to write an emulator for the 3B2. It was rough going at points
due to lack of documentation, but I was able to reverse engineer quite
a bit of the system through reading the SVR3 source code, and of
course strapping my own 3B2/310 to a logic analyzer.
The emulator is fairly complete. It certainly works well as a
standalone, single-user UNIX system. Support for multiple terminals is
coming very soon (as soon as I find the time, that is) so it will soon
be possible to allow multiple users to telnet into virtual terminals,
similar to how the SIMH PDP-11 and VAX emulators work.
For now, information about the emulator lives here:
https://loomcom.com/3b2/emulator/
Best Wishes,
-Seth
--
Seth Morabito
web(a)loomcom.com
OK. I'm confused. Maybe people here can help me understand.
Looking at the V7 sources, it looks for all the world like they were
released Jan 10, 1979. This release was PDP-11 only. So far, so good.
32V, a port to the VAX, is listed as 'early 1979'. Dates in the files in
the archive suggest March 26th, 1979 (though there are dates as late as May
3rd and April 30th on two files that are trivial). The tape we have in the
archive has a date Feb 22, 1980 written on it. Given the dates, that's only
3 months after V7 was released. This seems very fast, but maybe it's OK
since it's a swapping release....
3BSD, The Berkeley 32V has file dates as late as Mar 22, 1980... This seems
reasonable for turning V7 from swapping into paging... about a year is fast
but not crazy fast.
My question is: did these three events really happen in this quick
succession? Did USDL folks get started with a preliminary V7 for V32 or was
the port really done in 2 and a half months? Likewise with UCB and 3bsd:
did they start early?
Warner
> Venix/86 and Venix/86R might be interesting... I have impure versions of
> both...
+1
Venix/86 is the first Unix to run on PC hardware that I’m aware of. It could
go together with Idris and Minix as examples of early PC Unix.
For more on Admiral Grace Murray Hopper, by one who knew her well, see
Jean Sammet's remembrance:
Farewell to Grace Hopper: end of an era!
https://doi.org/10.1145/129852.214846
A Ph.D. thesis about her:
The Contributions of Grace Murray Hopper to Computer Science and Computer Education
https://digital.library.unt.edu/ark:/67531/metadc278692/m2/1/high_res_d/100…
Books:
Grace Hopper: Admiral of the Cyber Sea
1-59114-978-9
Grace Hopper and the Invention of the Information Age
ISBN 0-262-51726-4
Grace Hopper: Computer Whiz
ISBN 0-7660-2273-0 [juvenile literature]
I've always found it amusing that she was a strong proponent of the
work ethic: "Act first, get permission later", which is in direct
opposition to the military chain of command, despite her rank as Rear
Admiral of the US Navy.
See also
ACM Grace Murray Hopper Award
https://awards.acm.org/hopperhttps://awards.acm.org/hopper/award-winners
[Awarded to the outstanding young computer professional of the
year, selected on the basis of a single recent major technical
or service contribution. This award is accompanied by a prize
of $35,000. The candidate must have been 35 years of age or
less at the time the qualifying contribution was
made. Financial support of the Grace Murray Hopper Award is
provided by Microsoft.]
Don Knuth of Stanford was the first GMHA winner, in 1971; other
well-known people include Steve Wozniak (1971), Bob Metcalf (1980),
Dan Bricklin (1981), Brian Reid (1982), Bill Joy (1986), John
Ousterhout (1987), Guy Steele (1988), Richard Stallman (1990), Bjarne
Stroustrup (1993), Vern Paxson (2007), Craig Gentry (2010), ...
There is also a 1983 interview on a popular US news broadcast that
celebrates its 50th anniversary this year:
The 60 Minutes interview with Grace Murray Hopper
https://www.cbsnews.com/news/the-60-minutes-interview-with-grace-murray-hop…
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
> I've never seen a detailed description of UNIX/TS, although I have seen
> the "Unix Program Description" (January 1976) which documents the USG
> version, and of course PWB is described in the BSTJ issue, and UNIX/TS
> is supposedly a merge of those two.
> ...
> Did the later USG versions takeup some of the PWB work, does anyone
> know? (My thinking is 'if I find traces of PWB [in the MIT system],
> would that be from /TS, or could it be a later USG version' - I think
> there were 1-3, from something I saw online.)
So I seem to have stumbled on something interesting here (or maybe it's not,
and the history is just unclear - well, unclear to me at least, I'm sure
someone knows).
Looking at "Unix Program Description" (January 1976), it's clearly marked as
"Published by the UNIX Support Group". (I have an actual hardcopy, which I
don't recall how I came by, but for those who wish to follow along this
document is available in the TUHS archive, at:
http://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_jan…
and in other TUHS mirrors).
So, given the credit, I _assume_ that it documents some version of the USG
system. So I started looking at that, and the PWB version that's in the
archive:
http://www.tuhs.org/Archive/Distributions/USDL/spencer_pwb.tar.gz
to see how they compare, and it turns out (somewhat to my surprise) that the
USG document describes what seems to be an older version of the system.
For example, in text.c, it doesn't cover xlock()/xunlock()/xexpand(), all in
the PWB system - just xalloc()/xccdec()/xfree()/xswap().
Even more telling, in sys1.c, the USG document describes the older version of
exec(), where arguments are collected in a disk buffer, not (as in the PWB
system) in swap space. (I had thought that this change was mentioned in the
PWB paper in the BSTJ issue, but on checking, it appears my memory was
incorrect. Many of the PWB changes appear to be to things like the shell, not
the OS.)
So it seems the USG document describes a system very close to the 'classic'
V6 - not what I had expected. This may also make it hard to recognize USG
source (at least, the early versions).
More generally, it would be good to try and elucidate the relationship among
all these early Bell/AT+T versions: Research, USG, PWB, etc. Clearly the two
latter (from what we know now) are descended from V6 - but was there any
interchange between USG and PWB?
And did either of them feed back into V7? Or, perhaps more likely, were the
improvements to text.c, exec() etc _Research_ improvements that got fed into
PWB?
More questions than answers, sadly... I'm not at all familiar with V7, I'll
have to go read it at some point, and compare it to PWB. Not that I expect it
will answer many (any?) of these questions, but maybe we'll get lucky and
there will e.g. be stuff in this PWB which isn't in V7.
Speaking of which, I seem to recall there's more than one PWB version. I
wonder which one we have (above). Although there's another 'PWB' tape in the
archive:
http://www.tuhs.org/Archive/Distributions/USDL/bostic_pwb.tar.gz
(much larger than the other one), when I poked around a bit through that,
seeing what's there, and comparing it to the other one, the system sources I
looked at there all seemed to be the same as the one on the Spencer tape.
> I should look at the MIT kernel and see how much of it is USG, and see
> if I can find any traces of the changes described as done for PWB. I
> know the MIT version has provisions for longer exec() arguments, and
> text.c is considerably more complex than the one in V6 (and IIRC matches
> the description in the USG document)
So, my memory was in error here; the text.c matches the one from the PWB tape,
_not_ the USG document. In general, the parts of the MIT system seem to be a
close match to what's on the PWB tape, with the exception that the MIT one
seems to be slightly earlier (no 'register' argument types).
> Perhaps the MIT system really was /TS
Without a better understanding of what was really in /TS, this is totally
opaque.
> I've always described it as a hacked PWB1, but I might be wrong there.
And for once, I think I was right. The MIT system _does_ closely match the
one on the 'PWB' tapes - whatever that was!
Noel
So, I'm getting the impression, from the reactions about civility, etc, that
people aren't disagreeing with the characterization of "rudeness" (which can
only be meaning my posts). Can someone please point to text in my messages
which they consider "rude"? Thanks.
Noel
The ARPAnet reached four nodes on this day in 1969 (anyone know which?);
at least one "history" site reckoned the third node was connected in 1977
(and I'm still waiting for a reply to my correction). Well, I can believe
that perhaps there were only three left by then...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
A long time ago, dmr wrote about something that IIRC BSD had done he did
not like: unlimited length identifiers in C, maybe? His argument was that
being too general was not a good thing.
Can't quite find the quote, anyone remember it? Would have been ca. 1980.
ron
> From: Clem Cole
> it's direct predecessor (UNIX/TS) which was not officially released made
> its way to number of places ... heavily hacked systems that were combo's
> of V6, PWB [1.0], UNIX/TS plus local additions. UNIX/TS had a newer
> kernel, updated FS and the compiler that was released with troff -
> a.k.a. 'Typesetter C'
I'm not sure quite what the MIT system was.
I've never seen a detailed description of UNIX/TS, although I have seen the
"Unix Program Description" (January 1976) which documents the USG version,
and of course PWB is described in the BSTJ issue, and UNIX/TS is supposedly a
merge of those two. (If we ever do find V6+ USG source, it should be easy to
verify - that document is pretty detailed.)
I should look at the MIT kernel and see how much of it is USG, and see if I
can find any traces of the changes described as done for PWB. I know the MIT
version has provisions for longer exec() arguments, and text.c is
considerably more complex than the one in V6 (and IIRC matches the
description in the USG document); but I don't recall withough careful
checking, what was done where. Perhaps the MIT system really was /TS, and I
didn't know that - I've always described it as a hacked PWB1, but I might be
wrong there.
Did the later USG versions takeup some of the PWB work, does anyone know? (My
thinking is 'if I find traces of PWB, would that be from /TS, or could it be a
later USG version' - I think there were 1-3, from something I saw online.)
I initially got /TS mixed up with /RT, which is the system I'd _really_ like
to find - well, MERT, actually. I think that's a really early micro-kernel
system (although I haven't done any research to confirm that), a direction I
think is important. (I think the 'THE Multiprogramming System' may be the
earliest work in that direction, although I'd be interested to hear of
anything else.)
I actually got contact info for some of the original MERT people, and was
going to contact them to see if they still retained anything, but I never
got a 'round tuit'... too many other projects. :-(
Noel