I've send a couple of you private messages with some more details of why I
ask this, but I'll bring the large question to debate here:
Have POSIX and
LSB lost
their
usefulness/relevance? If so, we know ISV’s like Ansys are not going to go
‘FOSS’ and make their sources available (ignore religious beliefs, it just
is not their business model); how to we get that level of precision to
allow
the part of the
market
that will be 'binary only' continue to
create applications?
Seriously, please try to stay away from religion on this
question. Clearly, there are a large number of ISVs have traditionally
used interface specifications. To me it started with things like the old
Cobol and Fortran standards for the languages. That was not good enough
since the systems diverge, and /usr/group then IEEE/ANSI/ISO did Posix.
Clearly, Posix enabled Unix implementations such a Linux to shine, although
Linux does not doggedly follow it. Apple was once Posix conformant, but
I'd not think they worry to much about it. Linux created LSB, but I see
fewer and fewer references to it.
I worry that without a real binary definition, it's darned hard (at least
in the higher end of the business that I live day-to-day) to get ISV's to
care.
What do you folks think?
Clem
As an aside about Wolfram and SMP (and one that actually has
something to do with UNIX):
I ran the VAX on which Wolfram et al (and it was very much et al)
developed SMP. It started out running UNIX/TS 1.0. I know how
that system was snuck out of Bell Labs, but if I told you I'd have
to terminate you with extreme prejudice. (I wasn't involved
anyway.)
SMP really needed dynamic paging; the TS 1.0 kernel had only
swapping. We had quite a few discussions about what to do.
Moving wholesale to 3BSD or early 4BSD (this was in 1981)
would have been a big upheaval for our entire user community.
Those systems were also notorious at the time for their delicate
stability: some people reported that they ran well, others that
they crashed frequently. Our existing system was pretty solid,
and I had already put some work into making it more so (better
handling of low-level machine errors, for example).
Somehow we ended up deciding that the least-painful path was
to lift the VM code out of 4BSD and shoehorn it into our
existing kernel, creating what we called Bastardized Paging
UNIX. I did most of the work; I was younger and more energetic
back then. Also considerably grumpier. In the heart of the
page-in (I think) code, the Berkeley guys had written a single
C function that stretched to about ten printed pages. (For those
too young to remember printers, that means about 600 lines.)
I was then and still am adamant that that's the wrong way to
write anything, but I didn't want to take the time to rewrite
it all, so (being young and grumpy) I relieved my feelings by
adding a grumpy comment at the top of the source file.
I also wrote a paper about the work, which was published in
(of all places) AUUGN. I haven't read it in years but it was
probably a bit snotty. It nevertheless ended up causing a
local UNIX-systems-software company to head-hunt me (but at
the time I had no interest in leaving Caltech), so it must
not have been too rude.
What days those were, when a single person could understand
enough of the OS to do stuff like that in only a month or two,
and get it pretty much right too. I did end up finding some
interesting race-condition bugs, probably introduced by me, but
fascinating to track down; e.g. something that went wrong only
if a page fault happened at exactly the right time with respect
to something else.
Norman Wilson
Toronto ON
Donald ODana:
already 20 years ago I met a guy (masters degree, university) who never
freed dynamically allocated memory. He told me he is 'instantiating
a object', but had no idea what an heap is, and what dynamically
allocated memory means.
====
This is the sort of programmer for whom garbage collection was named:
his programs are a collection of garbage.
Norman Wilson
Toronto ON
(In 1127-snark mode this evening)
>Date: Sat, 17 Feb 2018 17:47:22 +1100 (EST)
>From: Dave Horsfall <dave(a)horsfall.org>
>To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org>
>Subject: [TUHS] Of birthdays etc
>Message-ID: <alpine.BSF.2.21.1802171649520.798(a)aneurin.horsfall.org>
>Content-Type: text/plain; format=flowed; charset=US-ASCII
>
>...
>Harris' Lament? Look it up with your favourite search engine (I don't use Google).
>
probably early 1995 I dabbled a bit in AltaVista Search. So even now
still using Yahoo somehow :-)
Keep it coming Dave, it's appreciated, at least by me.
>From a former DECcie,
uncle rubl
Blimey... How was I to know that a throw-away remark would almost develop
into a shitfight? It would help if people changed the Subject line too,
as I'm sure that Ken must've been a little peeved... It would also help
if users didn't bloody top-post either, but I suspect that I've lost that
fight.
Anyway, this whole business started when I thought it might be a good idea
to post reminders of historical events here, as I do with some of the
other lists that I infest^W infect^W inhabit. I figured that the old
farts here might like to be reminded of (IMHO) significant events, and
similarly the youngsters might want to be reminded that there was indeed
life before Linux (which, by the way, I happen to loathe, but that's a
different story).
I'm glad that some people appreciate it; and don't worry, Steffen, you'll
soon catch up, as they should all be in the archives :-) A long-term goal
(if I live that long) is to set up one of those "this day in history"
sites, but it looks like Harris' Lament[*] has already applied :-(
I've had a number of corrections (thanks!), some weird comments on
pronunciation (an Englishman can probably pick my ancestry from me saying
"castle" as "c-AH-stle" and "dance" as "d-A-nce" etc), but oddly enough no
criticism (well, unless I'm talking about mounting a magtape as a
filesystem; no, I will not forget the implication that I was a liar), and
Warren has yet to spank me...
For the morbidly curious I keep these events in Calendar on my MacBook
(which actually spends most of its time in Terminal, and I don't even know
how to use the Finder!), and am always noting things which interest me and
therefore possibly others.
Anyway, thanks all; it is an honour and a privilege to share a mailing
list with some of the people who wrote the software that I have both used
in the past and still use to this day.
[*]
Harris' Lament? Look it up with your favourite search engine (I don't use
Google).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> On Feb 14, 2018, Dave Horsfall <dave(a)horsfall.org> wrote:
>
> Computer pioneer Niklaus Wirth was born on this day in 1934; he basically
> designed ALGOL, one of the most influential languages ever, with just
> about every programming language in use today tracing its roots to it.
Wirth designed many languages, including Euler, Algol W, Pascal, Modula, and Oberon, but he did not design Algol; more specifically, he did not design Algol 60. Instead, a committee (J. W. Backus, F. L. Bauer, J. Green, C. Katz, J. McCarthy, P. Naur, A. J. Perlis, H. Rutishauser, K. Samelson, B. Vauquois, J .H. Wegstein, A. van Wijngaarden, and M. Woodger) designed it, and Peter Naur edited the remarkable Algol 60 specification. A few others, including Edsgar Dijkstra, who completed the first implementation, participated in meetings leading up to the final design.
From: Doug McIlroy <doug(a)cs.dartmouth.edu>
> Like PL/I, it also
> borrowed the indispensable notion of structs from business languages
> (Flowmatic, Comtran, Cobol).
That is an interesting insight. I always thought that structs were
inspired by the assembler DORG construct, and hence the shared namespace
for members.
The above insight goes some way to explain why PDP11 “as” did not have
a DORG construct, but early C did have ‘struct'.
Paul
So people have called me on the claim that lisp is not fast. Here's a
rebuttal.
Please write a clone of GNU grep in lisp to demonstrate that the claim
that lisp is slower that C is false.
Best of luck and I'll be super impressed if you can get even remotely
close without dropping into C or assembler. If you do get close, I
will with draw my claim, stand corrected, point future "lisp is slow"
people at the lisp-grep, and buy you dinner and/or drinks.
--lm
> From: Larry McVoy <lm(a)mcvoy.com>
> the proof here is to show up with a pure lisp grep that is fast as the C
> version. ... I've never seen a lisp program that out performed a well
> written C program.
Your exact phrase (which my response was in reply to) was "lisp and
performance is not a thing". You didn't say 'LISP is not just as fast as C' -
a different thing entirely. I disagreed with your original statement, which
seems to mean 'LISP doesn't perform well'.
Quite a few people spent quite a lot of time making LISP compiler output fast,
to the point that it was possible to say "this compiler is also intended to
compete with the S-1 Pascal and FORTRAN compilers for quality of compiled
numeric code" [Brooks,Gabriel and Steele, 1982] and "with the development of
the S-1 Lisp compiler, it once again became feasible to implement Lisp in Lisp
and to expect similar performance to the best hand-tuned,
assembly-language-based Lisp systems" [Steele and Gabriel, 1993].
Noel
> Computer pioneer Niklaus Wirth was born on this day in 1934; he basically
> designed ALGOL, one of the most influential languages ever, with just
> about every programming language in use today tracing its roots to it.
Rather than "tracing its roots to it", I'd say "has some roots in it".
Algol per se hardly made a ripple in the US market, partly due to
politics and habit, but also because it didn't espouse separate
compilation. However, as asserted above, it had a profound impact on
language designers and counts many languages as descendants.
To bring the subject back to Unix, C followed Fortran's modularity and
Algol's block structure. (But it reached back across the definitive Algol
60 to pick up the "for" statement from Algol 58.) Like PL/I, it also
borrowed the indispensable notion of structs from business languages
(Flowmatic, Comtran, Cobol). It adopted pointers from Lisp, as polished
by BCPL (pointer arithmetic) and PL/I (the -> operator). For better or
worse, it went its own way by omitting multidimensional arrays.
So C has many roots. It just isn't fashionable in computer-language
circles to highlight Cobol in your family tree.
Doug
> From: Larry McVoy <lm(a)mcvoy.com>
> I don't know all the details but lisp and performance is not a thing.
This isn't really about Unix, but I hate to see inaccuracies go into
archives...
You might want to read:
http://multicians.org/lcp.html
Of course, when it comes to the speed/efficientcy of the compiled code, much
depends on the program/programmer. If one uses CONS wildly, there will have to
be garbage collection, which is of course not fast. But properly coded to stay
away from expensive constructs, my understanding is that 'lcp' and NCOMPLR
produced pretty amazing object code.
Noel
Actually, Algol 60 did allow functions and procedures as arguments (with correct static scoping), but not as results, so they weren’t “first class” in the Scheme sense. The Algol 60 report (along with its predecessor and successor) is available, among other places, here:
http://www.softwarepreservation.org/projects/ALGOL/standards/
On Feb 16, 2018, Bakul Shah <bakul(a)bitblocks.com> wrote:
> They did lexical scoping "right", no doubt. But back when
> Landin first found that lambda calculus was useful for
> modeling programming languages these concepts were not clearly
> understood. I do not recall reading anything about whether
> Algol designers not allowing full lexical scopin was due to an
> oversight or realizing that efficient implementation of
> functional argument was not possible. May be Algol's call by
> name was deemed sufficient? At any rate Algol's not having
> full lexical scoping does not mean one can simply reject the
> idea of being influenced by it. Often at the start there is
> lots of fumbling before people get it right. May be someone
> should ask Steele?
Clueless or careless?
A customer program worked for many years till one of the transaction
messages had a few bytes added.
Looking into it I discovered that the program had only worked because
the receive buffer was followed by another buffer which was used in a
later sequence. Only when also that buffer overflowed some critical
integers got overwritten and used as index in tables that gave a lot
of fun.
Well, as all here know, C is fun :-)
> From: Larry McVoy <lm(a)mcvoy.com>
I am completely non-LISP person (I think my brain was wired in C before C
existed :-), but...
> Nobody has written a serious operating system
Well, the LISP Machine OS was written entirely in LISP. Dunno if you call that
a 'serious OS', but it was a significantly more capable OS than, say,
DOS. (OK, there was a lot of microcde that did a lot of the low-level stuff,
but...)
> or a serious $BIG_PROJECT in Lisp.
Have you ever seen a set of Symbolics manuals? Sylph-like, it wesn't!
> Not one that has been commercially successful, so far as I know.
It's true that Symbolics _eventually_ crashed, but I think the biggest factor
there was that commodity microprocessors (e.g. Pentium) got faster so much
faster than Symbolics' custom LISP hardware, so that the whole rationale for
Symbolics (custom hardware to run LISP fast) went away. They still exist as a
software company selling their coding environment, FWTW.
> C performs far better even though it is, in the eyes of lisp people, far
> more awkward to do things.
I think it depend on what you're doing. For some kinds of things, LISP is
probably better.
I mean, for most of the kind of things I do, I think C is the bees' knees
(well, except I had to add conditions and condition handlers when I went to
write a compiler in it), but for some of the AI projects I know a little
about, LISP seems (from a distance, admittedly) to be a better match.
Noel
On Feb 15, 2018, Ian Zimmerman <itz(a)very.loosely.org> wrote:
>>
>> So, how's this relevant to Unix? Well, I'd like to know more about the
>> historical interplay between the Unix and Lisp communities. What about
>> the Lisp done at Berkeley on the VAX (Franz Lisp).
>
> I know one of the Franz founders, I'll ask him when I have a chance.
There is some information about Franz Lisp and its origins here:
http://www.softwarepreservation.org/projects/LISP/maclisp_family/#Franz_Lis…
(And lots more information about many other varieties of Lisp at the same web site.)
On Sat, Feb 3, 2018 at 5:59 PM, Dave Horsfall <dave(a)horsfall.org> wrote:
> On Sat, 3 Feb 2018, Arthur Krewat wrote:
>
>> I would imagine that Windows wouldn't be what it is today without UNIX.
>> Matter of fact, Windows NT (which is what Windows has been based on since
>> Windows ME went away) is really DEC's VMS underneath the covers at least to
>> a small extent.
>>
>
> I thought that NT has a POSIX-y kernel, which is why it was so reliable?
> Or was VMS a POSIX-like system? I only used it for a couple of years in
> the early 80s (up to 4.0, I think), and never dug inside it; to me, it was
> just RSX-11/RSTS-11 on steroids.
The design of the original NT kernel was overseen by Dave Cutler, of VMS
and RSX-11M fame, and had a very strong and apparent VMS influence. Some
VAX wizards I know told me that they saw a lot of VMS in NT's design, but
that it probably wasn't as good (different design goals, etc: apparently
Gates wanted DOS++ and a quick time to market; Cutler wanted to do a *real*
OS and they compromised to wind up with VMS--).
It's true that there was (is? I don't know anymore...) a POSIX subsystem,
but that seemed more oriented at being a marketing check in the box for
sales to the US government and DoD (which had "standardized" on POSIX and
made it a requirement when investing in new systems).
Now days, I understand that one can run Linux binaries natively; the
Linux-compatibility subsystem will even `apt-get install` dependencies for
you. Satya Nadella's company isn't your father's Microsoft anymore. VSCode
(their new snazzy editor that apparently all the kids love) is Open Source.
Note that there is some irony in the NT/POSIX thing: the US Government
standardized on Windows about two decades ago and now can't seem to figure
out how to get off of it.
A short story I can't resist telling: a couple of years ago, some folks
tried to recruit me back into the Marine Corps in some kind of technical
capacity. I asked if I'd be doing, you know, technical stuff and was told
that, since I was an officer no, I wouldn't. Not really interested. I ended
up going to a bar with a recon operator (Marine special operations) to get
the straight scoop and talking to a light colonel (that's a Lieutenant
Colonel) on the phone for an hour for the hard sell. Over a beer, the recon
bubba basically said, "It was weird. I went back to the infantry." The
colonel kept asking me why I didn't run Windows: "but it's the most popular
operating system in the world!" Actually, I suspect Linux and BSD in the
guise of iOS/macOS is running on a lot more devices than Windows at this
point. I didn't bother pointing that out to him.
Would VMS become what it was without UNIX's influence? Would UNIX become
>> what it later was without VMS?
>>
>> Would UNIX exist, or even be close to what it became without DEC?
>>
>
> I've oft wondered that, but we have to use a new thread to avoid
> embarrassing Ken :-)
>
The speculation of, "what would have happened?" is interesting, though of
course unanswerable. I suspect that had it not been for Unix, we'd all be
running software that was closer to what you'd find on a mainframe or RT-11.
- Dan C.
> already 20 years ago I met a guy (masters degree, university) who never freed dynamically allocated memory. He told me he is 'instantiating a object', but had no idea what an heap is, and what dynamically allocated memory means.
Years ago, I had an new programmer who I just couldn't teach. He never understood the difference between an array and pointer, and apparently couldn't be bothered to learn.
After string him along for three months, I was on my way into his office to fire him when I found out he had quit, but not before he checked a bunch of drek into our source code control system.
I thought I backed all his commits out at the time.
Years later I was running "purify" on our product looking for memory leaks. I found this small utility function that predated the source code control system leaking. This, I thought was odd, as it had been there FOREVER and was well tested. I brought up the source code system and checked it anyhow and found the afore mentioned programmer had checked in one change: he deleted the "free" call in it.
I KNOW what happened. He did something else to corrupt the malloc heap in his code and often this causes a core dump in a subsequent malloc/free call. Apparently this was the place it struck him, so he just deleted the free call there.
So, in:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s2/mv.c
what's the point of this piece of code:
p = place;
p1 = p;
while(*p++ = *argp3++);
p2 = p;
while(*p++ = *argp4++);
execl("/bin/cp","cp", p1, p2, 0);
I mean, I get that it's copying the two strings pointed to by 'argp3' and
'argp4' into a temporary buffer at 'place', and leaving 'p1' and 'p2' as
pointers to the copies of said strings, but... why is it doing that?
I at first thought that maybe the execl() call was smashing the stack (and
thus the copies pointed to by 'argp3' and 'argp4'), or something, but I don't
think it does that. So why couldn't the code have just been:
execl("/bin/cp","cp", argp3, argp4, 0);
Is this code maybe just a left-over from some previous variant?
Noel
> From: Dave Horsfall <dave(a)horsfall.org>
> I'd like to see it handle "JSR PC,@(SP)+"...
Heh!
But that does point out that the general concept is kind of confused - at
least, if you hope to get a fully working program out the far end. The only
way to do that is build (effectively) a simulator, one that _exactly_
re-creates the effects on the memory and registers of the original program.
Only instead of reading binary machine code, this one's going to read in the
machine language source, and produce a custom simulator, one that can run only
one program - the one fed into it.
Think of it as a 'simulator compiler'! :-)
Noel
>> I was wondering what it would take to convert the v6/v7 basic program
>> into something that can be run today.
>
> Hmmm... If it were C-generated then it would be (somewhat) easy, but it's
> hand-written and hand-optimised... You'd have to do some functional
> analysis on it e.g. what does this routine do, etc.
>
>> Its 2128 lines. It doesn't have that fun instruction in it :)
>
> I know! Say ~2,000 lines, say ~100 people on this list, distributed
> computing to the rescue! That's only 20 lines each, so it ought to be a
> piece of cake :-)
I'm up for that! However, only if the resulting C program can be compiled/run
on a V6/PDP11 again.
Let's assume that reverse engineering a subroutine of 20 lines takes
an hour. That then makes for 100 hours. If 10 people participate and
contribute one hour/routine per week, it will be done by May.
However, the initial analysis of the code architecture is a (time) hurdle.
Paul
PS: the Fortran66 of V6 is also assembler only...
IMO:
1) It kinda did catch on, in the form of macOS, but there was a time
when it was nearly dead as the major vendors moved to System V. For
some reason, Sun was the last major vendor to make the move, but they
caught most of the flack.
2) I think the main reason BSD nearly died, was the AT&T lawsuit. At
the time, Linux appeared to be a safer bet legally.
3) Linux got a reputation as an OS you had to be an expert to install,
so lots of people started it to install it to "prove themselves".
This was sort of true back when Linux came as 2 floppy images, but
didn't remain true for very long.
4) I believe the SCO lawsuit "against Linux" was too little, too late
to kill Linux's first mover advantage in the opensource *ix
department.
5) I think FreeBSD's ports and similar huge-source-tree approaches
didn't work out as well Linux developers contributing their changes
upstream.
Hi all,
Would anyone here be able to help me troubleshoot my qd32 controller? I
have a pdp11/73 that's mostly working, boots 2.11 from rl02 okay, but I
need my big disk to work so I can load the rest of the distro.
I've been following the manual for the qd32 to enter the geometry of my
real working m2333 (jumpered correctly according to the manuals), but when
I load the special command into the qd32's SP register that's supposed to
load the geometry table from the pdp11 memory to the novram, I get a bad
status value from the qd32's SP register and it remains unresponsive when I
try to store the geometry. If I go ahead and try the built-in qd32 format
command, it responds similarly. When I pull in mkfs from tape (vtserver)
and try anyway, despite the failures, to run mkfs on the m2333, I get an
!online error from the standalone unix mkfs. The disk does respond (the
select light flashes and I can hear heads actuating), but without geometry
and format, I'm obviously dead in the water.
Any suggestions on how to proceed?
thx
jake
> Why is it that umount(2) took the device special file name rather than the mount point directory name, anyway?
Symmetry. You unmount what you mount.
A competing model is that of links. Link makes an old file available
under a new name. But you unlink by the new name. Necessarily so,
because there may be many new names for one old file.
This is reminiscent of Don Norman's screed about the unnaturalness
of Unix. He didn't like strcpy because the arguments come in the
opposite order to those of cp. But stcpy is part of C, and in
C the destination of assignment comes before the source. But Norman
didn't rail at C. You pays your money and takes your choice.
Doug
these were in by the time I can along but I was wondering when they got it.
They've also always felt a bit like a thing that did not fit to me. I'm
pretty sure I was not alone, given that the Unix authors worked out a way
to get rid of them in later efforts. I know what came after, in Plan 9;
what came before, in Unix, that led to special files?
We lost computer pioneer John von Neumann on this day in 1957; the "von
Neumann" architecture (stored program etc) is the basis of all modern
computers, and he almost certainly borrowed it from Charles Babbage.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> From: Greg Lehey
>> V3 and earlier still *called* them special files, but it seems they
>> were essentially just magic inode numbers (there was no physical file
>> on disk, just any directory entry with the given inode would be the
>> special file).
> Isn't that still the case?
>From reading the manual page (URL sent earlier), in V3 and before it really
was just an inode _number_ (less than 50, IIRC). The first inode, in the
first disk block after the super-block, was inode #51. This is of course
different from later Versions, where there is an _inode_ for devices, but
still no actual _file_.
Noel
Co-inventor of Unix, he was born on this day in 1943. Just think: without
those two, we'd all be running M$ Windoze and thinking that it's
wonderful (I know, it's an exaggeration, but think about it).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> My experience is that the problems involved in making a program faster are
> often quite interesting and fun to work on. But the problems making things
> fit in a small space are, IMHO, really deadly.
First make things "as simple as possible, but no simpler" (Einstein). Ken and
Dennis not only cut out fat, they also found generalizations that combined
traditionally disparate features, so the new whole was smaller (and more
comprehensible) than the sum of the old parts. The going gets tough in the
presence of constraints on space or time. Steve's perception, I think, is
colored by the experience of facing hard limits on space, but not on time.
Describing one complication of hard time constraints, John Kelly used to
say that the Packard Bell 250 was "the only machine I ever used where
you transfer to a time of day rather than a memory location". (The delay-
line memory had two instruction formats: one was operation + address-of-
next-instruction, the other was just the operation--the next instruction
being whatever came out of the delay line when the operation ended. The
latter mode minimized both execution time and code space, but the attention
one had to pay to time was, to borrow Steve's phrase, "really deadly".)
Design tradeoffs for efficiency pose an almost moral conundrum:
whether to make things fast or make them easy. For example, the
classic Unix kernel typically did table lookup by linear search,
whereas Linux (when I last looked) typically used binary search.
The price of Linux's choice is that one must take care to keep
the tables sorted. Heavy discipline has to be imposed on making
entries and deletions.
Doug
What do you mean plan9 is dead? It's even possible make a facebook post
from inside plan9 nowadays!
https://twitter.com/bigatojj/status/949838932841201664
See vmx(1)
Em 3 de fev de 2018 23:25, "Steve Simon" <steve(a)quintile.net> escreveu:
Hi,
I have to take issue with the “plan9 is dead” statement,
I agree it seems on a downward spiral, but are a few who fight on.
[sent from my plan9]
-Steve
You can use make as much as you like; Go just doesn't need it. You can use
Go to fetch code from internet if you like, or you can do it yourself if
you prefer.
Regarding the "hardwired" directories, you can change it through an
environment variable.
Em 3 de fev de 2018 23:20, "Lyndon Nerenberg" <lyndon(a)orthanc.ca> escreveu:
That's the second endorsement I've seen for Go; I guess I should learn it.
>
In the scheme of "current" languages, Go is pretty good. With two major
caveats, IMO:
1) The build system. It doesn't work with make(1). That makes it a
non-starter for anything other than trivial projects at $WORK. While I
appreciate the arguments for the apparent simplicity of the "go" command,
that doesn't work for us. Which would have been fine, but for the entirely
antagonistic bent they have taken against being able to build Go programs
with make(1). Our build environment entirely precludes Go's promiscuous
insistence on unfettered internet access, and hardwired directory paths.
2) Hardwired directory paths for the development/build environment (see
above).
It seems they have unlearned all the UNIX lessons. Sad, really. I would
love to toss out Python, Ruby, PHP, Perl, et al. And could make the
argument for it, I think. But the build environment will never work in our
shop, therefore Go won't either.
And that ... sucks.
Hi,
Interested in some perspective here since the list has influential Linux
people like Ted Tso.
Linux has been described as influenced by Minix and System V. The Minix
connection is well discussed. The SysV connection something something
Linus had access to a spec manual. But I’d guess reality would be more
gradual — new contributors that liked CSRG BSD would have mostly gravitated
to the continuations in 386/BSDi/Net/Free that were concurrent to early and
formative Linux development.. so there’d be an implicit vacuum of BSD
people for Linux development.
What I am curious about is the continuing ignorance of BSD ideas. Linux
isn’t exactly insular; a lot of critical people and components came much
later on from other SysV flavors (lvm, jfs, xfs, RCU)
The kinds of BSD things I am talking about are ufs, kqueue, jails, pf,
Capsicum. Linux has grown alternatives, but with sometimes willful
ignorance of other technology. It seems clear epoll was not a good design
from the start. Despite jails not being taken to the logical conclusion of
modern containers like zones, the architecture is fundamentally closer
aligned to how people want to securely use containers versus namespaces and
cgroups. And Google ported Capscicum to Linux but it’s basically been
ignored in lieu of nebulous concepts like seccomp. And then there seems to
be outright hostility toward other platforms from the postmodern generation
with things like systemd.
This seems strange to me as BSD people are generally open to other /ideas/,
we have to be careful with Linux code due to license incompatibility, but
the converse is does not seem true either in interest in other ideas or
license hampering code flow.
The history of UNIX is spectacularly successful because different groups
got together at the table and agreeed on the ideas. Is there room for that
in the modern era where Linux is the monopoly OS? The Austin Group is
still a thing but it’s not clear people in any of the Freenix communities
really care about evolving the standards. I get that, but not so much
completely burrying ones head in the sand to what other OSes are doing. Is
there any future for UNIX as an “open system” in this climate or are people
going to go there separate ways?
Regards,
Kevin
We gained John von Neumann on this day in 1903, and if you haven't heard
of him then you are barely human... As computer science goes, he's right
up there with Alan Turing. There is speculation that he knew of Babbage's
work; see
https://cstheory.stackexchange.com/questions/10828/the-relation-between-bab… .
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> From: Sergio Pedraja
> I am very interested in your work exactly for the reasons you explain
We will generally be sending messages about it to the CCTalk list (for
collectors of 'classic' computers), so if you want to be notified about it,
sign up there.
We currently have only wire-wrap prototypes (the FPGA is on an off-the-shelf
daughter-card); we're hoping to produce PCB production versions 'soon'. We do
have the technology for getting PCB's, which we have used for doing 'indicator
panels':
http://ana-3.lcs.mit.edu/~jnc/tech/DECIndicatorPanels.html
We have those working (they've been a big help in debugging, actually :-), and
they'll be available too. I don't personally have one of them yet, I'm
_really_ looking forward to watching the lights blink as UNIX boots... :-)
> The only difference is that my PDP-11 is one 23/PLUS. There are some
> differences between this one and the PDP-11/23 and perhaps your emulator
> woudln't work in this PDP-11 model.
No, AFAIK the /23 and /23-PLUS are effectively identical, as far as the QBUS
goes. (Obviously the -PLUS has devices, etc, the plain /23 doesn't, but they
don't enter into whether our board will work with one.)
We also plan at UNIBUS version; the two busses are similar enough that we'll
probably start with a PCB version for that one.
> I will test the working state of my PDP. If all is fine perhaps I could
> help doing with some tests on it.
Sure; use CCTalk.
Noel
As I mentioned recently, Dave Bridgham and I are doing an RK11 emulator (and
soon an RP11, which just will take editing the Verilog a tiny bit) using an
SD card for storage, for heritage computer collectors who want to run their
PDP-11's but don't want to risk a head crash (since replacement heads are now
un-obtainium) - and also for people who have an -11, but no mass storage.
So the last stage was bringing up V6 on a hardware PDP-11/23, using the
emulated RK11, and we were having an issue (which turned out to be partial
block reads/writes not working properly; this has since been fixed, and we
have successfullly booted V6 on the -11/23 with only an SD card).
In the process of debugging that issue, I added logging to the RK driver, and
noticed that in the process of attempting to boot single-user, the system was
trying to do some swapping - two writes, and two reads - before it even tried
doing the fork() to create the shell process, followed by opening /dev/tty8
and doing the exec() of /bin/sh.
This confused me, since both newproc() and expand() have code which uses a
memory-memory copy if there is enough free memory - and on first booting,
there definitely was. Why was it swapping?
So I added some more logging, and the cause turned out that at one point, I
had re-compiled /etc/init - and without thinking about it too hard, had made
it a pure-text program.
And that's what did it: in exec() (called when process 1 tries to exec()
/etc/init), it calls xalloc(), which i) if the text was not already
available, gets together the pure text, and puts a copy on the swap device,
and ii) if the text is not already in core, swaps the rest of the process
out, because, as the code explains:
* if the calling process
* is misplaced in core the text image might not fit.
* Quite possibly the code after "out:" could check to
* see if the text does fit and simply swap it in.
If you're looking at the code, the process doesn't have a data segment at
that point, just the U area; the data will be set up later in the exec()
code, after the call to xalloc() returns, after the process is swapped back
in.
In fact, the process will _never_ have anything other than a U area when in
this code; the only call to xalloc() in the system is immediately preceeded
by an "expand(USIZE)" which throws away everything except the U area.
So I'm contemplating doing what the comment suggests - adding code to check
to see if there's enough memory available to hold the pure text, and if so,
avoiding the swap-out/in of the process' U-only data segment.
If done 'right', it should also be possible to allow avoiding the reading-in
of the text from the swap device, when first exec'ing a pure text...
Probably not as interesting a project as doing the splice() system call was,
but no doubt it will teach me about a corner of the system I don't know very
well (back in the day, doing networking stuff, I was mostly looking at I/O
code).
Although there is potentially a certain amount of amusement in an additional
enhancement, which is trying to make sure there's enough room for both the
text and the data; immediately upon the return from xalloc(), the process is
expanded to have room for the data. Which might involve _another_ swap-out/in
sequence... So perhaps the U area should simply be moved out of the way via a
direct memory-memory copy, rather than swapping it out/in, just before doing
it again!
You are not expected to understand this... :-)
I guess I should first take a look at the PWB1 pure text code, which is
heavily modified from the stock V6, to see what it does - this all may have
already been done there.
Noel
For a while I had been wondering about the origins of a modification to the V6 kernel that places the kernel buffers in a separately mapped area, freeing up space for other things. It is used in some of the early networking code, i.e. both the UoI code and the V6 BBN code (as available on the TUHS Unix Tree).
I came across the following reference in https://www.osti.gov/scitech/servlets/purl/12130675:
“One widely distributed (though undocumented) solution to this hardware limit on the model 40 was a version of Unix by Robert Sidebotham, Faculty of Environmental Design, University of Calgary. His solution was to move the I/O buffers out of kernel space.”
This would explain the modifications being bracketed with "#ifdef UCBUFMOD”.
Some questions for the old hands:
- Was this patch indeed widely known / distributed?
- Widely distributed is not the same as widely used: was it?
Born on this day in 1925, he was a pioneer in human/computer interaction,
and invented the mouse; it wasn't exactly ergonomic, being just a square
box with a button.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
So, while bringing up V6 on a hardware PDP-11/23 with an RK11 emulator using
an SD card for storage which Dave Bridgham and I are doing, I found this piece
of code in main() on V6 Unix:
rootdir = iget(rootdev, ROOTINO);
rootdir->i_flag =& ~ILOCK;
u.u_cdir = iget(rootdev, ROOTINO);
u.u_cdir->i_flag =& ~ILOCK;
I don't get why two separate calls to iget(), with the same arguments;
why not replace the second pair of lines with:
u.u_cdir = rootdir;
rootdir->i_count++;
What am I missing?
Noel
>>> LSX has a maximum of three processes that are swapped in and out in a
>>> stack-like fashion. Only one process is ever in core.
>
> I'm having a hard time working out how this works. If process A is swapped
> out, and then B, B has to be swapped in before A can be? But only one process
> is ever in core at a time? To get A in, B has to be moved out? But then B
> would be the last one out, and would have to come in before A?
>
> Anyway, I don't understand why the OS could/would care which order processes
> we swapped in - unless it's something like the 'onion skin' memory allocation
> algorithm of CTSS (which also had only a single process resident at a time,
> IIRC), where, when a small process had to be swapped in, and a large one was
> already in, it only swapped out enough of the large one to make room for the
> small one. The process could recurse, hence the name.
The LSI-11 had 40KB of core. The lower 16KB held the LSX kernel, the upper 24K was
for the active process.
LSX has 3 process slots and 2 swap slots (on floppy!). Optionally, LSX could
be built with an additional background process ("BGOPTION"), but this does
not work very well. Process numbers and swap slots have a 1:1 relationship.
There is a global variable, cpid, with the process number of the current
process, initially zero. Upon boot, LSX will load a shell as process 0.
(There is no swapper process and no init in LSX).
The original LSI-11 kernel code is here:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=LSX/sys
I can refer to source lines in the repository for my TI990 port of it:
https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b6ec9496e23efe8c
When a process forks, it writes the current core image out to the
corresponding swap slot (this swaps out the parent) and the core image
is repurposed as the new process (i.e. cpid is incremented and the
proc table filled in):
https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/3617ec3245c40a69?l…
The child now runs and the parent remains suspended until the child completes.
Yes, this implies no pipes. The shell is modified to emulate pipes with files.
When the child completes, it stores its u area / exit code in its swap slot
(as it is running, the swap slot must be empty. Process 3 has a small swap slot
just for this). Next LSX decreases cpid and the parent process is reloaded from
its swap slot:
https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b9c07dfc5add9fc5?l…
The actual swapping happens here:
https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b6ec9496e23efe8c?l…
The original PDP11 source has code to compress the empty space between _end and the
stack pointer, which I did not get to work properly.
LSX works well enough to run the standard V6 binaries unmodified. Some need to be
tweaked (e.g. table space in cpp) and the shell needed the pipe change. It can run
the V6 c compiler, but not with a wild card argument: that requires 4 stacked processes
(sh, glob, cc and cpp/c0/..) and LSX allows only 3.
Hope the above makes it a bit more clear.
We lost AI pioneer Marvin Minsky on this day in 2016 from a cerebral
haemorrhage, aged 88. Amongst other things, along with John McCarthy he
co-founded the MIT AI Lab, co-invented the Logo "turtle", was mentioned in
Arthur C. Clarke's novel "2001: A Space Odyssey", and built the first
randomly wired neural network learning machine, SNARC, in 1951.
He is now thought to be cryogenically preserved as "Patient 144" at Alcor
(he started cooling on 27/1/2016).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> From: Doug McIlroy
>> From: Paul Ruizendaal
>> LSX has a maximum of three processes that are swapped in and out in a
>> stack-like fashion. Only one process is ever in core.
I'm having a hard time working out how this works. If process A is swapped
out, and then B, B has to be swapped in before A can be? But only one process
is ever in core at a time? To get A in, B has to be moved out? But then B
would be the last one out, and would have to come in before A?
Anyway, I don't understand why the OS could/would care which order processes
we swapped in - unless it's something like the 'onion skin' memory allocation
algorithm of CTSS (which also had only a single process resident at a time,
IIRC), where, when a small process had to be swapped in, and a large one was
already in, it only swapped out enough of the large one to make room for the
small one. The process could recurse, hence the name.
> V1 was a time-sharing system; for which LIFO swapping is
> inappropriate.
And I don't follow that either...
V1 ran on the 11/20 without memory management hardware, though, right?
(Although there's that cryptic reference to the KS11 in "Odd Comments and
Strange Doings in Unix", although I've never been able to find out anything
else about the KS11.) So presumably one would not have wanted more than one
process resident at a time, as that decreases the odds of a buggy program
trashing another process?
Noel
Hi
I've just had an interesting experience, explaining C header files to
a nephew programmer who didn't understand them. I pointed him in the
direction of Minix as an example of a small well-engineered system
which would display their use.
Which raised the question: when did header files come into use? Who
was the first to use header files to store common system-wide or
application-wide data definitions? Was it used in any languages prior
to C?
Thanks
Wesley Parish
Hi.
Can a modern BSD guru please contact me off-list? I have a set of related
tests in the gawk test suite that consistently fail on just about every
*BSD system. It has me stumped, and I'd like to see these tests working
if possible.
(They've been not working for quite a while. That I get no complaints
from BSD users tells me that gawk isn't popular in that world, but that's
another story. :-)
Thanks,
Arnold
Re: [TUHS] Kernel Sizes
> I've often thought that LSX was V5 'regressed' to the concepts of
> V1, which was facing similar hardware constraints. Is that a
> reasonable view?
> LSX has a maximum of three processes that are swapped
> in and out in a stack-like fashion. Only one process is ever in core.
> Is that how V1 was organized?
The rocess limit was higher in V1. And V1 was a time-sharing
system; for which LIFO swapping is inappropriate. So LSX
seems to have "regressed" to some pre-Unix state.
doug
16K kernels?
Well, I came late to the UNIX world. I only remember getting a SCO
UNIX 3.2V4.2 kernel onto a single 3-1/2" diskette and still have all I
wanted including (with scripts on a second diskette of course :-) ).
That was 25 years ago.
Mind you, from there I moved to Digital UNIX /vmunix 9,613.712, Tru64
17.930.976 to HP-UX 11iv2 66.161.464 and HP-UX 11iv3 127.929.032
Of course, I also got lots more functionality I'm supposed to want and need :-)
Cheers,
rudi
For a presentation I'm doing this summer on FreeBSD, I thought it would be
cool to get the kernel sizes for various old flavors of Unix. I see numbers
for v5, v6 and v7 in the tuhs tree view, and it appears these versions are
complete enough for me to extract the kernels themselves. However, I see
nothing prior to that. The archives seem to be somewhat incomplete, but I'm
wondering if people have sizes for earlier versions. Later versions are
more problematic because they move to new hardware, instruction sets, etc.
For this graph to be meaningful, it would need to be pdp-11 only, though
I'm of the opinion more data is better than less. I'll also be extracting
the different V7 commercial kernels: V7M, Ultrix and Venix and the BSD 2.x
releases, but those appear to be intact enough in the archives to extract
data on my own. I've heard rumors there's a SysV for the pdp-11, but I've
not been able to locate images for that. I don't need the actual images,
just sizes with some reference for the source of the data. It's just for
one slide in the talk, so I don't want to burn a ton of time on it...
The larger picture is that I've written what's effectively modprobe for
FreeBSD and will be talking about it in detail. How it's like modprobe, how
it's different, how all the pieces fit together, history of similar
efforts, etc. Part of the driving force here is the bloated FreeBSD GENERIC
kernel.
Of course, I'll share the final report I'm planning on sizes with the group.
Thanks for any data you can provide.
Warner
> A self-imposed limit of 16K held in v1, and was quite fully utilized.
> When the iernel was rewritten in C, the limit (perhaps larger by then)
> influenced the C compiler. More than one optimization was stimulated
> by the need to keep the kernel in bounds.
>
> Doug
The LSX kernel was kept within a self-imposed limit of 16KB as well.
I've often thought that LSX was V5 'regressed' to the concepts of
V1, which was facing similar hardware constraints. Is that a
reasonable view?
For example, LSX has a maximum of three processes that are swapped
in and out in a stack-like fashion. Only one process is ever in core.
Is that how V1 was organized?
I realize that LSX was API compatible with V5/V6 and I don't mean
'regressed' in that sense.
Paul
> I seem to remember that at some point early on, we spent some of our
> capital budget on buying another 16K bytes for the PDP-11. As I
> recall, the deal was that the OS got 8K and users got 8K. I also
> recall that that purchase was 20% of our capital budget for the
> year...
> Doug, did I remember this correctly?
> Steve
Things did happen that way. I don't specifically remember the
numbers, but those you state have the ring of truth.
Memory came in (expensive) 4K increments. When the keepers of
Unix in the Charlotte wire center wanted to add 4K, their
management consented only on the condition that the wizards
in Research would confirm that roposed new functionality
really required it.
doug
A self-imposed limit of 16K held in v1, and was quite fully utilized.
When the iernel was rewritten in C, the limit (perhaps larger by then)
influenced the C compiler. More than one optimization was stimulated
by the need to keep the kernel in bounds.
Doug
Sorry for the off topic post.
I'm hoping that someone here might have seen a (what I consider to be) a
computer lore type story about a contractor that was brought in part way
through a project to consolidate three DCs into one. - In the end he
managed to do it early and under budget. The kicker is that they quite
literally physically moved and re-connected everything the way that it
was. Meaning that there were still WAN circuits (local only of course)
between equipment that was previously in different DCs.
I would like to find a copy of this story and save it in my archive. But
I've not been able to do so. Thus I'm asking a wider audience to see if
anyone might be able to give me a pointer.
--
Grant. . . .
unix || die
We lost Ed Yourdon on this day in 2016; a computer pioneer, he helped to
design the underpinnings of relational databases, and pretty much wrote
the book.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Dr. Prof. John Lions was born on this day in 1937; I had the pleasure of
having him as one of my Computer Science lecturers in the early 70s, and
he drilled into us the Principle of Least Astonishment (or POLA), better
known as "why the fsck did it do that?" (but he was far too genteel to
express it that way). And yes, that's my name in the credits; I helped
with the proof-reading and provided the use of the high-quality printer in
the CSU.
You are not expected to understand this.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Scot Hacker has re-published his BeOS columns for Byte. BeOS was an interesting operating system with a clear Unix inheritance built for a dual-PowerPC system, similar to the Macs of that era.
http://birdhouse.org/beos/byte/
Its inheritance can be found in Haiku (https://www.haiku-os.org)
Arrigo
All,
While it's fresh, I thought I'd share some resources I've found helpful
in learning about the venerable v6 as a relative newb...
Learning Unix V6 in the modern era is an interesting and enormously
educational experience. In the process of using it I have had to learn
how to host it in a simulator (SimH in my case, but there are others),
install it, communicate with it, configure it, build special files for
it, attach devices to it, communicate with the devices attached to it
and to SimH, build a kernel, install the kernel, boot the kernel, work
with a variety of media intended to work with it, extend it, and so on.
In addition, I have had to learn a bit about the PDP-11 (as arguably the
most convenient architecture for learning about V6), about its
architecture, its instruction set, its devices, its memory structure,
and so on.
None of this exploration would have been possible without the excellent
work of Bob Supnik, Mark Pizzolato, and co. on the SimH pdp-11
simulator, the Simh mailing list, Warren Toomey and TUHS for making the
bits available, the TUHS mailing list, PUPS, Bitsavers, and a slew of
readily available documentation and texts including these notables:
Setting Up Unix 6th Edition from the V6 Programmer's Manual
The Unix V6 Programmer's Manual in its entirety
The SimH and SimH PDP-11 Manuals
A large number of blogs with SimH specific V6 installation logs
The V6 Source Code and man pages (don't forget to install man - the 1bsd
version works, and is superior)!
The DEC PDP-11/05-10-35-40 1973 Handbook (the 11/40 handbook is not as
detailed with respect to memory management)
Lions's Commentary on the Sixth Edition source code
Now that I'm over the beginner's hump, so to speak, I'm exploring things
differently and I thought I'd share some resources that I am currently
finding useful and interesting in my explorations...
To bone up on assembly language, Lions's commentary is exceptionally
helpful in explaining assembly as it is implemented in V6. The manual
itself is really thin, and the source is a bit cryptic, for the
newcomer. Lions explains the idioms used in the main source of V6.
However, without a background in assembly language, Lions is pretty
meaningless, so I went looking for something that was PDP specific that
would bridge the gap and help me understand Lions's words. I found a
number of texts that were really good. Most require a working RT11
instance to actually try out the coding examples and do the exercises
(SimH and Bitsavers to the rescue):
Arthur Gill - Machine and Assembly Language Programming of the Pdp-11
Charles A. Kapps and Robert L. Stafford - Assembly Language for the PDP-11
Glenn H. MacEwan - Introduction to Computer Systems: Using the PDP-11
and Pascal
James F. Peters - The Digital Way: Macro-11 Assembler Programming (PDP-11)
Michael G. Schneider - The Principles of Computer Organization: With
Assembly Language Programming for the PDP-11
PDP-11 Processor Handbook (pretty much any edition)
Thomas A. Frank - Introduction to the PDP-11 and its Assembly Language
All of these are useable with a running RT11 instance. But, I think the
Peters and Frank books are the standouts. Peters because all of the
exercises that I have tried (dozens) have worked as printed and Frank
because he is rigorous in his treatment of the subject and builds up
from digital logic all the way through program execution. Frank is an
excellent complement to Lions work because he explains the details that
Lions assumes.
To learn about digital logic, and a special thanks to Warren for his
work on Crazy Small CPU, I have been introduced to logisim. It is a
great playground for exploring digital logic. I had no idea that a
sketchpad for digital logic simulation was available and accessible to
the layperson. Logisim development stopped around 2014 and while there
are a number of successors out there, I am using logisim-evolution:
https://github.com/reds-heig/logisim-evolution
The rabbit trails never seem to end... in order to learn how to use
logisim, I went through the excellent tutorial and then went looking for
a book of experiments in digital logic and found:
digital computer lab workbook from 1969
http://bitsavers.trailing-edge.com/pdf/dec/handbooks/Digital_Computer_Lab_W…
digital equipment corporation computer lab teacher's guide from 1968
http://www.so-much-stuff.com/pdp8/pdf/ComputerLabTeachersGuide.pdf
These two are useable with very little modification as a source of
digital logic exercises that work great with logisim and are related to
the architectural lineage of the PDP-11.
These resources fit together nicely in my pursuit to better understand
digital logic, the pdp-11, assembly language, and unix v6. In sum:
Source code for v6 for what really is supposed to happen in v6 operation
Lions for understanding Unix V6 sources and for unix assembly language
information
PDP-11 Hanbook for quick reference on PDP-11 assembly language
instruction set
Frank for assembly language details and for details on digital logic and
its relationship to the PDP-11 architecture.
Logisim to test logic constructs
The digital lab workbook for practice with digital logic
Later,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
Hi all, Happy New Year. As it's now only eighteen months to the Unix 50th
Anniversary, I thought I'd poll you all to get an update of what is being
done to celebrate the anniversary, and/or what could we organise that has
not yet been organised.
Cheers, Warren
Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a
computer pioneer (one of the greats) he gave us things like the quicksort
algorithm and ALGOLW (a neat language).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Computer pioneer Donald Knuth was born on this day in 1938; amongst other
things he gave us the TeX typesetting language, and he's still working on
"The Art Of Computer Programming" fascicles (I only got as far as the
first two volumes).
I really must have a look at his new MMIX, too; I love learning new
programming languages (I've used about 50 the last time I looked, and I'm
happy to post a list for my coterie of disbelievers).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> I will be happy to forward pertinent suggestions.
Here's one. If Bell Labs holds some kind of symposium on
the lines of the dmr memorial, how about a plenary
session with TV participation from remote venues (think
Berkeley/Silicon Valley and Wollongong/Sydney--a nine-hour
span of time zones).
Any thoughts about this or other possibilities?
Doug
I don't think I'm violating anyone's confidentiality by revealing that
Marcus Weldon, current president of the Labs, at the suggestion of
Martin Carroll, expects the Labs to embark soon on plans to mark
the occasion. I, and no doubt Martin, will keep you posted. Meanwhile
I will be happy to forward pertinent suggestions.
Doug
We lost a co-inventor of ENIAC, John Mauchly, on this day (that's 8th
January like my headers say) in 1980. ENIAC is claimed to be the "first
general purpose electronic digital computer", but I guess it comes down to
a matter of definition[*], as every culture likes to be the "first" (just
ask the Penguins, for example); for "computer" you could go all the way
back to the Mk-I Antikythera (Hellenic variation, from about the 100BC
production run)...
[*]
Analogue/digital/hybrid
Mechanical/electrical/electronic/hybrid
General/special
Wired/programmable/Turing
Prototype/production
Harvard/Neumann/quantum
Etc...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> From: Andy Kosela
> it appears this is a fundamental Intel bug that exists in all x86_64
> CPUs.
I'm highly amused by the irony. Intel throws bazillions of transistors at
these hyper-complex CPUs in an attempt to make them as fast as possible - and
(probably because of the complexity) missed a bug, the fix for which
involves... slowing things way down!
I wonder how many other bugs are lurking in these hyper-complex designs?
Didn't anyone at Intel stop to think that complexity is bad, in and of itself?
But I guess the market demands for faster and faster machines outweighed that
- until it bit them in the posterior. The real question is 'how many more times
will it have to happen before they get a clue'?
There's an interesting parallel between this, and uSloth's struggle with
security and bugs. For a long time, it seemed it was more important to the
market to add features (i.e. complexity), and security be damned - until poor
security really started to become an issue.
So now they're trying to catch up - but seemingly still haven't got there, in
terms of the fundamental architecture of the OS, as the never-ending stream of
bug patches attests.
The sad thing is that how to provide good security (not perfect, but much,
much better than what we have) was worked out a long time ago, and Intel hired
Roger Schell to add the necessary hardware underpinnings when they did the
386:
http://conservancy.umn.edu/bitstream/11299/133439/1/oh405rrs.pdf
Mutatis mutandis.
Noel
Clem Cole:
IIRC this is part of the argument Dykstra made with the THE paper years
ago, Parnas in his information hiding paper -- i.e. why microkernels and
proper layering are a good idea. Keep is simple and do one thing
well/protect yourself against other subsystems not being 100%.
=====
Indeed. Complexity creates needless RISC, er, risk.
Norman Wilson
Toronto ON
http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
Including here as it concerns Unix kernel and leaking memory from kernel
space to userland.
This is big -- it appears this is a fundamental Intel bug that exists in
all x86_64 CPUs.
It will be interesting to watch the ramifications and impact of this on the
industry as a whole.
--Andy
> A lingering gripe that explains my latent anti-Americanism goes back to
> when I had to support Uniplus 2.2/2.4 (sorta SysIII-ish) on the WICAT boxes
> in here in Australia. At installation time, we had to express the time
> offset as hours *west* of GMT; this left me with a lingering belief that
> Americans didn't want to be perceived as being backwards (yeah. it saved an
> entire keystroke out of the dozens that were otherwise required).
But east postive is an artifact of north up. I remember Australian
souvenir shops selling maps on "MacQuarrie's corrective projection",
in which south is up. In fact this orientation was not uncommon in
Europe between medieval maps that really were oriented, with east up,
and later convention that put north up and shoved Australia down under.
Surely an Aussie would prefer south up and west positive!
Doug
On Sun, Dec 31, 2017 at 7:15 PM, Dave Horsfall <dave(a)horsfall.org> wrote:
>
> A lingering gripe that explains my latent anti-Americanism goes back to
> when I had to support Uniplus 2.2/2.4 (sorta SysIII-ish) on the WICAT boxes
> in here in Australia. At installation time, we had to express the time
> offset as hours *west* of GMT; this left me with a lingering belief that
> Americans didn't want to be perceived as being backwards (yeah. it saved an
> entire keystroke out of the dozens that were otherwise required).
Dave I'm not so sure it's about being perceived as forward or backwards -
its just shallow, provincial and often lazy because the program did not
really knowing any better. The problem is too many American',
(particularly younger ones that experience our 'excellent' educational
system), have often never travelled that much and experiences other places,
cultures or social norms.
I admit this is extreme example, but about 8 years ago, my daughter had a
friend, who was approx 16 at the time, that we took to the big city
(Boston) to play in a orchestra concert at Symphony Hall when they both
were named 'All State' for the instruments. I don't remember why said
friends family did not/could not come - but it made sense and we said we
would take her with us. On the drive in-town, we were talking with her and
I discovered that she had never gone to Boston before ... ever -- she was
excited to see it (we live less than 1hr North mind you. Note quite the
boon-docks). She had not gone to a 'Bo Sox' game or anything. Never went
to the Science Museum, etc. She grew up in her town (mind you happy) and
using TV as her window to world.
Which brings me to >>my complaint<<. We, as American's, project so much
about 'us' via TV. The said truth is most Americans are not like what they
see on TV [e.g. Rice-A-Roni is made up!!, Benihana's is an American
invention, and "the big yellow school bus" is dirty/noisy and usually
without seat belts]. Sadly, many Americans do not know any better - queue
the famous quote about never under-estimating the taste of the American
public. But think about what folks outside the US see and think? Many of
my European friends in particular all want to visit NYC. [I tell them all,
visit Boston or Philadelphia first if you can. Those cities are much more
representative of America then LA, NYC or Dallas; if for no other reason
they are more 'European' in feel].
When I run into things like what you just described (and I seem to run into
then most often with MicroSoft based tools), I think to myself, it must
have been a cold day in Redmond, WA and some programmer did not want to
make an effort to do make her/his solution really general ;-)
Clem
FWIW: Not only did we take my kids all over the world as children, we
brought the world to them by sponsoring kids from all sorts of countries.
But I fear, my wife and I are less the norm then I would wish.
ᐧ
ᐧ
> From: Dave Horsfall
> What timezone did you say you were in again?
Ah; didn't realize you wanted the exact time, not just a date! :-)
Well, according to this:
http://www.rfc-editor.org/rfc/museum/ddn-news/ddn-news.n19.1
it was _planned_ to happen at "00:01 (EST) 1 Jan 1983". Whether it did happen
at that moment, or if in reality there was some variance, I don't know (IIRC,
I was off sailing in the Caribbean when it actually happened :-).
Noel
It was sort of a soft change over. All the did on January 1, 1983, is
disable link 0 on the IMPs. This essentially blocked NCP from working
anymore.
You could (and many of us were) run IP on the Arpanet for years before that.
In fact the weeks before we were getting ready for the change and we had our
TCP/IP version of the system up.
It crashed.
We rebooted it and set about debugging it.
It crashed again. Immediately my phone rang. It was Louis Mamakos, then
of the University of Maryland. He had tried to ping our system. I
called out the information to Mike Muuss who was across the desk from me.
We set to find the bug. It turned out that the ICMP echo handling in the
4.1c (I believe this was the version) that we'd cribbed our PDP-11/70 TCP
from had a bug where it used the incoming message to make the outgoing one,
AND it freed it, eventually causing a double free and crash. It was at
this point we realized that BSD didn't have a ping client program. Mike
set out to write one. It oddly became the one piece of software he was
most known for over the years.
The previous changeover was to long leaders on the Arpanet (Jan 1, 1981?).
This changed the IMP addressing space from eight bits (6 bits for imp
number, 2 for a host on imp) to 16 bits for imp number and 8 for a host on
imp. While long leaders were available on a port basis for years earlier,
they didn't force the change until this date. The one casualty we had a
PDP-11/40 playing terminal server running software out of the University of
Illinois called "ANTS." Amusingly the normal DEC purple and red logo
panels at the top of the rack were silkscreened with orange ANTS logos (with
little ants crawling on it). The ANTS wasn't maintained anymore and stuck
in short-leader mode. We used that option to replace that machine with a
UNIX (we grabbed one of our ubiquitous PDP-11/34's that were kicking
around). I kept the racks and the ANTS logo for the BRL Gateways. I
turned in the non-MM PDP-11/40. A year later I get a call from the
military supply people.
ME: Yes?
GUY: I need you to identify $65,000 of computer equipment you turned in.
ME: What $65,000 machine?
GUY: One PDP-11/40 and accessories.
ME: That computer is 12 years old... and I kept all the racks and
peripherals. Do you know how much a 12-year-old computer is worth?
The other major cut over was in October of 1984. This was the
Arpanet-Milnet split. I had begged the powers that be NOT to do the
change over on the Jan 1st as it always meant I had to be working the days
leading up to it. (Oct 1 was the beginning of the "fiscal" year). Our
site had problems. I made a quick call to Mike Brescia of BBN. This was
pre-EGP, and things were primarily static routed in those days. He'd
forgotten that we had routers at BRL now on the MILNET (all the others were
on the ARPANET) and the ARPANET-MILNET "mail bridge" routers had been
configured for gateways on the MILNET side.
> From: Dave Horsfall <dave(a)horsfall.org>
> the ARPAnet got converted from NCP to TCP/IP in 1983; ... have a more
> precise date?
No, it was Jan 1.
It wasn't so much a 'conversion', as that was the date on which, except for a
few sites which got special _temporary_ dispensation to finish their
preparations, support for NCP was turned off for most ARPANET hosts. Prior to
that date, most hosts on the ARPANET had been running both, and after that,
only TCP worked. (Non-ARPANET hosts on the then-nascent Internet had always
only been using TCP before that date, of course.)
Noel
Some interesting historical stuff today...
We lost Rear Admiral Dr. Grace Hopper USN (Retd) in 1992; there's not much
more than can be said about her, but I will mention that she received
(posthumously) the Presidential Medal of Honor in 2016.
As every Unix geek knows, today is the anniversary of The Epoch[tm] back
in 1970, and at least one nosey web site thinks that that is my birthdate
too...
And according to my notes, the ARPAnet got converted from NCP to TCP/IP in
1983; do any greybeards here have a more precise date?
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
On Fri, Dec 29, 2017 at 04:04:01AM -0700, Kevin Bowling wrote:
> Alpha generally maintained integer/ALU and clockspeed leadership for
> most of the '90s
> http://www.cs.columbia.edu/~sedwards/classes/2012/3827-spring/advanced-arch…
Wow, that first graph is the most misleading graph on CPU performance
I've ever seen. Ever.
So from 1993 to 2000 the only CPUs released were Alphas?
That era was when I was busy measuring performance across cpus and
operating systems and I don't ever remember any processor being a
factor of 2 better than its peers. And maybe I missed it, I only
owned a couple of alpha systems, but I never saw an Alpha that was
a game changer. Alpha was cool but it was too little, too late to
save DEC.
In that time period, even more so now, you had to be 2x better to get
a customer to switch to your platform.
2x cheaper
2x faster
2x more reliable
Do one of those and people would consider switching platforms. Less than
that was really tough and it was always, so far as I remember, less than
that. SMP might be an exception but we went through that whole learning
process of "well, we advertised symmetric but when we said that what we
really meant was you should lock your processes down to a processor
because caches turn out to matter". So in theory, N processors were N
times faster than 1 but in practice not so much.
I was very involved in performance work and cpu architecture and I'd love
to be able to claim that we had a 2x faster CPU than someone else but we
didn't, not at Sun and not at SGI.
It sort of make sense that there weren't huge gaps, everyone was more or
less using the same sized transistors, the same dram, the same caches.
There were variations, Intel had/has the biggest and most advanced
foundries but IBM would push the state of the art, etc. But I don't
remember anyone ever coming out with a chip that was 2x faster. I
suspect you can find one where chip A is introduced at the end of chip
B's lifespan and A == 2*B but wait a few month's and B gets replaced
and A == .9*C.
Can anyone point to a 2x faster than it's current peers chip introduction?
Am I just not remembering one or is that not a thing?
--lm
A bit off the PDPs, but to do a minor correction on mail below
The commercial version of 'UNIX' on Alpha was maybe first called
Digital Unix OSF/1, but quickly changed to Digital Unix at least with
v3 and v4.0 (A - G). From there we had a 'break' which only in part
was due to take over by Compaq and we had Tru64 UNIX v5.1A and V5.1B.
The V5.1B saw updates till B-6.
As for the Digital C compiler, I'm still using
DTCCMPLR650 installed Compaq C Version 6.5 for Compaq Tru64 UNIX Systems
When I get some old source (some even developed on SCO UNIX 3.2V4.2) I
like to run it through all compiler /OS-es I got handy. With the
Compaq C compiler and HP-UX ANSI C I mostly get pages of warning and a
few errors. By the time I 'corrected' what I think is relevant some
nasty coredumps tend to disappear :-)
Compile for a better 2018,
uncle rubl
>Date: Fri, 29 Dec 2017 21:30:11 -0500.
>From: Paul Winalski <paul.winalski(a)gmail.com>
>To: Ron Natalie <ron(a)ronnatalie.com>
>Cc: TUHS main list <tuhs(a)minnie.tuhs.org>
>Subject: Re: [TUHS] Why did PDPs become so popular?
>Message-ID: <CABH=_VRwNXUctFPav5rHX83wfUS0twMQuBhinRZ6QEY1cB3TNQ(a)mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
>
>On 12/29/17, Ron Natalie <ron(a)ronnatalie.com> wrote:
> The Alpha was hot
> stuff for about nine months. Ran OSF/1 formerly DigitalUnix formerly
> OSF/1.
>Digital UNIX for the VAX was indeed derived from OSF/1. The port to
>Alpha was called Tru64 UNIX.
>Tru64 UNIX was initially a pure 64-bit system, with no provision for
>building or running 32-bit program images. This turned out to be a
>mistake . DEC found out that a lot of ISVs had code that implicitly
>"knew" that sizeof() a pointer was the same as sizeof(int) was the
>same as 4 bytes. Tru64 was forced to implement a 32-bit compatibility
>mode.
>There was also a problem with the C compiler initially developed at
>DECwest in Seattle. It supported ONLY ANSI standard C and issued
>fatal errors for violations/extensions of the standard. We (DEC
>mainstream compiler group) called it the Rush Limbaugh
>compiler--extremely conservative, and you can't argue with it.
Warning: off-topic info
> I was told once that McIlroy and Morris invented macro instructions
> for assembly language. And certainly they wrote the definitive
> paper on macros, with, as I recall, something like 10 decisions you
> needed to make about a macro processor and you could generate 1024
> different macro systems that way. I wonder if that ever got
> published
The suggestion that I invented macros can also be found on-line, but
it's not true. I learned of macros in 1957 or before. GE had added
a basic macro capability to an assembler; I don't know whether they
invented the idea or borrowed it. In 1959 George Mealy suggested
that Bell Labs install a similar facility in SAP (SHARE assembly
program). Doug Eastwood wrote the definition part and I handled
expansions.
Vic Vyssotsky later asked whether a macro could define a macro--a
neat idea that was obviously useful. When we went to demonstrate
it, we were chagrinned that it didn't work: definition happening
during expansion resulted in colliding calls to a low-level
string-handling subroutine that was not re-entrant. Once that
was fixed, Steve Johnson (as a high-school intern!) observed
that it allowed the macro table to serve as an addressable
memory, for which the store and load operations were MOP
(macro define) and MAC (macro call).
Probably before Steve's bright insight, Eastwood had folded
the separate macro table into the opcode table, and I had
implemented conditional assembly, iteration over a list, and
automatic generation of symbols. These features yielded
a clean Turing-complete language-extension mechanism. I
believe we were the first to achieve this power via macros.
However, with GPM, Christopher Strachey showed you don't need
conditionals; the ability to generate new macro names is
enough. It's conceivable, but unlikely, that this trick
could be done with earlier macro mechanisms.
As for publication, our macroprocessor inspired my CACM
paper, "Macro nstruction extension of compiler languages",
but the note that Steve remembers circulated only in the
Labs. A nontrivial example of our original macros in
action--a Turing machine simulator that ran completely within
the assembler--was reproduced in Peter Wegner's programming
book, so confusingly described that I am glad not to have
been acknowledged as the original author.
Doug
> From: Paul Winalski
> Lack of marketing skill eventually caught up to DEC by the late 1980s
> and was a principal reason for its downfall.
I got the impression that fundamentally, DEC's engineering 'corporate culture'
was the biggest problem; it wasn't suited to the commodity world of computing,
and it couldn't change fast enough. (DEC had always provided very well built
gear, lots of engineering documentation, etc, etc.)
I dunno, maybe my perception is wrong? There's a book about DEC's failure:
Edgar H. Schein, "DEC is Dead, Long Live DEC", Berett-Koehler, San
Francisco, 2003
which probably has some good thoughts. Also:
Clayton M. Christensen, "The Innovator's Dilemma: When New Technologies
Cause Great Firms to Fail", Harvard Business School, Boston, 1997
briefly mentions DEC.
Noel
'FUNCTION: To save the programmer effort by automatically incorporating library subroutines into the source program.'in Cobol whole 'functions' (subroutines) and even code snipplets are 'copied' into the main source file by the copy statement. That's different to preprocessor macros, -definitions, -literals and, since ansi c, function prototypes.
'FUNCTION: To save the programmer effort by automatically incorporating library subroutines into the source program.'in Cobol whole 'functions' (subroutines) and even code snipplets are 'copied' into the main source file by the copy statement. That's different to preprocessor macros, -definitions, -literals and, since ansi c, function prototypes.
Dear all,
I am starting a new “history” section of the “weird machines and security” publication PoC||GTFO (https://www.alchemistowl.org/pocorgtfo for my mirror, https://www.nostarch.com/gtfo for a printed compilation of the first 15 issues).
Ideally we would like some articles about the history of security exploits where the historical importance is emphasised: we always get authors willing to tell us about the latest and greatest web exploit but they often lack any historical perspective about what has been done before.
As PoC||GTFO has a strong emphasis on weird machines and generally forgotten hardware and software I thought that the contributors to TUHS would be ideally placed to write something about their preferred security exploits in the past. I have fond memories of taking over a machine using and NFS /home filesystem exported to the wide-world, of someone trying to hack into my MasPar via the DEC Ultrix which controlled it, etc. but I am really rather interested in other perspectives.
I hope a few of you will want to contribute something to the collection, there is still space for the January 2018 edition if anyone is so inclined.
Cheers,
Arrigo
I apologise if this is too far from the main topic, but I wanted to check
an urban legend.
There is a story - as I have heard it told - that PDPs established their
place (and popularity) in the marketplace by pointedly *not* advertising
themselves as "computers", but instead as "programmed data processors".
This was because - so the story goes - that everyone in corporations of the
time simply *knew* that "computers" came only from IBM, lived in big
datacentres, had million-dollar price-tags, and required extensive project
management to purchase; whereas nobody cared enough about a thing called a
"programmed data processor" to bother bikeshedding the
few-tens-or-hundreds-of-thousands-of-dollars purchase proposal to an
inevitable death. Thus, they flitted under the purchasing radar, and sold
like hotcakes.
I wonder: does this story have substance, please?
Aside from anything else: I draw parallels to the adoption of Linux by Wall
St, and the subsequent adoption of virtualisation / AWS by business - now
reflected in companies explaining to ISO27001 auditors that "well, we don't
actually possess any physical servers..."
- alec
--
http://dropsafe.crypticide.com/aboutalecm
I think that steep educational discounts and equipment grants from Digital to major collages also had a major impact,as did the existence of DECUS that made a lot of software readily available.
Best regards,
David Ritchie
Charles Babbage KH FRS was born on this day in 1791; pretty much the
father of the computer, a model of his "difference engine" built to the
standards of the day worked, complete with its printer. What is not so
well known about him was that he dabbled in cryptography, and broke the
Vigenère cipher; unfortunately for him it was classified as a military
secret, so one Friedrich Kasiski got the credit instead.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Somewhat tangentially related to the other thread...
So, back in the days when I was using Consensys SVR4.2, I found a bug in
tar. It goes like this:
If there is a symbolic link in the tree that you are taring, the first
one works fine. If a second symbolic link has a shorter destination name
than the first, the extra characters from the first symbolic link
destination are appended to the end of the second. So for example:
a -> abcdef
b -> zyx
Tar will actually tar these symbolic links as:
a -> abcdef
b -> zyxdef
Being that I happen to have found, on the Internet, the sources to AT&T
SVR4.2, and some other System V variants, I went and investigated.
The relevant piece from AT&T SVR4.2 tar.c (broken):
Jan 25 1993 ./ATT/ATT-SYSVr4/cmd/tar/tar.c
case S_IFLNK:
<SNIP>
i = readlink(shortname, filetmp, NAMSIZ - 1);
if (i < 0) {
vperror(0, "can't read symbolic link %s",
longname);
return;
}
From USL-4.2 (apparently fixed):
Jan 22 1994 ./USL/usl-4.2-source/src/i386/cmd/tar/tar.c
case S_IFLNK:
<SNIP>
i = readlink(shortname, filetmp, NAMSIZ - 1);
if (i < 0) {
vperror(0, ":462:Cannot read symbolic link %s",
longname);
return;
}
else
filetmp[i] = '\0'; /* since readlink does not
supply a '\0' */
From Solaris 2.5:
case S_IFLNK:
<SNIP>
i = readlink(shortname, filetmp, NAMSIZ - 1);
if (i < 0) {
vperror(0, gettext(
"can't read symbolic link %s"), longname);
if (aclp != NULL)
free(aclp);
return;
} else {
filetmp[i] = 0;
}
BSD 4.4:
case S_IFLNK:
<SNIP>
i = readlink(shortname, dblock.dbuf.linkname, NAMSIZ - 1);
if (i < 0) {
fprintf(stderr,
"tar: can't read symbolic link %s: %s\n",
longname, strerror(errno));
return;
}
dblock.dbuf.linkname[i] = '\0';
Anyone know when/why/how tar diverged between the two branches? Note the
readlink directly into dblock.dbuf, while the SVR4 variants use a temp
string and then sprintf it in later.
From: http://www.catb.org/esr/faqs/usl-bugs.txt
17. tar(1) fails to restore adjacent symbolic links properly
Arthur Krewatt <...!rutgers!mcdhup!kilowatt!krewat> reports:
SVR4 tar has another strange bug. Seems if when restoring files, you
restore one file that is a link, say "a ->/a/b/c/d/e" and there is another
link just after it called "b ->/a/b/c" tar will restore it as "b ->/a/b/c/d/e"
This just seems to be a lack of the NULL at the end of the string, like
someone did a memmov or memcpy(dest,src,strlen(src)); where it should be
strlen(src)+1 to include the NULL.
Esix cannot reproduce this under 4.0.4 or 4.0.4.1, they think it's fixed.
Hello Team TUHS:
I am having a problem with my PDP-11 SVR1 running under a recent SIMH build. My problem occurs on both MAC OS X and FreeBSD.
First, I created a six disk (RP06) and eight port TTY (DZ) kernel, with swap placed on drive 1. The system behaves beautifully as FSCK reports clean. Eight users can login with no problem.
Second, I reverted to a pristine PDP-11 SVR1 with one drive (RP06) and no DZ and booted the default kernel (gdtm) and I see the same problem described below.
Third, when using the tape driver instead of /dev/null i get the same results.
Next, here is the issue:
cd /
find . -print | cpio -ocvB > /dev/null
It runs for a short while and then shitz a core:
I am using /dev/null to take the tape driver out of the equation.
Here is the backtrace for cpio:
$c
__strout(053522,043,0,053012)
__doprnt(046652,0177606,053012)
_fprintf(053012,046652,053522)
~main(02,0177636)
Now, interestingly, I run into a similar issue when using tar:
cd /usr
tar -cvf /dev/null .
Again, this will run for a while, then drops a core. Here is the backtrace for tar:
$c
__strout(043123,02,0,045506)
__doprnt(043123,0167472,045506)
_fprintf(045506,043123,0170600)
~putfile(0170600,0170641)
~putfile(0171654,0171704)
~putfile(0172730,0172745)
~putfile(0174004,0174016)
~putfile(0175060,0175066)
~putfile(0176134,0176136)
~putfile(0177672,0177672)
~dorep(0177632)
~main(04,0177630)
This really bugging me since my SVR1 is otherwise working flawlessly. I was able to remake the entire system and custom kernels that boot with no problem.
Also, I configured my main port to run inside the AWS Lightsail and now I have access to SVR1 from anywhere in the world!
I was also wondering if doing a CPIO or TAR on the entire system was overflowing some link tables and maybe this is expected behavior for the minimal resource of the PDP-11?
Thank you for any help.
Would you expect tar or cpio to dump core if you attempted to copy large filesystems (or the entire system) on a PDP-11?
Note: All of my testing has been in single user mode.
Truly,
Bill Corcoran
> From: Dave Horsfall
> Colossus, arguably the world's first electronic computer
Well, it all depends on your definition of "computer"... :-)
I myself prefer to reserve that term for things that are programmable,
and Turing-complete. (YMMV... :-)
So I call things like Colossus and ABC "digital electronic calculating
devices" (or something similar).
None of which is to take anything away from the incredible job done by Flowers
and his cohorts. It was an amazing device, and had a major effect on history.
Noel
Tommy Flowers MBE was born on this day in 1905; an electrical and
mechanical engineer, he designed Colossus, arguably the world's first
electronic computer, which was used to break the German "Lorenz"
high-level cipher (not Enigma, as some think).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Before we had to phase out our FTP server, I kept on it several
versions of UNIX clones and related OS that were mostly not on TUHS.
This post is to remember some of these systems. Many of these were
open sourced or widely available at some time and were related to UNIX
one way or another. I may not have the latest versions or all the
versions, but at least I do keep something.
The following ones have been open sourced at some point in time (I
believe):
ChorusOS
Coherent
EXOS
L4
Lunix
MaRTE-OS
Mach
OpenBLT
OpenSolaris
Sprite (I also own the original distribution CD)
Trix
UniFlex
agnix
amoeba
bkunix
bsd386
hurd
iunix
jaluna-c5
lsx-unix
mini-unix
minix
omu
opensolaris
starunix
thix
from tliquest.net/local/unix: uzi and various other bits
tme
tropix
tunix
unix-v8
unix-wega
uzi
xhomer
xinu
xv6
yoctix
Plus several archaic CDs with early versions of Linux,
Open/Free/NetBSD, (Walnut Creek, InfoMagic, etc. CD/ROMs)
and even the Beowulf/Extreme Linux CDs (plus I must keep around the
mirror we hosted for a long time of the Beowulf site). The hobbyist CDs
for OpenSolaris 8 (and I believe 9) with sources. Oh, and
MOSIX/OPENMOSIX.
In addition, I have many other sources whose Copyright status I'm not
aware of, but which are interesting for archival purposes.
Regarding QNX, yes, it was open sourced (at least for hobbyist use, I
have to check the license) for several distributions. I ported some
bioinformatics software and kept for some time a distribution
repository, and I'm pretty certain I must have the sources as well as
the virtual machines. I'll try to verify the licenses to see if it can
be redistributed, although I doubt they can. Oh, and I also own the
mentioned famous 3.5" diskette. I think I digitized it long ago. Would
have to check.
Off the Net, it has been possible, one time or another, to recover
executables and, sometime, even sources, of many systems. Archive.org
has -I believe- a copy of a once famous repo of abandonware with
binaries of SCO, System V, AIX, etc...
I know that AIX, ATT systemV vI, II, III and IV, Solaris V6, Tru64,
OSF-1, Dynix, Ultrix 11, BSDI, Ultrix-32 etc... have been out there at
some time or another in source code format, and binaries of IRIX, Lisa,
QNX, A/UX, xenix...
Some years ago, I had more free time and could test many systems on
emulators, and built images and accompanying scripts ready ti run. I
also made some tools to be able to transfer data in and out of old
unix versions (so I could edit the software off the virtual machine
while back-porting a screen editor to V6, v5, etc... with only vt100
support).
Not UNIX-related, I also keep copies of many other ancient operating
systems and software and hardware emulators.
Well, as I said at the beginning, everything that I had, I should still
keep while the hard disks continue spinning. If there is any
interest in adding any of these to TUHS, I can try to find a way to
send it all.
If I find time to browse through everything, I would like to upload all
the source code to GitHub (at least anything that's redistributable).
If I find the time...
But, Warren, if you are interested in anything, let me know and I'll
find a way to give you access.
j
--
Scientific Computing Service
Solving all your computer needs for Scientific
Research.
http://bioportal.cnb.csic.es
I blundered today into the GECOS field in /etc/passwd:
https://en.wikipedia.org/wiki/Gecos_field
"Some early Unix systems at Bell Labs used GECOS machines for print
spooling and various other services,[3] so this field was added to
carry information on a user's GECOS identity."
I had forgotten about this field and I don't recall it being
previously described as related to GECOS (I likely didn't take note at
the time I first encountered it).
Aside from the influence of Multics and other things on UNIX design
are there other tangible[1] manifestations of non-UNIX operating
system things like the GECOS field that were carried forward intact in
later UNIX implementations?
[1] things can be pointed at, rather than design ideas
> From: Doug McIlroy
> In fact, I don't recall being aware of the existence of the ITS
> movement at the time Unix arose.
For background, here are a few selected timeline items:
?/1967 ITS design starts
7/67 ITS first becomes operational
12/67 Multics single process boot on 645
10/68 Initial Multics milestone (8 users)
01/69 Limited Initial Multics milestone (12 users)
04/69 Bell Labs drops out of Multics
(I included the latter since I'm assuming the "time Unix arose" is after the
Bell Labs departure.)
Note: I'm not saying or implying anything about the 3 systems with this; this
is purely data.
Noel
> > are there other tangible[1] manifestations of non-UNIX operating
> > system things like the GECOS field that were carried forward intact in
> > later UNIX implementations?
>
> Job control was inspired by ITS job control capabilities. Control-Z
> does pretty much the same thing in both operating systems.
I don't think "carried forward" describes job control, which I
believe was never in any Research system. "Borrowed" would be
more accurate. In fact, I don't recall being aware of the
existence of the ITS movement at the time Unix arose.
Doug
> > In fact, I don't recall being aware of the existence of the ITS
> > movement at the time Unix arose.
> Was there ever a movement? It was just four machines at MIT.
When AT&T sued BSD Inc over (among other things) the phone number
1-800-ITS-UNIX, the joke was that MIT should have sued them too.
-- Richard
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
Ian Zimmerman:
> How do other train systems handle [DST], e.g. the European intercity
> system?
Dave Horsfall:
UTC? It's not hard to get used to it.
=====
You misunderstand the problem.
Suppose I'm planning to board a train at 0300 on the morning
Daylight Time ends.
Now suppose the train actually departs an hour early, at 0200,
because it originated before the time change and some nerd who
never rides trains declared that it shall not wait the extra
hour until scheduled departure time.
Nerds may be happy, but the paying passengers won't be. Telling
passengers to set their watches to UTC just won't happen. (Some
of us nerds actually had our watches on GMT for a few months
back in the years that gave the `Nixon table' in old ctime.c
its (informal) name, but gave up because it was just too damn
much work to stay in sync with the real world.)
Once upon a time, before railways had radio communications and
proper track-occupancy signalling, the consequences were more
serious than that: if you run an hour ahead of schedule, you
risk colliding with another train somewhere. That is why it
was the railways that first accepted and promoted standard time
zones.
Nowadays it's not about scheduling and safety, just about
having an acceptable user interface.
In a similar vein, I know of at least one case in which Amtrak
changed the official departure time of a train (that requires
advance reservations and often runs full) from 0000 to 2359,
because people would get confused about which day midnight
falls on and show up a day late. (Actually the Amtrak
timetable read 1200 midnight and 11:59 PM, but 24-hour time
is one of the changes I agree people should just accept
and use.)
Norman Wilson
Toronto ON
My question about SOL got me thinking a bit. It would be nice to have
section in TUHS of any early clones that could be collected. The two that
I can think of that probably should be there are (other feel free to point
ones that we should try to find):
1.) Idris, which was fairly true to V6 (enough that the one time I test it,
things from pretty much just worked). It was notable from being first.
Although the C compiler and the 'anat' (the assembler) were a tad
different. It the system that got Bill Plauger in trouble @ USENIX @ UDEL
when he was booed for a 'marketing' talk.
2.) CRDS (pronounced Cruds by those of use that use it at the time) -
Charles River Data Systems. It was a UNIX-like system, although I do not
think really attempted to hold to a V7 API much more than intent. Although
if my memory serves me, one of the unique features was the use of Reed &
Kanodia synchronization in its kernel [REED79], which I was a always a
fan. The system was slow as sin bit it ran on a 68000. [CRUDS system, a
Fortune box and our Vax/750 running BSD4.1 were the systems Masscomp used
to bootstrap].
Clem
[REED79] D.P. Reed and R.K. Kanodia, "Synchronization with Eventcounts and
Sequencers"
Arnold:
ISTR that the vaxen did have such things. Or rather, I ran some BSD 780s
for several years and I don't remember having to set the date / time
every time I did a reboot. They sat in a data center, so I may have never
done a cold boot from power on. It was a LONG time ago now, so there's
undoubtedly lots that I just plain don't remember.
====
I believe all the VAXes had time-of-year clocks, though
the implementation and the method of access varied from
model to model. On `Big' VAXes, the clock was considered
part of the console front-end, and accessed through the
model-specific console scheme. MicroVAXes had no console
front-end; I believe the clock was accessed through
registers, but it was an off-the-shelf digital-watch
chip with some funny format (separate registers for
year, month, day, hour, minute, second).
So they all had proper battery-backed-up clocks, but of
many different types. It wasn't as simple as reading a
single counter out of a register, sensible as that might
seem.
If anyone's really interested I can dig up details for
the several models of Big and MicroVAX I dealt with; I
still have all the code lying around.
Norman Wilson
Toronto ON
We lost Konrad Zuse on this day in 1995; he invented the world's first
programmable computer -- the Z3 -- which was unfortunately lost in the
Berlin bombing during 1943.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Heh, my V6 machine thinks (via 'date') that today is _Monday_, December
12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess the
date code is probably missing the '400 year' exception.
Noel
I tried a long time ago to set PS1 and PS2 to character sequences
which would permit cut-paste to work. I failed, but I didn't try very
hard.
The choice of "# " and "> " interests me. Because roots prompt of
"hash" has a side effect of making a cut-paste over it a comment in
most shells.
But.. it predates being *able* to cut-paste so it has to be a
side-effect, not a design choice.
"> " is more dangerous in cut-paste. Which again feels like a
side-effect both by anachronistic time effects, and intent: nobody
would be that suicidally mad to make cut-paste invoke shell
pre-forming the command sequence which neccessarily zeros out the >
targets before executing the cmd...
-G
> From: Arnold
> One would think that SIMH
I'm using Ersatz-11...
> into the simulated computer's time of day clock.
What Time of Day clock? We're talking PDP-11's here! :-)
The very last DEC models of the -11 (/93-94) had a ToY clock; I'm pretty sure
none of their others did. And of course V6 long pre-dated the /93-94.
Noel
>>> Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106. If you have source it’s incredibly trivial to change, and nothing changes size wise.
>>
>> Easy, but perhaps unwise. The sign bit is a potential escape hatch for
>> times, just as it is for characters in UTF-8.
>
> I'm not sure what you're suggesting - UTF-8 works because it's a
variable length encoding - a variable length timestamp might be
interesting as an academic exercise, but there's no way for time() to
specify how much space is needed, or be informed of how much space is
allocated
Like UTF-8, a variable-length time would be something normal
programs aren't supposed to see--it would be a format for
external media (i.e. file systems). Times in inodes would be
variable-length. Times returned by stat() and time() would
be full length. Only the kernel needs to know the encoding.
One may note that inodes already use a variable-length
encoding for the list of physical block addresses, so there
is nothing radical here.
I admit, though, that if the kernel can tell "old" from "new"
inodes, then they could have different time encodings rather
than one variable-length encoding.
Doug
> From: Clem Cole
> It would be nice to have section in TUHS of any early clones that could
> be collected.
The Unix Tree does have a section for "Unix Clones", and it has Coherent,
Xinu, Minix and some early Linuxes.
Another one that's missing (although in a different category) is Ultrix-32.>
Noel
Is there any information on the rationales behind the sizes and
positions of the hardcoded partitions in the rp/hp drivers in V6? There
are odd gaps of unused space between ones that appear to be intended to
be used together (I think I have some pieces of the puzzle worked out
below, but not all).
For the rp driver, only rp[01] uses the whole disk - rp2 and rp3 are
9200 blocks. The hp partitions looked more complicated, but it looks
like the manpage is wrong about where partition 2 starts - 84018 vs
48018. Partitions 0123 are 161584 blocks, 4567 are 162400 blocks. 4567
start on 100-cylinder boundaries, but are only a bit over 97 cylinders
long - in fact, they are the same length as rp[01]: 203 RP03 cylinders.
rp6 and rp7 are not mentioned in the manpage, and are 15600 blocks,
making rp[65] and 47 reasonably non-wasteful configurations.
Is there something special about 9200 blocks? rp2 and rp3 are that size,
and hp1 is that size rounded to the next cylinder.
V7 is much simpler: rp0 is the whole disk, 123 is a non-overlapping set
with no wasted space. hp[0145], 016, and 017 are non-overlapping sets.
> Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106. If you have source it’s incredibly trivial to change, and nothing changes size wise.
Easy, but perhaps unwise. The sign bit is a potential escape hatch for
times, just as it is for characters in UTF-8.
Doug
Can anyone enlighten me on the effective difference in the use of
/var/spool vs /var/lib?
It's my understanding that spools are for files that are in transit.
Effectively like packages moving through a shipping depo or people
waiting in line. I.e. they come in, they hang around for a while, and
then they leave.
I'm of the opinion that files in /var/lib should stick around longer and
are not nearly as dynamic (if at all, save for code updates).
As sure as I type this, I can't think of a reason library files would go
under /var vs a different */lib directory.
Does it make any difference if the files are actually executed and / or
consumed on the system?
I don't consider the POP3 / IMAP / NNTP server to be processing files
when people access messages / articles (read: files) via the respective
protocols.
Back story: I'm considering writing something that will download a file
every day and process the last day's / week's / month's file(s) to
generate output which is itself stored elsewhere. - I feel like these
files should live in the /var/spool/<bla> subdirectory.
--
Grant. . . .
unix || die
> From: Tom Ivar Helbekkmo
> My /83s have them, but I'm not so sure it's a feature of the CPU board:
> there's this thought nagging in the back of my head that the ToY thing
> actually sits in the front panel module with the various buttons on it.
/83 documentation seems to be very thin on the ground, alas.
It's definitely not the CPU; the KDJ11-B CPU (of the /83) manual
(EK-KDJ1B-UG-001) makes no mention of it; and in the PDP-11/94E System User
and Maintenance Guide (EK-KDJ1E-UG-001), section D.2 "PDP-11/94 and 11/84
Hardware Differences" (the /?3 and /?4 models use the same CPU board, but a
different backplane, with QBUS/UNIBUS converter, so this could equally well be
titled "PDP-11/93 and 11/83 Hardware Differences") says "Time of Year Clock",
indicating the 83/84 don't have one.
Several companies made after-market ToD clocks to plug into the QBUS, e.g.
here:
https://www.ebay.com/itm/371284594072
Is something like that what your /83 has?
Noel
Does anyone know of any other similar history discussion mailing lists /
newsgroups to discuss things like Mainframes or (Open)VMS?
I have some questions as I try to broaden my horizons, but I don't think
they fit in the TUHS context.
--
Grant. . . .
unix || die
>From the tuhs web site:
"This is a set of addenda to Seventh Edition Unix, possibly put out by the
Labs."
and
"The identity of the person who donated them is unknown."
Two questions: Was this put out by the Labs?
Second: There was recently a discussion about a tape found at some public
location during an early Unix user group meeting. Is this that tape?
Warner
> From: Arnold
> So how did you manage to lose a whole year? Time travel? :-)
No, I just haven't booted the V6 often in the last year, and when I did, I
never bothered to reset the time; so it was still on Nov, 2016.
Noel
> So, I looked at the code, and the bug is not obvious.
Because there _was_ no bug!!! :-)
It was saying December 12 was a Monday because the _year_ was still set to
_2016_, and in 2016, December 12 _was_ a Monday!
{Smacks forehead!}
Noel
> Guess the date code is probably missing the '400 year' exception.
So, I looked at the code, and the bug is not obvious. (The routine for
detecting leap years in V6's ctime.c is so minimalistic it actually works for
2000!)
The version I'm currently running had been worked on some, to have a hack fix
for the overflow of the number of 8-hour periods since the epoch ("hack" since
the 'fixed' version will break in 2029 or so), and I was worried that 'fix'
was wrong and caused the week-day problem, but I don't think so.
Noel
In the early 1980s, a bunch of French researchers set out to build a clone
of UNIX/V7 in Pascal (using a ukernel IIRC). The project was the SOL
project [Gien, 1983]. I believe it eventually begat the Chorus system
(which was C++); which UI was going to use for System V/R5 before it all
blew up.
1) Does anyone know what happen to SOL? Was it finished, deployed, used
for anything?
2.) Did the sources and doc survive (and who owns the IP)? I think those
should be in the TUHS archives, as I think this was the first attempt at a
rewrite of UNIX in something other than C (or assembler).
3.) On a similar thought, did the Chorus code survive and who owns the IP?
Clem
[Gien, 1983]*“The SOL Operating System*”, Michel Gien, USENIX Association,
1983, Proceedings of the Summer ’83 USENIX Conference, Toronto, On, Canada,
July, 1983, Pages 75-78
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
> From: Larry McVoy
> an altruistic person trying to make things better. They aren't all bad.
I would echo that. During my time on the IESG, I'd say the vast majority of
the people in the IETF really did want to make things better for everyone.
Of course, that statement covers a vast range of subtle variations, from
people who had nothing at all to gain personally, and thus really were pushing
what they thought was best; through people who did stand to gain, but truly
thought that what they were advocating was in everyone's interest; etc.
But the people who I felt were deliberately and knowingly putting their own
interests before the community's, i.e. recommending something they knew to be
harmful because it was good for them - they were very rare.
My recollection is now somewhat dim (too much was happening, at too high a
pace) of the details of those later days (well, 'later' only in that they were
considerably later than the very early days :-), but my sense is that people
like that didn't last long in the community; I have the distinct impression
that people figured them out, and as an eventual result, they tended to fade
from the scene. The IETF culture was not welcoming to that kind of thinking.
I dunno, maybe I'm just being naive (and I would certainly welcome correction
if I'm wrong), but that's how I saw it.
Noel
> Standards committees are not filled with altruistic folks working to
> make something great.
Not only in big ways, such as to sway the market. An example from Posix
is the undefined meaning of malloc(0). As I understand it, just one
committee member held out for malloc(0) to be an optional error, thus
confounding a harmless corner case with a fatal error. This nit has
burdened conscientious programmers ever since, all so one company's easily
fixable variant could be grandfathered into compliance.
Doug
> They might actually. Gates isn’t in charge, and there has been a major effort to being Linux compatibility into the Windows 10 kernel.
I agree that they might. Once there was strong commercial logic to disown their Unix history; that commercial logic may have reversed in the last decade.
> The biggest issue will be the never ending tangle of licenses, if they had other stuff integrated into there.
Let’s analyse that bit:
- They could pick the Nokia solution, i.e. to simply make an undertaking not to sue and thus avoid taking a position on Unix ownership etc.
- It would seem that Xenix 2 (no apparent version 1?) was more or less V7 and for internal use only (lacking a binary redistribution license, as Clem pointed out). Very little chance of 3rd party source code in there, but also of little interest for the historical record.
- The first real ports occur with Xenix 2.x in 1981-83. This would appear to have been based on System III with the PDP-11, Z8000, 68000 and 8086 as targets. Considering the size of MS at the time and how busy they were with IBM and DOS I don’t think they would have had much time to do more than a basic port: they contracted out much of the work to SCO, a two man shop at the time. It would seem that MS owned the IP with SCO being a contractor & part-owned subsidiary.
- This Altos manual https://web.archive.org/web/20170222131722/http://www.tenox.net/docs/xenix/… actually says that Xenix 2.x was still based on V7 and would seem to be a vanilla port, i.e. unlikely to include other stuff than V7, some 2BSD and of course MS' own stuff.
- The next release, Xenix 3.0 in 83-84, still appears to be SysIII based and would remain easy from that perspective. However, given two years of polishing it may have picked up bits and pieces from the outside and the tool chains probably started to include MS’ own compilers, it would be harder to figure out what could be released. However, looking at this highly interesting leaflet http://www.os2museum.com/wp/wp-content/uploads/2012/10/IBM-Seminar-Proceedi… it would seem that it is still all SysIII, BSD and Microsoft code.
In my opinion the real hurdle is finding a retired MS VP who’s interested in knocking on doors and making the case for this public relations move.
Paul
PS: There is scope for confusion over version numbers. It would seem that MS never directly sold Xenix, only via OEM’s. For example, IBM PC Xenix 1.0 would appear to be the same as MS Xenix 3.0
I have my own types.h that I carry around that has stuff like
typedef unsigned char u8;
typedef unsigned short u16;
typedef unsigned int u32;
typedef unsigned long long u64;
typedef signed char i8;
typedef signed short i16;
typedef signed int i32;
typedef signed long long i64;
and I wonder why the original Unix authors didn't make something similar?
Instead we have uint64_t and I don't see the added value of more chars.
--
---
Larry McVoy lm at mcvoy.comhttp://www.mcvoy.com/lm
On Thu, 7 Dec 2017, Greg 'groggy' Lehey wrote:
>> On Thu, 7 Dec 2017 11:01:51 +1100 (EST), Dave Horsfall wrote:
>
> Since we're being pedantic, note that this should be AEDT. EST is
> ambiguous, but in general refers to the east coast of the USA.
That appears to be how Alpine formats it (I certainly didn't write it)...
If it can be overridden then naturally I'm all ears.
>>> Serious question: is "FLAVOUR" accepted as an alias, or does the rest
>>> of the world have to put up with American spelling?
>
> Think of it as a keyword. No national origin necessary.
Fair enough, I suppose.
> We really have better things to think of.
Indeed; in the meantime I see you finally fixed your DNS... Yes, I 4xx
mail from servers with an improper chain, in the hope that they'll
eventually notice (it catches a lot of spammers).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Hello.
||On Wednesday, 29 November 2017 at 20:16:43 +0100, Steffen Nurpmeso wrote:
||> Greg 'groggy' Lehey <grog(a)lemis.com> wrote:
||>> On Monday, 27 November 2017 at 21:51:13 -0800, Jon Steinhart wrote:
||>>> Does anybody know the history of dash options? Were they
||>>> a UNIX thing or did UNIX borrow them from something earlier?
||>>
||>> If you mean specificall the dash, I can't help much. But there were
||>> similar ideas elsewhere. UNIVAC EXEC-8 (for the 1108, late 1960s) had
||>> options that followed the command with a comma, like:
||>>
||>> @RUN,G GOPU,STANDARD,STANDARD
||>> @ADD,PL ASGDMS . ASSIGNIERT DATENBASIS
||>
||> "WEIßT DATENBASIS ZU" or "ZUWEISUNG DATENBASIS"
...
||>> @ASG,A PF. . PF IST PROGRAMM-FILE MIT GOPU
||>
||> "PF IST PROGRAMM-DATEI MIT GOPU" or so.
...
I have apologised for this brusque and rude tone in private.
Unfortunately Greg Lehey was the one who took up that thread.
Puh; he is also right correcting my statements, it should have
been "Weist Datenbasis zu" and "PF ist Programmdatei mit GOPU"
instead of what i falsely claimed.
|The question that should have been asked with mild interest and
|very kind should have been "Why has German been used to comment
|this code?" at first, i am afraid to realize.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Ralph,
> > On unjustified text, fmt (which uses an algorithm purported to be like
> > Knuth-Plass)
>
> I wonder if that accounts for modern, coreutils 8.28-1, fmt's weirdness
> that I've seen for a while but never got around to investigating?
>
> $ yes x | fmt | awk '{print length, $0}' | uniq -c | sed 5q
You threw it something of a curve ball--an infinite paragraph.
At some point I suppose it chokes, and tries its best to make
a semiparagraph of equal-length lines. (Since the real paragraph
is not yet complete, it would be wrong to make the last line of
the semiparagraph short.)
Equilibrating apparently led to the split between 69- and 71-letter lines.
Whether the alternation of 11 of one and 16 of the other is an infinite
pattern or a subpattern is not clear. It could be part of a continued-fraction
approximation, related to the staircse appearance of a bitmap "straight line".
Doug
Regarding Theodore Bashkow I found a reference in this article
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.53.880&rep=rep1&ty…
"[Jain 90a], N. Jain, M. Schwartz and T. R. Bashkov, "Transport
Protocol Processing at GBPS Rates.",
Computer Communications Review, Vol. 20 (4), 1990, pp. 188-199."
No idea if this 'bashkov' is the 'bashkow' in the 'what's missing' discussion.
Cheers,
rudi
All, it's time to nudge the conversation away from debugging 2017 OOM issues
and the pre-UNIX history of the Arpanet.
We've been able to recover quite a deal of UNIX artifacts in the past two
decades, but what artifacts (in your opinion) are still out there that
we should try and unearth? Remember that the 50th anniversary is coming up
in 2019.
Here's my list:
- more PDP-7 source code: the shell, the rest of the utilities
- more 1st Edition source code: the rest of the utilities
- ditto the missing bits of 3rd, 4th and 5th Editions
- the Phil Foglio artwork that became a Usenix t-shirt (Armando, any ideas?)
- more details on who was Ted Bashkow, and the story behind his (+ others?)
analysis of the 1st Edition kernel at http://www.tuhs.org/Archive/Distributions/Research/Dennis_v1/PreliminaryUni…
- a firm date on the day that Ken added pipes to the kernel :)
What else should be we looking for? What physical artifacts (drawings,
artwork etc.) have we missed that should be sought after?
Cheers, Warren
Hi.
What's the difference between spell.old and spell in the V10 sources?
I'm guessing spell.old is the original version for the small-address-space
PDP-11 and that plain spell takes better advantage of the roomier vax...
Thanks,
Arnold
>> The choice of "# " and "> " interests me. Because roots prompt of
>> "hash" has a side effect of making a cut-paste over it a comment in
>> most shells.
>
> "#" as the root prompt predates # as the comment in the Bourne shell,
> not to mention predating copy/paste entirely. (My understanding is that
> the do-nothing command, ":" was used for comments. Talk about minimalist!)
>
> Same point for ">", since copy/paste didn't exist in the late 70s when
> Bourne was doing the shell, it wasn't an issue.
As early as V5 the (thompson) shell prompts were “#” and “%”, and “:” for
a label. As the goto command exists in V4 (there is a man page for it), I
would assume that those characters were used in V4 as well. So it would
seem to go back to 1974.
In the V7 (bourne) shell the default non-root prompt is “$”. Goto is
dropped at this point.
Don’t know when or where “>” was first used on Unix as a prompt character
(on my boxes it still is “$”).
Paul
> We've been able to recover quite a deal of UNIX artifacts in the past two
> decades, but what artifacts (in your opinion) are still out there that
> we should try and unearth? Remember that the 50th anniversary is coming up
> in 2019.
I’d be interested in anything on Spider/Datakit networking in V4-V7.
(at them moment the trail starts at V8, with just a few hints in earlier
source materials, and the bits that Noel found).
My thinking is that there were two main lines of early networking development
on Unix (and I realise that this gross simplification excludes many other
worthy projects):
1. The “sockets” lineage from UoI NCP Unix -> BBN NCP Unix -> BBN TCP Unix
-> 4.1a BSD -> 4.2 BSD
2. The “device” lineage from Spider -> Datakit -> UUCP -> streams
-> STREAMS
In the first lineage there is much material available, in the second very
little. This is probably because Datakit was AT&T confidential at the time.
Warren Toomey <wkt(a)tuhs.org> asks on Wed, 6 Dec 2017 08:21:13 +1000:
>> - more details on who was Ted Bashkow, and the story behind his (+ others?)
I found a short obituary at
http://engineering.columbia.edu/web/newsletter/spring_2010/memoriam
which is, in full:
>> ...
>> Theodore R. Bashkow Dr. Theodore R. Bashkow, professor emeritus of
>> electricial engineering and computer science, died Dec. 23, 2009, at
>> his home in Katonah, N.Y. See PDF version
>>
>> He was born in St. Louis, Mo., and attended Washington University,
>> where he received his BS degree in mechanical engineering. He went on
>> to receive his master’s and doctorate degrees at Stanford
>> University. He served in the U.S. Air Force as a first lieutenant
>> during World War II from 1943 to 1945.
>>
>> While in the Air Force, he served as maintenance officer and helped to
>> stage the Enola Gay. In the 1950s, while at Bell Labs, Professor
>> Bashkow became well known for his development of a new method for
>> analyzing linear electrical networks, Professor Bashkow’s A matrix. He
>> also became involved with digital computers. He joined the faculty of
>> the Columbia Electrical Engineering Department in 1958 and helped
>> transform the Electrical Engineering Department into the Department of
>> Electrical Engineering and Computer Science.
>>
>> When, in 1979, this department was divided into the Electrical
>> Engineering and Computer Science departments, Bashkow became one of
>> the founding faculty members of Computer Science. He taught courses in
>> digital logic, computer organization, and computer programming. He did
>> research on parallel processing. In collaboration with Herbert
>> Sullivan, he pioneered a new approach to that subject through the
>> development of CHoPP, Columbia Homogeneous Parallel Processor, a
>> large-scale, homogeneous, fully distributed parallel machine. A number
>> of Columbia graduate students and a junior faculty member, David
>> Klappholz, were also involved at various stages.
>>
>> In 1980, the Computer Science Department instituted an annual award in
>> his honor, the Theodore R. Bashkow Award. Among his many affiliations,
>> Professor Bashkow was an active member of IEEE, ACM, and Sigma Xi
>> organizations.
>> ...
He is apparently not in Wikipedia.
I then searched our local bibliography archives and found this
publication-title summary (Bashkow is an uncommon name, so I didn't
attempt to disambiguate the reported articles):
MariaDB [bibtex]> select filename, label, substr(title,1,80) from bibtab where (author like '%Bashkow%') order by year, filename;
+-------------------------+--------------------+----------------------------------------------------------------------------------+
| filename | label | substr(title,1,80) |
+-------------------------+--------------------+----------------------------------------------------------------------------------+
| jacm.bib | Bashkow:1958:CPR | A ``Curve Plotting'' Routine for the Inverse Laplace Transform of Rational Funct |
| ieeetranscomput.bib | Bashkow:1963:RDA | R63-106 The D 825 Automatic Operating and Scheduling Program |
| ieeetranscomput.bib | Bashkow:1963:C | Contributors |
| ieeetranscomput.bib | Bashkow:1963:PSD | A Programming System for Detection and Diagnosis of Machine Malfunctions |
| ieeetranscomput.bib | Bashkow:1964:SCA | A Sequential Circuit for Algebraic Statement Translation |
| fortran1.bib | Bashkow:1967:SDF | System Design of a FORTRAN Machine |
| ieeetranscomput.bib | Bashkow:1967:SDF | System Design of a FORTRAN Machine |
| ieeetranscomput1970.bib | Bashkow:1971:BSS | B71-6 System Structure in Data, Programs, and Computers |
| ieeetranscomput1970.bib | Bashkow:1971:BIC | B71-2 Introduction to Computer Organization |
| ieeetranscomput1970.bib | Bashkow:1973:CRO | Comment on Review of Operating Systems Survey |
| ovr.bib | Sullivan77b | A Large Scale, Homogeneous, Fully Distributed Parallel Machine |
| ovr.bib | Sullivan77a | A Large Scale Homogeneous Fully Distributed Parallel Machine |
| sigarch.bib | Sullivan:1977:LSHb | A Large Scale, Homogenous, Fully Distributed Parallel Machine, II |
| sigarch.bib | Sullivan:1977:LSHa | A large scale, homogeneous, fully distributed parallel machine, I |
| ieeetranscomput1980.bib | Ghafoor:1989:BFT | Bisectional Fault-Tolerant Communication Architecture for Supercomputer Systems |
| super.bib | Ghafoor:1989:BFT | Bisectional Fault-Tolerant Communication Architecture for Supercomputer Systems |
| ieeetranscomput1990.bib | Ghafoor:1991:SOG | A study of odd graphs as fault-tolerant interconnection networks |
+-------------------------+--------------------+----------------------------------------------------------------------------------+
17 rows in set (2.67 sec)
-------------------------------------------------------------------------------
- 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/ -
-------------------------------------------------------------------------------
> From: Jon Forrest
> LBL has never been part of UC Berkeley. It's (always?) been a
> Department of Energy laboratory managed by the Univ.
Actually, I think if you go back far enough (1930's), it was part of UCB,
back when Lawrence first started it.
And of course the DoE didn't exist until 1977, so during the early ARPANET
era if would have been under the AEC, and then I assume the Energy Research
and Development Administration after 1974 (I assume it didn't go with the NRC
when the AEC was split up).
Noel
This page:
http://www2.lbl.gov/Publications/75th/files/exhibit.html
mentions 3 links between LBL and Arpanet:
- In 1974, the Lab’s CDC 6600 became the first online supercomputer when it was connected to ARPANET, the Internet’s predecessor.
- In 1986, when the Internet was on the verge of collapse from congestion, a Berkeley Lab researcher, Van Jacobson, co-developed the congestion control algorithms that allowed the Internet to keep growing.
- In 1995, Jacobson and Steven McCanne developed MBone, the first successful software for multiparty audio and video conferencing over the Internet.
I don’t think anybody was thinking you wilfully misrepresented things,
it is always interesting to hear about strands of history that might
have been missed earlier.
It would be helpful to better understand the time period, people
involved and the scope of work.
I’m a bit confused as to what time period you are referring to: I
think you are referring to the initial development of Arpanet, i.e.
the second half of the sixties. Is that correct?
There is a page here with some info on events in that period and it
may have missed some interesting development work done at LBL:
https://www.livinginternet.com/i/ii_roberts.htm
Paul
>
> Message: 7
> Date: Mon, 4 Dec 2017 19:46:21 -0800
> From: Deborah Scherrer <dscherrer(a)solar.stanford.edu>
> To: tuhs(a)minnie.tuhs.org
> Subject: Re: [TUHS] ARPAnet now 4 nodes
> Message-ID: <8254fc85-12e6-4730-8f14-faf060ad6a70(a)solar.stanford.edu>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Yes, Van Jacobson was involved. Great guy. So sorry you feel the need
> to think I am lying. Why would I make up this stuff? I was a
> teeny tiny piece of it. Doesn't affect my career one way or other. I
> don't care what you believe, but this really did happen.
>
> D
> From: Deborah Scherrer
> I don't know about the historical record. But everything I said is true,
> based on my own personal experience. ... I was there, this happened. If
> people didn't write it down, I don't know why.
FWIW, I was actually at many of those meetings. (You can find my name in a lot
of those Meeting Notes.) Nobody from LBL, or UCB in general, was involved -
and the Meeting Notes (which, you will note, are quite detailed) indicate the
same thing.
(Later on, of course, Van Jacobson of LBL did some imporant work on TCP
congestion control, but that was in '87 or so - I can't instantly lay my hands
on my copy of Van's famous e-mail, to get a more exact date - some years after
the full-scale deployment of TCP/IP in January, 1983.)
> Why would I misrepresent?
Perhaps you are conflating several different things in your memory? Human
memory is very fallible, which is why historians prefer contemporary documents
(and even those sometimes have errors). Here:
http://www.chiappa.net/~jnc/nontech/tmlotus.html
is a mildly amusing example (from a completely different arena) of all that.
Noel
Does anyone remember the reason that processes blocked in I/O don't catch
signals? When did that become a thing, was that part of the original
design or did that happen in BSD?
I'm asking because I'm banging on FreeBSD and I can wedge it hard, to
the point that it won't recover, by just beating on tons of memory.
--
---
Larry McVoy lm at mcvoy.comhttp://www.mcvoy.com/lm
> From: Deborah Scherrer
> the initial research on the arpanet was done at Lawrence Berkeley Lab
I was interested to find out more about this: I looked in Hafner, "Where
Wizards Stay Up Late" (the popular, but well-researched, book on the ARPANET)
but couldn't find 'Lawrence Berkeley' or 'LBL' in the index (although it did
have Lawrence Livermore); there were a couple of 'Californa, University of (at
Berkeley' listings, but none covered this. In Abbate, "Inventing the Internet"
(the first half of which covers the ARPANET), nothing under any of 'Lawrence
Berkeley', 'LBL', 'Berkeley' or 'California'.
In Norberg/O'Neill, "Transforming Computer Technology" (the standard ARPA
history, which has extensive coverage of the ARPANET project), there was one
entry for 'Californa, University (Berkeley)', which might be about the work
you refer to:
"IPTO issued a contract for a 'network' project at the Berkeley campus of
the University of California ... because of the presence at Berkeley of
specialists in programming languages and heuristic programming".
But there's nothing about what was produced. Is there anything you can point
me at that provides more detail? Thanks!
Noel
> From: Dave Horsfall
> The ARPAnet reached four nodes on this day in 1969 (anyone know which?)
SRI, UCSD, UCLA, Utah:
http://www.chiappa.net/~jnc/tech/arpageo.html
All West Coast, plus Utah. Next was BBN; if you look at the IMP numbers, in
HOSTS.TXT, they were assigned in order of installation.
> at least one "history" site reckoned the third node was connected in
> 1977 ... Well, I can believe that perhaps there were only three left by
> then...
No:
http://www.chiappa.net/~jnc/tech/arpalog.html
1977 was not too many years before the peak in size (with the MILNET split
coming in October, 1983). Per:
http://www.chiappa.net/~jnc/tech/arpanet.html
"Prior to the split, in 1983, there were 113 IMPs in the ARPANET; after the
ARPANET/MILNET split, the MILNET consisted of 65 nodes, leaving the ARPANET
with 68 nodes."
Noel
On Wed, Nov 29, 2017 at 08:00:55PM +0100, Steffen Nurpmeso wrote:
> Larry McVoy <lm(a)mcvoy.com> wrote:
> |On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote:
> |> 1977 marks my entry into the world of UNIX. I've always stated there was
> |> only one person who truly understood nroff and he was dead.
> |> I mourn the fact that of all the UNIX greats I've met, I missed out on
> |> Ossanna.
>
> |I think one could argue that James Clark has a pretty good handle on
> |roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc).
>
> And Werner Lemberg, who carried the torch for the last almost two
> decades. He brought in some really great improvements, like
> arguments for strings, which allows to write pretty much TeX like
> a.k.a. inline if you want to (as in "this is \*[I talic] text").
Yep. James exited stage left and Werner stepped in. I mean no disrespect
to anyone, I was just saying that James has a really good handle on roff,
he redid it all. I admire him for doing so (even though I curse the fact
that he did it in C++).
All,
Was Unix ever ported to a PDP8, or any other 12 bit environment, for
that matter? If not, why not? My understanding, such as it is, is that
Unix was created on the PDP7 - btw, thank you very much, Ken Thompson,
you definitely changed my world :), which is an 18bit machine, and that
it soon found its first real home on the 16 bit PDP11 series of machines
(an 11/20), and from there, ever upward or at least ever onward. I'm
curious about it for historical reasons, of course, but also because
I've been messing around in the PDP8 emulation world and enjoying the
excursion into simplified ISA and memory architectures.
-will
So tape I can see being more weird, but isn't raw disk just "don't put it
in buffer cache"?
>From what I've been able to gather early tape in Unix was dicey, something
about the driver doing seek. Was there more to it than that?
On Tue, Nov 21, 2017 at 02:33:55AM +0000, Clem Cole wrote:
> It???s not so much that they don???t mix, it???s not quite the same. Some
> coprocessor ideas work really well into the Unix I/O model, others don't.
> Raw disk and tape I/O ala a PDP11 or VAX for instance is not easy on an
> IBM channel controller or a CDC PPU.
>
>
>
>
>
>
>
>
> On Mon, Nov 20, 2017 at 6:45 PM Larry McVoy <lm(a)mcvoy.com> wrote:
>
> > On Mon, Nov 20, 2017 at 06:43:28PM -0500, Ron Natalie wrote:
> > >
> > >
> > > > I get that PDP-11 and VAX used memory mapped I/O but was that somehow
> > > exposed above the device driver layer? If so, I missed that, because I
> > had
> > > no conceptual or technical problem with talking to an I/O
> > >
> > > > channel, it was pretty easy. And I suck at writing drivers.
> > >
> > > There's nothing that restricts a device driver to memory mapped I/O.
> > You
> > > do what ever you have to do to initiate the I/O. Even the x86's
> > originally
> > > used special instructions to start the I/O (in/out). The DENELCOR HEP
> > > supercomputer (we did this port around 1983) we had to bounce I/O
> > requests
> > > off a separate I/O processor different from where the kernel was running.
> > > Similar constucts were used on other machines.
> >
> > Yeah, that's what I thought. But other people were saying that I/O
> > processors and Unix didn't mix. I don't get that, seems like whatever
> > the model is is hidden under the driver, that's the whole point of the
> > driver design is it not?
> >
> --
> Sent from a handheld expect more typos than usual
--
---
Larry McVoy lm at mcvoy.comhttp://www.mcvoy.com/lm
> From: Charles Anthony
> Entry points are usually defined as "foo$bar", where "foo" is the
> segment name, and "bar" an entry point in the segment symbol table. I
> believe that the degerate case of "foo$" is treated as "foo$foo" by the
> shell.
So I'm curious about how this, and additional names, interact. (For those who
aren't familiar with Multics, a segment [file, sort of] can have multiple
names. This is sort of like 'hard links' in Unix, except that in Multics one
name, the "primary name" is very slightly preeminent. See here:
http://web.mit.edu/multics-history/source/Multics/mdds/mdd006.compout
page 2-5, for more, if you're interested.)
So if I have a segment with primary name 'foo', and additional names 'bar' and
'zap', and I say 'zap' to the Multics shell, I assume it does a call to
zap$zap, which finds the segment with the primary name 'foo', and calls the
'zap' entry therein?
> Multics rulez; UNIX droolz
Dude, you clearly have Very Large brass ones to send that to this list! :-)
Noel
Early on, when multics was understood to have
one big, segemented address space, it was expected
that PL/I name qualification ($) would serve to address
segments. I do not know whether that idea was
actually implemented.
Doug
My favorite reduction to absurdity was /bin/true. Someone decided we
needed shell commands for true and false. Easy enough to add a script that
said "exit 0" or exit 1" as its only line.
Then someone realized that the "exit 0" in /bin true was superfluous, the
default return was 0. /bin/true turned into an empty, yet executable, file.
Then the lawyers got involved. We got a version of a packaged UNIX (I
think it was Interactive Systems). Every shell script got twelve lines of
copyright/license boilerplate. Including /bin true.
The file had nothing but useless comment in it.
> Multics had some kind of `attach' and `detach' of I/O streams, well
> known to Ossanna, so perhaps dup(2), and a Thompson-shell syntax to go
> with it meant `>' was earmarked early on.
According to "The Evolution of the Unix Timesharing System", full path names
arrived later than I/O redirection, so by they time they needed a separator,
'>' and '<' were gone. '/' also has the advantage of being a non-shift
character!
Noel
PS: Re-reading that, I see that early Unix did not have an exec() call (as I
was just discussing); it was done in user mode, with normal read and write
calls.
> On Tue, Nov 28, 2017 at 2:36 PM, Paul Winalski <paul.winalski(a)gmail.com>
> wrote:
>
>> MS/DOS patterned its command line
>>
>> syntax after RT-11 and inherited the slash as a command option
>> introduction from there.
>
> Minor correction... To do a CDC style patient zero history ;-) RT11 took
> it from DOS/8, CP/M took it from RT11, then finally DOS-86 which became
> PC-DOS ney MS/DOS took it from CP/M.
I think Gary Kildall was very much into the PDP-8 when teaching at the
Naval Post Graduate School in the early 70's (doing the FORTRAN/8 compiler
for instance). Can't find the link now, but I read somewhere that his
work with the 8008 and 8080 was guided by the idea of having a PDP-8 like
machine in his home office. For CP/M's command syntax RT11 probably did
not come into it. I just had a quick glance through the CP/M 1.4 - 2.2
manuals, and I did not see slash options (or any other option character).
Microsoft bought QDOS as a base for PC-DOS/MS-DOS. The QDOS system calls
were done such that converting existing 8080 CP/M code with Intel's source
level 8080-to-8086 asm converter would generate the correct code. The FAT
file system was modeled after the one used by MS Disk BASIC for the 8086.
Not sure where the QDOS command line came from, other than CP/M. MS did a
lot of its early development on a PDP-10: perhaps that was an inspiration
too.
Sorry for getting off-Unix-topic...
> From: Doug McIlroy
> But if that had been in D space, it couldn't have been executed.
Along those lines, I was wondering about modern OS's, which I gather for
security reasons prevent execution of data, and prevent writing to code.
Programs which emit these little 'custom code fragments' (I prefer that term,
since they aren't really 'self-modifying code' - which I define as 'a program
which _changes_ _existing_ instructions) must have some way of having a chunk
of memory into which they can write, but which can also be executed.
> Where is the boundary between changing one instruction and changing them
> all? Or is this boundary a figment of imagination?
Well, the exec() call only overwrites existing instruction memory because of
the semantics of process address space in Unix - there's only one, so it has
to be over-written. An OS operating in a large segmented single-level memory
could implement an exec() as a jump....
BTW, note that although exec() in a single address-space OS is conventionally
something the OS does, this functionality _could_ be moved into the user
space, provided the right address space primitives were provided by the OS,
e.g. 'expand instruction space'. So the exec() code in user space would i)
find the executable, ii) see how much of each kind of memory it needs, iii)
get the OS to give it a block of memory/address space where the exec() code
can live while it's reading in the new code, iv) move itself there, v) use
standard read() calls to read the new image in, and then vi) jump to it.
Yes, it's probably simpler to implement it in the OS, but if one's goal is to
minimize the functionality in the kernel...
Noel
In case you missed it:
https://www.spectrum.ieee.org/view-from-the-valley/tech-history/silicon-rev…
It is important to keep the conversations alive and not to file your
memory boxes away in the attic. Thanks for sharing what you know and
especially for making your documents and bits available.
-will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
OK, we were discussing terminals this morning with some other old guys. If
I knew the answer to this I've forgotten.
Every PDP-11 UNIX I ever used had the console KL-11 as /dev/tty8. The
question is why. My guess is that for some reason
an 8 terminal multiplexor (DZ-11?) was stuck at tty0, but why?
> From: Larry McVoy
>> they aren't really 'self-modifying code' - which I define as 'a program
>> which _changes_ _existing_ instructions
> Isn't that how dtrace works?
I'm not familiar with dtrace(), but if it modifies some other routine's code,
then it would not be "self" modifying, right?
Oh, another category, sort of like biological viruses (which are in a grey
zone between 'alive' and not): the PDP-11 paper tape bootstrap:
http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/bootloader.mac
in which the program's own code _is_ modified - but not by program
instructions, but by data on the paper tape it is reading in. It's
entertainingly convoluted (the copy above should be well-enough commented to
make it pretty easy to understand what's going on).
Noel
We lost J.F. Ossanna on this day in 1977; he had a hand in developing
Unix, and was responsible for "roff" and its descendants. Remember him,
the next time you see "jfo" in Unix documentation.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> From: Kevin Bowling
> The earliest stuff may be covered by Novell's grant of early code.
> ...
> Would be fun to run *ix on any of them.
Alas, the Bell port of Unix to the /370 needs that underlying layer of code
from IBM, and that's probably not going to escape. Too bad, it would be pretty
cool.
Noel
I am curious about how the Harvard Architecture relates to Unix,
historically. If the Harvard Architecture is predicated on the
separation of code from data in order to prevent self-modifying code (my
interpretation), then it would seem to me to be somewhat at odds with a
Unix philosophy of extreme abstraction (code, data, it's all 0's and
1's, after all). In my naive understanding, the PDP-11 itself, with the
Unibus and apparently agnostic ISA seem to summarily reject the Harvard
Architecure...
My question is - was there tension around Harvard and Von Neumann
architectures in Unix circles and if so, how was it resolved?
Thanks,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
There are some little bits in the public V7 source code that
suggest that it had support for Datakit, but that it was scrubbed
from the public release:
There is a Datakit header file:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/dk.h
and Datakit state bits are defined in 'sys/tty.h':
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/sys/tty.h
Does anyone know if this assumption (Datakit support in V7) is correct?
Perhaps more specific, was there a remote login program for V7/Datakit,
of for V6/Spider? For V8/Datakit there was 'dcon', but perhaps this
was built on earlier programs.
(I'm aware of 'cu' of course, but that does not support Datakit or
Spider).
Being able to login to another host on the network seems so useful
that it is hard to believe that a precursor to 'dcon' did not exist for
V6 and/or V7.
Thanks for explaining that. I think it may be for 10th edition though.
I searched for ipcopen() and 'gated' in the 8th edition source and could
not find them. In that search I did find a few bits that strongly suggest that
IP over Datakit was what was used in late '85 (when dmr posted about this).
In /usr/src/cmd/inet/READ_ME there is an example configuration that seems
to match with dmr's example. In that file an IP over a Datakit channel
appears to be configured.
(see http://chiselapp.com/user/pnr/repository/v8unix/artifact/6d09b05c7f06a2cc?l…)
The program 'dkipconfig' sets up a circuit and pushes the IP discipline on
the stream, both on the local end and on the remote end. It sets fixed local
and remote addresses, much the same as with a 'slip' line.
(see http://chiselapp.com/user/pnr/repository/v8unix/artifact/6c5f3267b58721a6?l…)
On Sat, Nov 25, 2017 at 4:50 PM, William Cheswick <ches at cheswick.com> wrote:
>
> Nope, not IP over Datakit, as I recall. It was quite interesting to work at
> a site (Bell Labs) where there were two distinct network technologies.
>
> [--snip--]
>
> This library was socks about seven years before socks, originally written by
> Presotto and Howard Trickey. The relay program was originally called
> “gated”, but that wouldn’t do after a while. I renamed it “proxyd”, and
> that is the first use of “proxy" in this context that I am aware of.
>
> If you were on AT&T’s intranet and wanted to connect externally, you ripped
> out the entire socket dance and replaced it with an ipcopen call. I also
> distributed common modified clients, like ptelnet, pftp, pfinger, etc.
>
> I still have all this code, and I suppose it ought to go in an archival
> repository. I can’t imagine that AT&T/Lucent/Alcatel/Nokia would care at
> this point. Anyone want it?
>
I'm trying to figure out how tcp/ip networking worked in 8th edition Unix.
I'm starting from dmr's paper about streams (http://cm.bell-labs.co/who/dmr/st.html) the V8 man pages (http://man.cat-v.org/unix_8th/3/) and browsing the source code (tarball here http://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/)
In the below I use 'socket' to mean a file descriptor bound to a network connection. My current understanding is like this:
- The hardware interface is exposed as a character device; for tcp/ip only ethernet is supported. Directly accessing this device reads/writes ethernet frames.
- One can push an 'ip' module (only) onto an ethernet device; this module also handles ARP. Once this is done IP messages are queued to the virtual ip devices, /dev/ipXX. The device minor number XX equals the protocol number, i.e. the ip packets are demultiplexed into separate virtual devices. IP packets from multiple ethernet cards all end up on the same virtual ip devices. I'm not sure if one can still read/write to the ethernet device after pushing the ip module, but I think you can, creating a raw IP interface so to say.
- On /dev/ip6 one can push a TCP module. The TCP module handles the TCP protocol and demultiplexes incoming traffic to the virtual /dev/tcpXX devices. On /dev/ip17 one can push a UDP module. The UDP module handles the UDP protocol and demultiplexes incoming traffic to the virtual /dev/udpXX devices. Not sure wether the ip6 and ip17 devices can still be read/written after pushing these disciplines.
- There are 100 udp devices, /dev/updXX. To open a UPD socket, one opens an unused udp device (through linear search). This socket accepts binary commands ('struct upduser') through the read()/write() system calls. There is a command to set the local port (effectively 'bind') and a comment to also set the foreign address and port (effectively 'bind+connect'). As long as the socket is not connected actual datagrams are preceded by a command header with the address/port information (effectively 'sendto'/'recvfrom'). Once the socket is connected, it is no longer possible to send further commands, but each write/read is a datagram. For udp sockets it is not possible to specify the local address: it is chosen by the system to match with the given foreign address.
- There are 100 tcp devices /dev/tcpXX. Initial connection is always over an odd numbered device. To open a TCP socket, one opens an unused tcp device (through linear search). This socket accepts binary commands ('struct tcpuser') through the read()/write() system calls. There is a command to actively connect (effectively 'connect' with optional 'bind'), and a command to passively listen (effectively 'bind'+'listen'). If the connect command is sent, one can read one more response block and then the socket becomes a regular tcp socket. If the listen command is sent, one can read multiple response blocks, one for each new client (effectively 'accept'). Those response blocks contain a device number for the new client connection, i.e. one has to subsequently open device /dev/tcpXY to talk to the client. This number is always even, i.e. locally initiated tcp connections are over odd numbered tcp devices, and remotely initiated connections are over even numbered tcp devices - not sure what the significance of this is.
- The above seems to be modeled on the Datakit setup, where the network is exposed as 520 virtual devices, one for each channel, as /dev/dk/dkXXX. These channels than also seem to accept binary command blocks through the read()/write() interface, with a 'connect' type command changing the connection into a data only channel.
Anybody on the list with 8th edition experience who can confirm that the above understanding is about correct?
Paul
> From: Will Senn <will.senn(a)gmail.com>
> I am curious about how the Harvard Architecture relates to Unix,
> historically. If the Harvard Architecture is predicated on the
> separation of code from data in order to prevent self-modifying code (my
> interpretation)
That's not the 'dictionary' definition, which is 'separate paths for
instructions and data'. But let's go with the 'no self-modifying code' one for
the moment.
The thing is that self-modifying code is pretty much an artifact of the dawn
of computers, before the economics of gates moved from that of tubes, to
transistors, and also before people understood how important good support for
subroutines was. (This latter is a reference to how Whirlwind did subroutines,
with self-modifying code.) Once people had index registers, and lots of
registers in general, self-modifying code (except for a few small, special
hacks like bootstraps which had to fit in tiny spaces) became as dead as the
dodo.
It's just a Bad Idea.
> then it would seem to me to be somewhat at odds with a Unix philosophy
> of extreme abstraction (code, data, it's all 0's and 1's, after all).
The people who built Unix were fundamentally very practical. Self-modifing
code is not 'practical'. (And note that Unix from V4:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/text.c
onward has support for pure text - for practical reasons).
> the PDP-11 itself, with the Unibus and apparently agnostic ISA seem to
> summarily reject the Harvard Architecure...
You could say that of a zillion computers. The only recent computer I can
think of offhand with separate instruction and data paths was the AMD 42K
(nice chip, I used it in a product we built at Proteon). They had separate
ports for instructions and data purely for performance reasons. (Our card had
a pathway which allowed the CPU to write the instruction memory, needed during
booting, obviously; the details as to how we did it escape me now.)
> From: Jon Steinhart
> For all intents and purposes instructions were separate from data from
> the PDP 11/70 on.
s/70/45/.
And the other -11 memory management (as on the /40, /23, etc) does allow for
execute-only 'segments' (they call them 'pages' in the later versions of the
manual, but they're not) - again, separating code from data. Unix used this
for shared pure texts.
And note that those machines with separate I+D space don't meet the dictionary
definition either, because they only have one bus from the CPU to memory,
shared between data and instruction fetches.
Noel
> From: Doug McIlroy
> Optimal code for bitblt (raster block transfers) in the Blit
Interesting case. I'm not familiar with BitBLT codes, do they actually modify
the existing program, or rather do they build small custom ones? Only the
former is what I was thinking of.
Noel
>From the discussion of self-modifying code:
>> Optimal code for bitblt (raster block transfers) in the Blit
>
> Interesting case. I'm not familiar with BitBLT codes, do they actually modify
> the existing program, or rather do they build small custom ones? Only the
> > former is what I was thinking of.
>
It built small custom fragments of code. But if that had been in D
space, it couldn't have been executed.
>> Surely JIT compiling must count as self-modifying code.
>
> If it does, then my computer just runs one program from when I turn it
> on. It switches memory formats and then is forever extending itself and
> throwing chunks away.
Exactly. That is the essence of stored-program computers. The exec
system call is self-modification with a vengeance.
Fill memory-and-execute is the grandest coercion I know. What is
data one instant is code the next.
It's all a matter of viewpoint and scale. Where is the boundary
between changing one instruction and changing them all? Or is
this boundary a figment of imagination?
Doug
> From: "Ron Natalie"
> Every PDP-11 UNIX I ever used had the console KL-11 as /dev/tty8.
> The question is why.
Blast! I have this memory of reading an explanation for that somewhere - but
I cannot remember what it was, or where! I've done a grep through my hoard of
Unix documents, looking for "tty8", but no hits.
Noel
> The thing is that self-modifying code is pretty much an artifact of the dawn
> of computers, [...]
>
> It's just a Bad Idea.
Surely JIT compiling must count as self-modifying code.
Optimal code for bitblt (raster block transfers) in the Blit
Repeat, slightly modified, of a previous post that got
shunted to the attachment heap.
> I am curious if anyone on the list remembers much
> about the development of the first spell checkers in Unix?
Yes, intimately. They had no relationship to the PDP 10.
The first one was a fantastic tour de force by Bob Morris,
called "typo". Aside from the file "eign" of the very most common
English words, it had no vocabulary. Instead it evaluated the
likelihood that any particular word came from a source with the
same letter-trigram frequencies as the document as a whole. The
words were then printed in increasing order of likelihood. Typos
tended to come early in the list.
Typo, introduced in v3, was very popular until Steve Johnson wrote
"spell", a remarkably short shell script that (efficiently) looks
up a document's words in the wordlist of Webster's Collegiate
Dictionary, which we had on line. The only "real" coding he did
was to write a simple affix-stripping program to make it possible
to look up plurals, past tenses, etc. If memory serves, Steve's
program is described in Kernighan and Pike. It appeared in v5.
Steve's program was good, but the dictionary isn't an ideal source
for real text, which abounds in proper names and terms of art.
It also has a lot of rare words that don't pull their weight in
a spell checker, and some attractive nuisances, especially obscure
short words from Scots, botany, etc, which are more likely to
arise in everyday text as typos than by intent. Given the basic
success of Steve's program, I undertook to make a more useful
spelling list, along with more vigorous affix stripping (and a
stop list to avert associated traps, e.g. "presenation" =
pre+senate+ion"). That has been described in Bentley's "Programming
Pearls" and in http://www.cs.dartmouth.edu/~doug/spell.pdf.
Morris's program and mine labored under space constraints, so
have some pretty ingenious coding tricks. In fact Morris has
a patent on the way he counted frequencies of the 26^3 trigrams
in 26^3 bytes, even though the counts could exceed 255. I did
some heroic (and probabilistic) encoding to squeeze a 30,000
word dictionary into a 64K data space, without severely
affecting lookup time.
Doug
> From: "Nelson H. F. Beebe"
> The PDF URLs for bstj.bell-labs.com no longer work, and the ones for
> www.alcatel-lucent.com ... now redirect to an HTML page.
With any luck, someone scraped them before they went.
I've gotten in the habit of scraping all the Web content I look at, since it
has (as above) a distressing tendency to vapourize.
Noel
On 24 November 2017 at 10:11, Nemo <cym224(a)gmail.com> wrote:
> On 22 November 2017 at 03:48, <arnold(a)skeeve.com> wrote (in part):
>>> As a former developer and manager, I would be really pissed off if my
>>> programmers wasted their time on writing useless frippery instead of
>>> quality code, and I would certainly have a little chat with them...
>>
>> I think that this is totally appropriate for code being developed
>> for a paid product.
>
> I would say this is context-sensitive (industry, customers, ...). One
> version of MS Word had an animation of a cartoon monster crushing "WP'
> (somewhere in the credits, I recall).
>
> N.
I really must be more careful with replies. The above was meant for
TUHS, not just Arnold.
N.
I stumbled into a reddit post on Unix with the claim about early Unices only being accessed via printing terminals, and it suggested a question to me as to the first “glass teletype” or CRT terminal to be used with Unix.
Given the DEC-centric nature of early Unix I would guess perhaps a VT05 or VT52 but I’m keen to know if anyone from those early years recollects what happened and when regarding Unix terminal access alternatives aside from the venerable 33KSR or 33ASR.
Hi all,
An easter-egg in the version of man that is installed on the most popular
Linux distros has recently been discovered after being there for 6 years:
https://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gi…
It is for example discussed here:
https://news.ycombinator.com/item?id=15747313
It makes man print 'gimme gimme gimme' if called at "Half past twelve", as
in the ABBA song.
I check on BSD, but man seems to be a shell script on FreeBSD, so it's
immune from the easter egg:
https://github.com/freebsd/freebsd/blob/master/usr.bin/man/man.sh
Do you have any UNIX easter-egg stories ? Putting some in, or discovering
one...
Was this kind of humor tolerated in the professional settings where UNIX
first circulated, or was it frowned upon ?
> From: "Ron Natalie"
> After making a stink about it, Proteon removed (or just changed) the
> password.
We added a 'disable field service password' option to the configuration (for
those who wanted to keep FS out), changed the password (since the old one was
blown), and stored the new one in encrypted form - hence the message! :-)
Noel
Path: eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!adore2!news.iecc.com!.POSTED.news.iecc.com!nerds-end
From: Shoefoot <shoefoot(a)gmail.com>
Newsgroups: comp.compilers
Subject: Announcing the initial release of an XPL Compiler
Date: Tue, 21 Nov 2017 09:25:43 -0800 (PST)
Organization: Compilers Central
Sender: news(a)iecc.com
Approved: comp.compilers(a)iecc.com
Message-ID: <17-11-001(a)comp.compilers>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="19370"; mail-complaints-to="abuse(a)iecc.com"
Keywords: history, translator
Posted-Date: 21 Nov 2017 14:37:00 EST
X-submission-address: compilers(a)iecc.com
X-moderator-address: compilers-request(a)iecc.com
X-FAQ-and-archives: http://compilers.iecc.com
Xref: feeder.eternal-september.org comp.compilers:3921
Announcing the initial release of the XPL to C source translator.
The XPL language is a dialect of PL/I created by McKeeman, Horning and Wortman
and documented in their book "A Compiler Generator" published in 1970.
XPL is a procedural language with structured program flow. The language
supports integer arithmetic and logical operations. XPL supports dynamic
string variables and powerful character string manipulation features.
The compiler and the runtime are written in C. The compiler generates C source
so anyone with a working C compiler can compile and execute code written in XPL.
XPL and the BNF analyzer were the cutting edge of compiler technology 50 years
ago. This release includes both the compiler and the BNF analyzer written
in the late 60s.
You can download the source here:
https://sourceforge.net/projects/xpl-compiler
Warner Losh <imp(a)bsdimp.com> wrote:
> On Wed, Nov 22, 2017 at 9:11 AM, <arnold(a)skeeve.com> wrote:
>
> > Ian Zimmerman <itz(a)very.loosely.org> wrote:
> >
> > > On 2017-11-22 01:48, arnold(a)skeeve.com wrote:
> > >
> > > > Try:
> > > >
> > > > gawk --nostalgia
> > >
> > > ~$ gawk --nostalgia
> > > awk: bailing out near line 1
> > > Aborted
> > >
> > > Maybe it still needs a program?
> >
> > No, that was the joke. Early Unix awk used to say exactly that
> > message, on almost any problem, often followed by a core dump.
> >
> > (I never claimed the easter egg was non-lame.)
> >
>
> There were T-Shirts of this at early conferences as well. Showed a picture
> of a vaguely puffin-like bird baling of an airplane made up of what looked
> like ascii characters {}()|/... Google is unable find one though, so my
> memory may be rusty here...
>
> Warner
I have such a shirt. Maybe I can scan it. :-)
Arnold
On Thu, 23 Nov 2017, Matthew Geier wrote:
> There is a brake computer for the centre bogie and a microprocessor in
> the auxillary converter too.
Centre bogie? How does that work on curves? Or is it part of the
coupler?
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Recent commentary on porting led me to read the article on porting
UNIX to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf)
to support 5ESS development because the existing PDP11s were being
overwhelmed. I confess to not having this read this before and find
it interesting. Any recollections from anyone on the matter. And
whatever happened to it?
N.