Preferring fewer emails, but not wanting to miss out on topics
that had not occurred to me, I would continue to subscribe
to the digest and not switch to a topic-filtering option.
Doug
On 7/6/20 7:30 PM, Greg 'groggy' Lehey wrote:
> People (not just Clem), when you change the topic, can you please
> modify the Subject: to match? I'm not overly interested in uucp,
> but editors are a completely different matter. I'm sure I'm not the
> only one, so many interested parties will miss these replies.
I see this type of change happen — in my not so humble opinion — /way/
/too/ /often/.
So, I'm wondering if people are interested in configuring TUHS and / or
COFF mailing list (Mailman) with topics. That way people could
subscribe to the topics that they are interested in and not receive
copies of topics they aren't interested in.
I'm assuming that TUHS and COFF are still on Mailman mailing lists and
that Warren would be amicable to such.
To clarify, it would still be the same mailing list(s) as they exist
today. They would just have the to be utilized option of picking
interesting topics. Where topics would be based on keywords in the
message body.
I'm just trying to gauge people's interest in this idea.
--
Grant. . . .
unix || die
Dave Horsfall:
A boss of mine insisted that we all learned "ed", because one day it might
be the only editor available to you after a crash; he was right...
====
Besides which, as The Blessed Manual said in every
Research edition:
ed is the standard text editor.
Norman Wilson
Toronto ON
(typing this in Toronto qed)
John Cowan:
Very much +1. Part of the trouble is that Gmail and similar clients don't
routinely show you the Subject: line to make it easy to edit it; you have
to take affirmative action when you want to change the subject matter.
====
Perhaps we should take a leaf from 1980s Rob Pike, and
just automatically change every message to be
Subject: The content of this message
(There is an actual story behind that, but I'll leave it
to Rob to tell.)
Norman Wilson
Toronto ON
When googling for File System Switch or Virtual File System most sources mention Sun NFS and SysVr3 as the earliest implementations. Some sources mention 8th Edition.
I did a (short) search on FSS/VFS in earlier, non-Unix OS’s (Tenex, Multics, CTSS, etc.), but none of those seem to have had a comparable concept.
Does anybody recall prior art (prior to 1984) in this area?
Paul
All, I just received this e-mail from a non-TUHS list member. If you have
an answer for Michael, could you reply to him and pop a cc here as well?
Thanks, Warren
----- Forwarded message from Michael Siegel <msi(a)malbolge.net> -----
Date: Sun, 14 Jun 2020 16:37:59 +0200
From: Michael Siegel <msi(a)malbolge.net>
To: wkt(a)tuhs.org
Subject: Origins and life of the pg pager
Hi there,
I'm trying to find out where the pg pager originated.
The research I've done so far vaguely suggests it came with one of the
System V versions, though Internet claims it to be “the name of the
historical utility on BSD UNIX systems” occasionally.[1]
I think System V because the source code of pg.c in the util-linux
package says that this utility is “a clone of the System V CRT paging
utility.”[2]
I'd also like to find out when pg was discarded and if it ever made it
into POSIX before that. Linux still has pg to the very day, but none of
the current major BSDs (Free/Net/Open) offer it. POSIX 2001, 2004
Edition lists it as an excluded utility.[3] I've not been able to get
the text of any prior POSIX documents. It seems they aren't freely
available.
Any ideas on how to proceed?
Best
Michael
[1] This one's from Wikipedia (https://en.wikipedia.org/wiki/Pg_(Unix))
but I've also found other sites stating the same.
[2]
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/text-ut…
[3] https://pubs.opengroup.org/onlinepubs/009696899/xrat/xcu_chap04.html
----- End forwarded message -----
Could someone point me to some information about s editor?
Googling didn't help
On Fri, Jul 3, 2020, 9:00 PM <tuhs-request(a)minnie.tuhs.org wrote:
> Send TUHS mailing list submissions to
> tuhs(a)minnie.tuhs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
> or, via email, send a message with subject or body 'help' to
> tuhs-request(a)minnie.tuhs.org
>
> You can reach the person managing the list at
> tuhs-owner(a)minnie.tuhs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of TUHS digest..."
>
>
> Today's Topics:
>
> 1. v7 uucp debugging help requested (Adam Thornton)
> 2. Re: v7 uucp debugging help requested (Clem Cole)
> 3. Re: v7 uucp debugging help requested (Grant Taylor)
> 4. Re: v7 uucp debugging help requested (John Cowan)
> 5. Re: v7 uucp debugging help requested (Clem Cole)
> 6. Re: v7 uucp debugging help requested (Clem Cole)
> 7. Re: v7 uucp debugging help requested (Norman Wilson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 3 Jul 2020 13:52:42 -0700
> From: Adam Thornton <athornton(a)gmail.com>
> To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org>
> Subject: [TUHS] v7 uucp debugging help requested
> Message-ID:
> <CAP2nic3UNxqi-obHwB5H+Ee+x5MKsd=eBrwhVbX+Ao3AgVPx=
> g(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> (if this is better suited for COFF, that'd be fine too)
>
> I've been trying to set up UUCP on my V7 system and its raspberry Pi host.
> This plus the "s" editor (already working) are really all that's needed to
> make this something pretty close to a daily driver, if all I wanted to do
> was write text files (which in some sense is all my job _is_, but to be
> fair I get a much more immediate feedback loop in my current environment).
>
> I was following
>
> https://github.com/jwbrase/pdp11-tools/blob/master/howtos/V7%20UUCP%20Insta…
> more or less--I had already rebuilt v7 with the DZ terminal driver and was
> using it for interactive sessions (albeit, before I started trying to get
> UUCP running, with 7-bit line discipline--but I've since changed that).
>
> I have 16 DZ lines, I've set them to 8-bit mode. They're working fine,
> because I can use them for terminal sessions.
>
> I've built UUCP, set a node name, and set it up on the pi.
>
> I can execute uucico to send files, and it, frustratingly, almost works.
>
> >From the Pi side, I see (with uulog):
>
> uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP)
> uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful
> uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful (protocol
> 'g' sending packet/window 64/3 receiving 64/7)
> uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending
> /home/adam/git/simh/sim_scsi.h (6780 bytes)
> uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting for
> packet
> uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent 86,
> resent 6, received 1
> uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0,
> order 0, remote rejects 0
> uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds 5440
> bytes 19 bps)
>
> So it's clearly logging in, and if I telnet in directly, the v7 end is
> starting uucico as expected:
>
> login: pi-uucp
> Password:
> Shere
>
> uulog -x on the v7 side has no output, and nothing ever appears in the
> spool directory, which I suspect is a direct result of the timeout waiting
> for packet.
>
> So my question is, what else do I do to debug this? Clearly the pi (Taylor
> UUCP) side is expecting something else--maybe an acknowledgement?--from the
> v7 side to let it know the transmission was successful.
>
> Any help would be appreciated.
>
> Adam
>
Grant Taylor:
I'm a little surprised that you're trying to use the 'g' protocol to
talk to v7. I thought the 'g' protocol came out later for TCP over
Ethernet connections. As such I wonder if UUCP on v7 supports the 'g'
protocol.
=====
You're mis-remembering. g was the original protocol,
intended for use over possibly-noisy serial lines (e.g.
modems on POTS). It does error checking of various
sorts with retransmission. I believe it is named g
after the protocol's original designer, Greg Chesson.
Later protocols meant to work over reliable, error-
checked links like a TCP/IP circuit were t and e.
Norman Wilson
Toronto ON
Date: Wed, 24 Jun 2020 14:31:34 -0400 (EDT)
From: norman(a)oclsc.org (Norman Wilson)
> Reaching outside of UNIX, RSX/11 used external supervisor-mode processes called ACPs (ancillary control processes) to implement file systems. I don't know exactly how they were plugged in, but I do know they were pluggable, so their interface must have constituted a file-system switch of some sort. RSX dates back into the 1970s. At some point in the latter part of the 1980s, Ralph Stamerjohn (a name instantly recognizable in the 16-bit DEC software world) gave a DECUS talk about implementing a remote file system through ACPs: a stub ACP on the client exporting RPCs over the network, a real one at the server end. I remember chatting with him about how that did and didn't resemble the way pjw had done it; interesting architectural comparison.
> Norman Wilson Toronto ON
I am still digesting all the inputs (thanks, all!)
The above post made me realise that the delineation of what is a FSS/VFS or not, is not so easy.
I did a little bit of reading, and the concept of an ACP arrived with RSX11D in May 1973, but only matured in RSX11M in November 1974. As I understand it, originally in RSX11 file system code was closely tied to the low-level device driver for each device. ACP’s separated the file system code from the device driver itself, and became separate processes.
In essence there were two switches: one switch into abstract devices, implemented in ACP code and one kernel switch to deal with hardware interfacing. The first is indeed like a file system switch (although still tied to specific devices).
Looking at this stuff made me realise that my retro machine of choice (the TI990) went through a similar evolution. In the early seventies it had a sort of abstract device switch that linked to individual ‘device service routines’ (drivers). Initially, these modelled batch oriented ‘logical units’ that tied to files at the job control level. Later (late 70’s), the ‘open’ command would carry a file name and the file system was delegated to the device service routine. Still later (say 1983) this was used for networked disks.
As several people have observed in this topic, indeed there appears to be a close relationship between a device switch and a file system switch.
