> From: Will Senn
> I know some of y'all were there (Noel)
I'm you're huckleberry (sort of; I didn't work on building the ARPANet, but I
built a number of boxes which were attached to it, later).
> I'm looking for the ARPANET Protocol Handbook
I have a hardcopy; the January 1978 version. (No, I can't scan it; it's
bound and 1/5" thick, and I don't wish to dwestroy it to scan it - but
see below).
> by Feinler, E. and Postel, J.
They were just the editors; most of the content was written by others.
It contains a whole raft of individual documents, most of them RFCs, and some
"NIC"s - similar documents available through the NIC, but generally only in
hardcopy form (like the earliest RFCs).
Many of the most important non-RFC ones are available here:
http://www.chiappa.net/~jnc/tech/arpanet.html
at the bottom of the page.
I will create a page which lists the contents of the APH, since I
gather it doesn't seem to be online. I'll email the list with the URL
once I get it up.
Any that are important, and not otherwise available online, I can scan; I've
done one (NIC 29588) in the past.
> If it's been superceded and the successor is available
There were _successor_ documents, like the IPH, but they covered entirely
different material. There likely was more then one version of the APH, as
inididual documents in it were added/modified; I have no confirmatorion
on that, though.
Noel
> From: Steve Shumaker
> NTRL has 3 published versions listed with two available as pdf downloads;
> https://ntrl.ntis.gov/NTRL/
Good find! The ADA052594 one is the one I have. The other one has older versions of
some things.
So I won't need to scan anything; but I will put up a machine-readable TOC.
Noel
When I try
http://www.openvms.digital.com/openvms/os/openvms-release-history.html
in archive.org I get the usual:
"Sorry.
This URL has been excluded from the Wayback Machine."
That's supposed to be because robots.txt prevents spidering so the
Internet Archive takes down the pages (even if they were previously
available, it seems).
But digital.com is back and if you go far enough down
https://digital.com/about/ you'll see that they know where the domain
came from.
So if whoever now controls digital.com could be persuaded to ask, would
the Internet Archive allow those digital.com pages back out into the
open again?
(I'm asking here because I think there's at least one person on this
list who might be able to provide a reasonably authoritative answer).
I did happen to notice that dec.com is back too ...
Antonio
--
Antonio Carlini
antonio at acarlini.com
Hi,
If this is off-topic, my apologies, but I know some of y'all were there
(Noel), so I'm hoping it's close enough to on-topic to garner a
successful response. I'm looking for the ARPANET Protocol Handbook by
Feinler, E. and Postel, J., published by SRI back in the day (revised
edition 1978) in an online format (pdf preferably, but anything readable
is fine. I came across the reference in RFC 790 - Assigned Numbers. If
it's been superceded and the successor is available, that would probably
work, too. Although, I prefer the earlier works for concision.
Regards,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
Hi all, i am looking for a loader rom set for my 21mx and does not seem to be around at the usual places, I am hoping to find a leed.
Here is what i am in need of.
12992L consisting of
12992-80011
91740-80070
91740-80071
91740-80072
there is a set of 91740 on bit savers but with a suffix of 67-69 ?
any help would be appreciated.
Thanks
Grant
Hello Rich,
I tried emailing you directly, but I don't think you got my message. I'm still here and looking for some ArcNET cards if any have turned up in your closet.
Thank You,
Jonathan
>Hello all,
> I had a HDD failure and I lost all of my emails going back 3 years.
>There was a gentleman that was looking for Arcnet cards. Could you
>please recontact me?
>GOD Bless and Thanks,
>rich!
Does anyone have any experience with UUCP on macOS or *BSD systems that
would be willing to help me figure something out?
I'm working on adding a macOS X system to my micro UUCP network and
running into some problems.
- uuto / uucp copy files from my non-root / non-(_)uucp user to the
UUCP spool. But the (demand based) ""call (pipe over SSH) is failing.
- running "uucico -r1 -s <remote system name> -f" as the (_)uucp user
(via sudo) works.
- I'm using the pipe port type and running things over an SSH connection.
- The (_)uucp user can ssh to the remote system as expected
without any problems or being prompted for a password. (Service
specific keys w/ forced command.)
I noticed that the following files weren't set UID or GID like they are
on Linux. But I don't know if that's a macOS and / or *BSD difference
when compared to Linux.
/usr/bin/uucp
/usr/bin/uuname
/usr/bin/uustat
/usr/bin/uux
/usr/sbin/uucico
/usr/sbin/uuxqt
Adding the set UID & GID bits allowed things to mostly work.
Aside: Getting the contemporary macOS so that I could edit the
(/usr/share/uucp/) sys & port files was a treat.
I figured that it was worth inquiring if anyone had any more experience
/ tips / gotchas before I go bending ~> breaking things even more.
Thank you.
--
Grant. . . .
unix || die
--
Grant. . . .
unix || die
Hi Paul,
Thanks for posting some Y2K fixes and enhancements for DECnet/E under
RSTS/E.
I've also used the Bitsavers source files for RSTS/E V10.1 to fix a Y2K bug
with handling RT-11 Y2k3 dates by the FIT program.
Are you interested in including my patched FIT.TSK for RSTS/E along with
your fixes. I could also provide my modified BASIC-Plus source code to FIT
too (but releasing this too may have copyright limitations).
Also I remember seeing a Y2K patch kit from Mentec for RSTS/E V10.1 on a
TK50 tape. I don't have a copy of it - but I think it also had some
additional Y2K fixes. You wouldn't also have some of these too?
Thanks in advance.
Tony
--
Tony Nicholson <tony.nicholson at computer.org>
On 6/28/20 6:48 PM, Grant Taylor wrote:
> Does anyone have any experience with UUCP on macOS or *BSD systems that
> would be willing to help me figure something out?
I ended up getting this to work.
I don't know if it was a macOSism or a *BSDism, but the root of the
problem was crossing between users via setuid / setgid in relation to
OpenSSH.
Two different versions of macOS behaved differently.
macOS Yosemite 10.10.5 runs the underlying ssh pipe command as the user
account that initiates the uucp / uuto / uux.
macOS Catalina 10.15.15 runs the underlying ssh pipe command as the
_uucp user, NOT the account that initiates the uucp / uuto / uux.
As such, on macOS Yosemite 10.10.5, I have to have the normal user's ssh
public key in the authorized_keys file on the remote system.
Conversely, on macOS Catalina 10.15.15, I have to have the _uucp user's
ssh public key in the authorized_keys file on the remote system.
I don't know why macOS Yosemite 10.10.5 and macOS Catalina 10.15.15 are
behaving differently, but they are.
These inconsistencies made identifying which client ssh config file --
nominally ~/.ssh/config -- was used cumbersome.
For some unknown reason, I couldn't rely on "~/" or defaults to specify
the _uucp user's key (Identity) file or the known_hosts file on macOS
Catalina 10.15.15, despite the fact that it was running as the _uucp
user. I ended up having to hard code the paths, as they were defaulting
to the original user account that initiated the uucp / uuto / uux.
I can only surmise that something is fundamentally different between
Linux and macOS in how it does things when changing user accounts via
setuid & setgid as I did not have any of these problems on multiple
Linux machines. I can further surmise that something is different
between macOS Yosemite 10.10.5 and macOS Catalina 10.15.15. I don't
know if this is related to System Integrity Protection or something else.
--
Grant. . . .
unix || die
--
Grant. . . .
unix || die