Hi!
I have an updated Unix 2.0v2 package running under the current Vax-780 sim.
It has been tuned up with missing packages and some new ones. Like automatic
startup with date/time setting, running fsck at boot and properly shutting
down
ALL processes at shutdown allowing for a "clean" shutdown thereby avoiding
fsck issues at the next boot.
Also there is a virtual tape so you can do backups..
My question is can THIS version access an IP address? And if so, how.
If there is any interest I could package it up into a tar file for others.
Thanks,
Ken
--
WWL 📚
Hello folks, posing a question here that will help with some timelining.
So System III, according to everything I've read, was commercially issued in 1982. However, PWB 3.0 was issued internally in 1980, two years prior. This isn't that surprising, give USL some time to work it up for commercial-readiness.
Where I'm curious is if there was a similar gap for the public release of PWB, given that was earlier on and pre-support and such. Was there a particular "public release" date for PWB 1.0 or would it have just been whenever folks started getting tapes out of Bell? I know it shows up in a price sheet floating around from say 1983 or 1984 among the likes of V7, 32V, System III, and System V also for sale, but would anything that early have had a formal "ship date" indicating a day they cut the master to copy tapes from or was it more of a contact Bell, someone will cut you a tape of whatever we've got right now?
Also, was PWB held as something that would be "marketable" from the get-go, or was it more of a happy accident that it wound up in the right place in the right time to become the commercial line? One would think USG Generic would be the one they'd shoot for being the "base" to build on, but everything I'm finding in my study of System III lately is pointing to a much more PWB-ish lineage with random borrowings from CB, PY, HO, IH, among others.
- Matt G.
There was such a tool, psroff (same name as, but no shared code with the
Adobe version) that read either C/A/T or ditroff output and produced
postcript. It was in volume 24 of comp.sources.unix. There were also
multiple patches to it.
It dates from 1991.
segaloco, you were looking for this? Contact me privately if you can't
find it.
Arnold
> From: "Ronald Natalie"
> Multilevel breaks are as bad as goto with regard to structure violation.
In a way, you are right. There isn't really much difference between:
for (mumble) {
for (foobar) {
do some stuff
break-2;
}
}
and:
for (mumble) {
for (foobar) {
do some stuff
goto all_loops_done;
}
}
all_loops_done:
The former is basically just 'syntactic sugar' for the latter.
I think the point is that goto's aren't necessarily _always_ bad, in and of
themselves; it's _how_, _where_ and _why_ one uses them. If one uses goto's
in a _structured_ way (oxymoronic as that sounds), to get around things that
are lacking in the language's flow-control, they're probably fine.
Then, of course, one gets into the usual shrubbery of 'but suppose someone
uses them in a way that's _not_ structured?' There's no fixing stupid, is my
response. Nested 'if/then/else' can be used to write comletely
incomprehensible code (I have an amusing story about that) - but that's not
an argument against nested 'if/then/else'.
As I've said before, the best sculpting tools in the world won't make a great
sculptor out of a ham-handed bozo.
Noel
> From: Warner Losh
> for breaking out of multiple levels of while/for loops.
Yeah, multi-level 'breaks' were one of the things I really missed in C.
The other was BCPL's 'VALOF/RESULTIS'. Back before C compilers got good
enough to do inline substitutions of small procedures (making macros with
arguments less useful), it would have been nice to have, for macros that
wanted to return something. Instead, one had to stand on one's head and use a
'(cond ? ret1 : ret2 )' of some form.
Noel
> From: Ralph Corderoy
> if you say above that most people are unfamiliar with them due to their
> use of goto then that's probably wrong
I didn't say that. I was just astonished that in a long thread about handling
exceptional conditions, nobody had mentioned . . . exceptions. Clearly, either
unfamiliarity (perhaps because not many laguages provide them - as you point
out, Go does not), or not top of mind.
Noel
I have successfully got System V running on a PDP11 sim.
I have been trying to add serial lines like on Version 7 but
have had no success.
What would be necessary under System V on a sim to do so.
I have already tried the SIMH group but no working answers.
If direct telnet is a better way please let me know.
Thanks
Ken
--
WWL 📚
Ca. 1981, if memory serves, having even small numbers of TCP connections
was not common.
I was told at some point that Sun used UDP for NFS for that reason. It was
a reasonably big deal when we started to move to TCP for NFS ca 1990 (my
memory of the date -- I know I did it on my own for SunOS as an experiment
when I worked at the SRC -- it seemed to come into general use about that
time).
What kind of numbers for TCP connections would be reasonable in 1980, 90,
2000, 2010?
I sort of think I know, but I sort of think I'm probably wrong.
So I decided to keep the momentum and have just finished the first pass of a Fifth Edition manual restoration based on the same process I used for 3B20 4.1:
https://gitlab.com/segaloco/v5man
There were a few pages missing from the extant PDF scan, at least as far as pages that were in both V4 and V6 sources, so those are handled by seeing how V5 source of the few programs compares to V6. I'll note which pages required this in a second pass.
I've set my sights on V1 and V2 next, using V3's extant roff sources as a starting point, so more to come.
- Matt G.
From reading a lot of papers on the origins of TCP I can confirm that people appear to have been thinking in terms of a dozen connections per machine, maybe half that on 16-bit hardware, around 1980. Maybe their expectations for PDP-10’s were higher, I have not looked into that much.
> From: Tom Lyon <pugs78(a)gmail.com>
> Sun chose UDP for NFS at a point when few if any people believed TCP could
> go fast.
> I remember (early 80s) being told that one couldn't use TCP/IP in LANs
> because they were WAN protocols. In the late 80s, WAN people were saying
> you couldn't use TCP/IP because they were LAN protocols.
I’m not disputing the above, but there was a lot of focus on making TCP go fast enough for LAN usage in 1981-1984. For example see this 1981 post by Fabry/Joy in the TCP-IP mailing list: https://www.rfc-editor.org/in-notes/museum/tcp-ip-digest/tcp-ip-digest.v1n6…
There are a few other similar messages to the list from around that time.
An early issue was check-summing, with that initially taking 25% of CPU on a VAX750 when TCP was heavily used. Also ideas like having "trailing headers" (so that the data was block aligned) were driven by a search for LAN performance. Timeouts were reduced from 5s and 2s to 0.5s and 0.2s. Using a software interrupt instead of a kernel thread was another thing that made the stack more performant. It always seemed to me that the BBN-CSRG controversy over TCP code spurred both teams ahead with BBN more focussed on WAN use cases and CSRG more on LAN use cases. I would argue that no other contemporary network stack had this dual optimisation, with the possible exception of Datakit.