> If anyone has any information about 'samuel' or 'cin',
> I would be delighted to hear from him or her.
cin appears in the v9 and v10 manuals. Thus if the
program is found in the wild, there should be no
compunction about adding it to the tuhs archive.
Doug
Due to having an actual NSA VAX...I think I should get NSAVAX ;)
Sent from my iPhone
> On Mar 30, 2017, at 23:13, Dave Horsfall via Uucp <uucp(a)minnie.tuhs.org> wrote:
>
>> On Thu, 30 Mar 2017, Kurt H Maier via Uucp wrote:
>>
>> kremvax and moskvax are online. What's the policy on uucp.map entries
>> for hosts that never really existed in the first place?
>
> Hmmm... I wouldn't mind having "kgbvax" in that case (I've relinquished
> "utzoo" to Henry Spencer himself). Or possibly "ciavax" or "fbivax"...
>
> --
> Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
I was just the other day apprised of the fact that
Warren Toomey had finally got permission to make public
sources from Eight, Ninth and Tenth Edition Unix. It
was Paul McJones from the Software Preservation Group
who made me aware of this because some months ago I was
in touch with him in regard to the status of source for
'pads/pi' which is on the SPG website. That was donated
by Bjorn Stroustrup in 2004 I believe, as an example of
a large C++ project, along with sources for 'cfront'.
I myself have been working on pads/pi in a desultory
fashion since 1990 when I left the Basser Department of
Computer Science at the University of Sydney; we had an
Eighth Edition licence, hence source code, and all of
the blit/jerq utilities.
I ported 'pads' to the Plan9 graphics model many years
ago, and finally started to port 'pi' to Solaris 11 a
couple of years ago. This works in a rudimentary
fashion, but needs a Dwarf interface.
Given that Bjorn Stroustrup released this code long ago
(a much later version than what I had), I daresay there
are no problems with its publication.
I have, however, also worked on 'samuel' and ported its
functionality to the Plan9 'sam'. 'samuel' does not
appear in any of the archives that Wareen Toomey has
made available, so I am wondering what its status may
be. It was written by John Puttress at the labs in the
late '80s, when he was apparently working under Ted
Kowalski. Ted Kowalski is also a 'person of interest'
because he wrote 'cin', the C interpreter, an interface
to which exists in 'samuel'. Ted Kowalski
unfortunately passed away some years ago and no-one
seems to know where the source is. It again, isn't in
any of the archives that Wareen Toomey has been able to
make available.
If anyone has any information about 'samuel' or 'cin',
I would be delighted to hear from him or her.
Bruce Ellis, who wrote 'cyntax', told me that he worked
on 'cin' a lot (in the '90s I think, when he worked at
Bell Labs) but it was succeeded by something named
'vice', about which I can find no information. Again, I
would be grateful for any information about this.
Regards,
Noel Hunt
Joerg Schilling:
This is done on a UNIX implementation that uses STREAMS.
SVr4 is such a UNIX.
======
I know that SVr4 has STREAMS (somewhat more elaborate than
the original stream I/O system, but the same principles),
and knew (though I'd forgotten) that Ethernet devices are
stream-capable. I did an implementation of the late
lamented Coraid's AoE protocol that took advantage of that.
Somewhat like the Research IP implementation, in fact:
there was an AoE line discipline to be pushed onto an
Ethernet device, coupled to devices in /dev/dsk and /dev/rdsk.
But is IP done that way in SVr4 (or at least in Solaris, its
most-visible descendant)? I had the impression that the
IP stack was more like the BSD one, with everything coupled
together within the kernel and a fundamentally socket interface.
I've never actually looked at the code, though.
Norman Wilson
Toronto ON
Arnold:
> Well, I'll take credit for pushing Norman yet again. :-)
ARGGH. That should have been
Well, I'll take credit for pushing Warren ...
^^^^^^
=====
I confess I didn't notice the fumble the first time.
But in fact Warren has had the dubious pleasure of
pushing me for something more than once. So just
think of it as another level of indirection.
Norman Wilson
Toronto ON
Ron Natalie:
It's a violation of the network layering concept to require or even allow
the user to bind the application data streams to a physical device.
=====
Oh, come on.
If you mean an applications programmer shouldn't have to wallow
in low-level network details, I agree. That's one of the reasons
I think the socket interface now standard in nearly every UNIX
is an abomination. It reminds me of the binary data structures
you had to assemble just to open a file in TOPS-10, only
ten times worse.
But if you mean it's a violation of layering for the kernel to
expose the pieces and let user-mode code to the work, I strongly
disagree. By that argument, the very idea of inetd is an abomination.
Possibly even the ifconfig command. And don't even get the
hypothetical you started on microkernels. User-mode code for device
drivers or file systems? Outrageous violation of layering! Send
in the New Jersey Inquisition!!
Or perhaps you misunderstand how it all works. Device files
for Ethernet devices, /dev/ip*, and so on are like those for
disk devices: you could allow anyone to read and write them,
but in practice you probably wouldn't: you'd restrict access
to the super-user and perhaps a special group to admit some
sort of privilege reduction (like the group allowed to read
disks on some systems, or to read /dev/kmem).
That parts of the stack are assembled in user mode is a feature,
not a bug.
The one glaring flaw, as I said, is that no permissions are
checked when pushing a stream line discipline onto a file.
I think that happened because when Dennis first wrote the
code, he was thinking about modules to implement canonical-tty
semantics, or to invoke the very-different Datakit networking
model. It's a fundamental flaw, though. I have had thoughts
about fixing it, but never enough time nor enough motivation.
(My technical mind is pretty much filled up by what I am
paid to do these days; I haven't done much hobby computing
in years.)
Norman Wilson
Toronto ON
Josh Good:
Which brings up a question I have: why didn't UNIX implement ethernet
network interfaces as file names in the filesystem? Was that "novelty" a
BDS development straying away from AT&T UNIX?
======
Remember that UNIX has long been a family of systems;
it's risky to make blanket statements!
The following is from memory; I haven't looked at this
stuff for a while and am a few kilometers from my
manuals as I type this. I can dig out the complete
story later if anyone wants it; for now, this is just
the flavour and the existence proof.
Research UNIX, once it supported Ethernet at all, did
so using devices in /dev; e.g. /dev/qe0[0-7] were the
conventional names for the first DEQNA/DELQA device on a
MicroVAX. There were eight subdevices per physical
device, each a channel that might receive datagrams
of a particular 16-bit type, programmed by an ioctl.
To set up what we now call an IP interface, one did
the following:
a. Open an unused channel for the proper Ethernet
physical device. (I think the devices were exclusive-
open to make this easier: open /dev/qe00, then qe01,
and so on until one succeeds.)
b. Issue the ioctl to set the desired datagram type,
usually 0x800.
c. Push the IP stream line discipline onto the open file.
d. Issue an ioctl to inform that IP instance of its
address and netmask.
Now datagrams of the specified type arriving on that
device are fed to the IP subsystem, and the IP
subsystem uses the IP address and mask and possibly
other information to decide which datagrams to route
to that IP instance, which sends them out that physical
device.
I forget how ARP and Ethernet encapsulation fit in.
I know that they were someone more naive early on,
and that in the 10/e systems I can now admit I have
running at home I made things a bit smarter and less
brittle. But that's the basic architecture.
So how does one actually make, say, a TCP connection?
Another layer of the same sort:
There are devices /dev/ipX, served by an IP device
driver that is part of the IP subsystem. Originally
minor device X was hard-connected to IP protocol X;
I later changed that to be ioctl-configured as well.
To make TCP usable:
a. Open /dev/ip6 (old school), or find an unused
/dev/ipX (again they are exclusive-open) and configure
it to accept protocol 6.
b. Push the TCP stream line discipline onto the
open file.
c. There are probably things one could then configure,
but I don't remember them offhand.
To make a TCP call, open an unused /dev/tcpNN device;
write something to it (or maybe it was an ioctl) with
the desired destination address; wait for an error or
success. On success, writes to the file descriptor send
to the network, encapsulated as a TCP stream; reads
receive.
To receive a TCP call, open an unused /dev/tcpNN device,
and write something (or ioctl) to say `I want to listen
on this local port.' Then read the file. When a call
arrives, you will read a message saying who's calling,
and what /dev/tcpXX device you should open to accept the
call.
Notice the general scheme: for both TCP and IP (and there
was a primitive UDP at one point, but it has fallen out
of use on my systems), the protocol implementation
comprises:
1. A line discipline: push it onto devices that will
transport your data.
2. A device driver: use those devices to send and
receive calls.
The two are inextricably coupled inside the operating
system, of course.
There are all sorts of unfortunate details surrounding
communications; e.g. the TCP code knows it is talking
to IP, and constructs datagrams with partly-filled-in
IP headers. (It is not clear one can do better than
that in practice, because the protocols themselves really
are linked, but I still think it's unfortunate.)
On the other hand, that the junctions between plumbing
are accessible makes some things very simple. I wrote
a PPP implementation in user mode, with no kernel
changes: to plug itself into IP, it just pushed the
IP line discipline onto one end of a pipe, and read
and wrote datagrams on the other. I later extended it
to PPPoE by having it open an Ethernet device set to
the proper datagram types (there is one for data and
another for connection setup).
On the other other hand, there are no permissions on
stream line disciplines, so an untrustworthy person
(if I allowed such on my systems) could push the IP
line discipline onto his own pipe and send whatever
datagrams he liked. This is decidedly a flaw.
Those familiar with the original stream-system
implementation have already spotted a lesser flaw:
the file descriptor with IP pushed on (or TCP, or
whatever) must remain open; when it is closed,
everything shuts down. In practice it is usually
useful to have a daemon listening to that file anyway;
that's a good way for the system to report errors or
confusion. In practice, TCP incalls and outcalls
all went through a special daemon anyway, so that
programs didn't have to be full of TCP-specific crap;
that's what Dave Presotto's `connection server' is
all about.
Norman Wilson
Toronto ON
Thanks for the hints, and whatnot... I got v8 running!
> ----------
> From: Tim Newsham
> Sent: Wednesday, March 29, 2017 7:50 AM
> To: David du Colombier
> Cc: The Eunuchs Hysterical Society
> Subject: Re: [TUHS] 8th Edition Research Unix on SIMH
>
> Would be great if someone scripted it up to make it dog-simple.
> Here's how I did it for v6: http://www.thenewsh.com/~newsham/myv6/README
> (I should do this, but I'm not sure I'll have time in the near future).
>
> On Tue, Mar 28, 2017 at 8:58 AM, David du Colombier < 0intro(a)gmail.com>
> wrote:
>
>
> Here are my notes to run 8th Edition Research Unix on SIMH.
>
> http://9legacy.org/9legacy/doc/simh/v8
>
> These notes are quite raw and unpolished, but should be
> sufficient to get Unix running on SIMH.
>
> Fell free to use, improve and share.
>
> --
> David du Colombier
>
>
>
>
>
> --
>
> Tim Newsham | www.thenewsh.com/~newsham | @newshtwit |
> thenewsh.blogspot.com
>
I am maintaining a BSD Mail derivative and one goal of the project
is to have the complete history of Unix mail and BSD Mail in the
repository.
There yet exists a [timeline] branch, which has been fed with data
from TUHS (thank you!) and CSRG; but it is coarse and further linear
history and so the new V8 and V10 cannot be inserted, i will need
to add new [unix-mail] and [bsd-Mail] (and maybe [bsd-csrg] with
all commits preserved, like Spinellis did so in the Unix-history
repository).
Thanks to TUHS the former can be almost completed, except that
there is no trace of 9th Edition mail. It would be fantastic if
finally this project could provide the complete history of Unix
mail. I would be thankful for informations where to get a copy of
9th Edition mail. Thank you.
P.S.: apologizing for capturing the other thread with such
a coarse message.
--steffen
All, today after some heroic efforts by numerous people over many years,
Nokia-Alcatel has issued this statement at
https://media-bell-labs-com.s3.amazonaws.com/pages/20170327_1602/statement%…
Statement Regarding Research Unix Editions 8, 9, and 10
Alcatel-Lucent USA Inc. (“ALU-USA”), on behalf of itself and Nokia
Bell Laboratories agrees, to the extent of its ability to do so, that it
will not assert its copyright rights with respect to any non-commercial
copying, distribution, performance, display or creation of derivative
works of Research Unix®1 Editions 8, 9, and 10. The foregoing does not
(i) transfer ownership of, or relinquish any, intellectual property rights
(including patent rights) of Nokia Corporation, ALU-USA or any of their
affiliates, (ii) grant a license to any patent, patent application,
or trademark of Nokia Corporation, ALU-USA. or any of their affiliates,
(iii) grant any third-party rights or licenses, or (iv) grant any rights
for commercial purposes. Neither ALU-USA. nor Nokia Bell Laboratories will
furnish or provided support for Research Unix Editions 8, 9, and 10, and
make no warranties or representations hereunder, including but not limited
to any warranty or representation that Research Unix Editions 8, 9, and
10 does not infringe any third party intellectual property rights or that
Research Unix Editions 8, 9, and 10 is fit for any particular purpose.
There are some issues around the copyright of third party material in
8th, 9th and 10th Editions Unix, but I'm going to bite the bullet and
make them available in the Unix Archive. I'll post details later today.
Cheers, Warren
