The Unix Heritage Society mailing list
 help / color / Atom feed
* Re: [TUHS] screen editors
@ 2020-01-08  7:39 Thomas Paulsen
  2020-01-08 15:58 ` Steve Nickolas
  2020-01-08 21:49 ` Dave Horsfall
  0 siblings, 2 replies; 28+ messages in thread
From: Thomas Paulsen @ 2020-01-08  7:39 UTC (permalink / raw)
  To: arnold; +Cc: tuhs

>What's funny is that in doing the work to get 'se' running on Georgia
>Tech's Vax, I had to learn vi.  By the time I was done, vi had become
>my main editor and had burned itself into my finger's ROMs.
I do ed/se occasionally for simple tasks, vim frequently , because it loads fast, and emacs for all bigger projects, beside liteide for golang. 



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-08  7:39 [TUHS] screen editors Thomas Paulsen
@ 2020-01-08 15:58 ` Steve Nickolas
  2020-01-08 23:41   ` Dave Horsfall
  2020-01-08 21:49 ` Dave Horsfall
  1 sibling, 1 reply; 28+ messages in thread
From: Steve Nickolas @ 2020-01-08 15:58 UTC (permalink / raw)
  To: Thomas Paulsen; +Cc: tuhs

On Wed, 8 Jan 2020, Thomas Paulsen wrote:

>> What's funny is that in doing the work to get 'se' running on Georgia
>> Tech's Vax, I had to learn vi.  By the time I was done, vi had become
>> my main editor and had burned itself into my finger's ROMs.
> I do ed/se occasionally for simple tasks, vim frequently , because it 
> loads fast, and emacs for all bigger projects, beside liteide for 
> golang.

For what it's worth, I use nano. (Yeah, I know, not very unixy.)

I think the first fullscreen text editor I used was FrEdWriter (by Paul 
Lutus and Al Rogers) for the Apple ][.  After that it was IBM's E.  I 
haven't really used vi *or* emacs much.

-uso.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-08  7:39 [TUHS] screen editors Thomas Paulsen
  2020-01-08 15:58 ` Steve Nickolas
@ 2020-01-08 21:49 ` Dave Horsfall
  2020-01-08 22:01   ` Clem Cole
  2020-01-10  8:13   ` markus schnalke
  1 sibling, 2 replies; 28+ messages in thread
From: Dave Horsfall @ 2020-01-08 21:49 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Wed, 8 Jan 2020, Thomas Paulsen wrote:

> I do ed/se occasionally for simple tasks, vim frequently , because it loads fast, and emacs for all bigger projects, beside liteide for golang.

I had a boss once who insisted that all his staff learn "ed", because one 
day it might be the only editor available; he was right...

-- Dave

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-08 21:49 ` Dave Horsfall
@ 2020-01-08 22:01   ` Clem Cole
  2020-01-17 23:38     ` Dave Horsfall
  2020-01-10  8:13   ` markus schnalke
  1 sibling, 1 reply; 28+ messages in thread
From: Clem Cole @ 2020-01-08 22:01 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

On Wed, Jan 8, 2020 at 4:50 PM Dave Horsfall <dave@horsfall.org> wrote:

> I had a boss once who insisted that all his staff learn "ed", because one
> day it might be the only editor available; he was right...
>
I always suggest it.  It means you can use sed and lot of other tools
pretty quick.
And if you know ed, you can use almost anything close to it.   I hated
DOS's edlin but if I was stuck it was close enough.

Although the famous ? error from the original version was annoying.

Truly, I still suggest that any modern user, take Rob and Brian's book and
until you can do the exercises without think about it, you really are not
yet comfortable with UNIX.  I even recommend at least read and looking at
the chapter on nroff.

Clem

[-- Attachment #2: Type: text/html, Size: 1823 bytes --]

<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 8, 2020 at 4:50 PM Dave Horsfall &lt;<a href="mailto:dave@horsfall.org">dave@horsfall.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I had a boss once who insisted that all his staff learn &quot;ed&quot;, because one <br>
day it might be the only editor available; he was right...<br></blockquote><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">I always suggest it.  It means you can use sed and lot of other tools pretty quick.</span> </div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">And if you know ed, you can use almost anything close to it.   I hated DOS&#39;s edlin but if I was stuck it was close enough.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Although the famous ? error from the original version was annoying.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Truly, I still suggest that any modern user, take Rob and Brian&#39;s book and until you can do the exercises without think about it, you really are not yet comfortable with UNIX.  I even recommend at least read and looking at the chapter on nroff.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Clem</div><br></div></div></div>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-08 15:58 ` Steve Nickolas
@ 2020-01-08 23:41   ` Dave Horsfall
  2020-01-09  1:43     ` Nemo Nusquam
  0 siblings, 1 reply; 28+ messages in thread
From: Dave Horsfall @ 2020-01-08 23:41 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Wed, 8 Jan 2020, Steve Nickolas wrote:

> I think the first fullscreen text editor I used was FrEdWriter (by Paul 
> Lutus and Al Rogers) for the Apple ][.  After that it was IBM's E.  I 
> haven't really used vi *or* emacs much.

First I used was DEC's "EDT" and could never get used to the "gold" key...

Fortunately I was not required to use RSX (or was it VMS?) as I was 
strictly a PDP Unix bod at the time; I was just curious.

-- Dave

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-08 23:41   ` Dave Horsfall
@ 2020-01-09  1:43     ` Nemo Nusquam
  0 siblings, 0 replies; 28+ messages in thread
From: Nemo Nusquam @ 2020-01-09  1:43 UTC (permalink / raw)
  To: tuhs

On 01/08/20 18:41, Dave Horsfall wrote:
> [...]
> First I used was DEC's "EDT" and could never get used to the "gold" 
> key...
>
> Fortunately I was not required to use RSX (or was it VMS?) as I was 
> strictly a PDP Unix bod at the time; I was just curious.
>
> -- Dave

It was VMS and I had forgotten all about the Gold Key until now.

N.


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-08 21:49 ` Dave Horsfall
  2020-01-08 22:01   ` Clem Cole
@ 2020-01-10  8:13   ` markus schnalke
  2020-01-10  8:17     ` U'll Be King of the Stars
                       ` (3 more replies)
  1 sibling, 4 replies; 28+ messages in thread
From: markus schnalke @ 2020-01-10  8:13 UTC (permalink / raw)
  To: tuhs

Hoi.

[2020-01-09 08:49] Dave Horsfall <dave@horsfall.org>
> On Wed, 8 Jan 2020, Thomas Paulsen wrote:
> 
> > I do ed/se occasionally for simple tasks, vim frequently ,
> > because it loads fast, and emacs for all bigger projects,
> > beside liteide for golang.
> 
> I had a boss once who insisted that all his staff learn "ed",
> because one day it might be the only editor available; he was
> right...

On a modern Linux system, ed isn't even installed ... 8-O

I was quite shocked when I first realized that I had to do
`apt-get install ed' to have it available ... on a Unix-like
system. But on the other hand, who of today's users is even
capable of exiting it?!


On my own systems I like to install Heirlomm ed, which I have
outfactored from the Heirloom tools package. If you want to
actually use it every now and then, Gunnar's ed is much more
usable than GNU ed ... which seems to be more a demonstration
object than actually a programmer's editor.


Anyways, I'm having a great pleasure reading those historic
spotlights on editors these days. :-)


meillo

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-10  8:13   ` markus schnalke
@ 2020-01-10  8:17     ` U'll Be King of the Stars
  2020-01-11 19:58       ` markus schnalke
  2020-01-10 13:41     ` [TUHS] screen editors / machine load Mike Markowski
                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 28+ messages in thread
From: U'll Be King of the Stars @ 2020-01-10  8:17 UTC (permalink / raw)
  To: markus schnalke, tuhs

On 10/01/2020 08:13, markus schnalke wrote:
> GNU ed [...] seems to be more a demonstration
> object than actually a programmer's editor.

Hi Markus, in what way is GNU ed a "demonstration object"?

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors / machine load
  2020-01-10  8:13   ` markus schnalke
  2020-01-10  8:17     ` U'll Be King of the Stars
@ 2020-01-10 13:41     ` Mike Markowski
  2020-01-10 13:56       ` Otto Moerbeek
  2020-01-10 15:00       ` Mary Ann Horton
  2020-01-10 15:31     ` [TUHS] screen editors Nemo Nusquam
  2020-01-10 15:58     ` Theodore Y. Ts'o
  3 siblings, 2 replies; 28+ messages in thread
From: Mike Markowski @ 2020-01-10 13:41 UTC (permalink / raw)
  To: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]

[2020-01-09 08:49] Dave Horsfall <dave@horsfall.org>
> > I had a boss once who insisted that all his staff learn "ed",
> > because one day it might be the only editor available; he was
> > right...
>

I first used Unix on a pdp-11/70 in 1981, first year at university.  My
professor stopped by the computing center to see how his students were
doing - super nice of him and a perk to pre-PC times! - and was showing me
something or other regarding Unix.  I had only used ed to that point and
seeing him fire up vi was practically sci-fi to me.  He showed me a few
commands and vowed me to secrecy for fear if all students started using it,
it would bring the 11/70 to its knees.  Were multiple vi sessions really
such a potential burden to the machine?  I wouldn't think so with the slow
nature of human i/o, yet there certainly were times when the pdp-11/70
crashed as project due dates loomed closer and closer!

Also, I very much enjoy this list.  As an EE I use Unix-like OSes as a tool
rather being a builder of the tool like many here.  So I don't have the
deep background to contribute to the collective history, but I'm on the
sidelines enjoying the show.  As a brief tie-in to the editor comparisons,
I do a lot of DSP work for RF systems these days.  Python makes it quick
and easy to try new math, but has a maddening requirement that indentation
be strictly tabs or strictly spaces.  Text window pasting into a tab
indented python file wreaks havoc.  vim yank/put between split windows
retains the type of white space and lets me use my vi muscle memory.

Happy 2020,
Mike Markowski

[-- Attachment #2: Type: text/html, Size: 2017 bytes --]

<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[2020-01-09 08:49] Dave Horsfall &lt;<a href="mailto:dave@horsfall.org" target="_blank">dave@horsfall.org</a>&gt;<br>
&gt; I had a boss once who insisted that all his staff learn &quot;ed&quot;,<br>
&gt; because one day it might be the only editor available; he was<br>
&gt; right...<br></blockquote><div><br></div><div>I first used Unix on a pdp-11/70 in 1981, first year at university.  My professor stopped by the computing center to see how his students were doing - super nice of him and a perk to pre-PC times! - and was showing me something or other regarding Unix.  I had only used ed to that point and seeing him fire up vi was practically sci-fi to me.  He showed me a few commands and vowed me to secrecy for fear if all students started using it, it would bring the 11/70 to its knees.  Were multiple vi sessions really such a potential burden to the machine?  I wouldn&#39;t think so with the slow nature of human i/o, yet there certainly were times when the pdp-11/70 crashed as project due dates loomed closer and closer!</div><div><br></div><div>Also, I very much enjoy this list.  As an EE I use Unix-like OSes as a tool rather being a builder of the tool like many here.  So I don&#39;t have the deep background to contribute to the collective history, but I&#39;m on the sidelines enjoying the show.  As a brief tie-in to the editor comparisons, I do a lot of DSP work for RF systems these days.  Python makes it quick and easy to try new math, but has a maddening requirement that indentation be strictly tabs or strictly spaces.  Text window pasting into a tab indented python file wreaks havoc.  vim yank/put between split windows retains the type of white space and lets me use my vi muscle memory.<br></div><div><br></div><div>Happy 2020,</div><div>Mike Markowski<br></div></div></div>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors / machine load
  2020-01-10 13:41     ` [TUHS] screen editors / machine load Mike Markowski
@ 2020-01-10 13:56       ` Otto Moerbeek
  2020-01-10 15:00       ` Mary Ann Horton
  1 sibling, 0 replies; 28+ messages in thread
From: Otto Moerbeek @ 2020-01-10 13:56 UTC (permalink / raw)
  To: Mike Markowski; +Cc: TUHS main list

On Fri, Jan 10, 2020 at 08:41:53AM -0500, Mike Markowski wrote:

> [2020-01-09 08:49] Dave Horsfall <dave@horsfall.org>
> > > I had a boss once who insisted that all his staff learn "ed",
> > > because one day it might be the only editor available; he was
> > > right...
> >
> 
> I first used Unix on a pdp-11/70 in 1981, first year at university.  My
> professor stopped by the computing center to see how his students were
> doing - super nice of him and a perk to pre-PC times! - and was showing me
> something or other regarding Unix.  I had only used ed to that point and
> seeing him fire up vi was practically sci-fi to me.  He showed me a few
> commands and vowed me to secrecy for fear if all students started using it,
> it would bring the 11/70 to its knees.  Were multiple vi sessions really
> such a potential burden to the machine?  I wouldn't think so with the slow
> nature of human i/o, yet there certainly were times when the pdp-11/70
> crashed as project due dates loomed closer and closer!
> 
> Also, I very much enjoy this list.  As an EE I use Unix-like OSes as a tool
> rather being a builder of the tool like many here.  So I don't have the
> deep background to contribute to the collective history, but I'm on the
> sidelines enjoying the show.  As a brief tie-in to the editor comparisons,
> I do a lot of DSP work for RF systems these days.  Python makes it quick
> and easy to try new math, but has a maddening requirement that indentation
> be strictly tabs or strictly spaces.  Text window pasting into a tab
> indented python file wreaks havoc.  vim yank/put between split windows
> retains the type of white space and lets me use my vi muscle memory.
> 
> Happy 2020,
> Mike Markowski

In my first year at university (1984) we had a VAX-11/750 running
4.1BSD with too many students. We had to switch to ex once in a while
to get any editing done. I believe it was not only vi itself that was
causing the load, it was also running many terminals in raw mode that
killed performance.

	-Otto


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors / machine load
  2020-01-10 13:41     ` [TUHS] screen editors / machine load Mike Markowski
  2020-01-10 13:56       ` Otto Moerbeek
@ 2020-01-10 15:00       ` Mary Ann Horton
  2020-01-10 15:48         ` Clem Cole
  1 sibling, 1 reply; 28+ messages in thread
From: Mary Ann Horton @ 2020-01-10 15:00 UTC (permalink / raw)
  To: tuhs

Yes, it was a real concern. Physical memory on the shared PDP-11 was 
limited, and if everyone had a separate copy of vi running the machine 
would swap itself silly.

This only mattered if everyone had their own separate copy of vi 
installed. The fix was to put vi in a single system directory, such as 
/usr/ucb or /exptools. The instruction part of its memory would be 
shared among all the users, resulting in much less swapping.

In the early days, people tended to have their own personal copy because 
the Berkeley tools did not come standard with UNIX, especially at Bell 
Labs. That was one of the main motivations for Exptools (the 
"experimental tools"), which were basically 2BSD's applications and some 
other tools like Warren Montgomery's emacs. Disk space and people's time 
spend installing were also good reasons.

     Mary Ann

On 1/10/20 5:41 AM, Mike Markowski wrote:
> seeing him fire up vi was practically sci-fi to me.  He showed me a 
> few commands and vowed me to secrecy for fear if all students started 
> using it, it would bring the 11/70 to its knees.  Were multiple vi 
> sessions really such a potential burden to the machine?  I wouldn't 
> think so with the slow nature of human i/o, yet there certainly were 
> times when the pdp-11/70 crashed as project due dates loomed closer 
> and closer!

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-10  8:13   ` markus schnalke
  2020-01-10  8:17     ` U'll Be King of the Stars
  2020-01-10 13:41     ` [TUHS] screen editors / machine load Mike Markowski
@ 2020-01-10 15:31     ` Nemo Nusquam
  2020-01-10 16:04       ` Clem Cole
  2020-01-10 17:10       ` Dan Cross
  2020-01-10 15:58     ` Theodore Y. Ts'o
  3 siblings, 2 replies; 28+ messages in thread
From: Nemo Nusquam @ 2020-01-10 15:31 UTC (permalink / raw)
  To: tuhs

On 01/10/20 03:13, markus schnalke wrote (in part):
> Hoi.
[...]
> Anyways, I'm having a great pleasure reading those historic
> spotlights on editors these days. :-)
In earlier days, my wife was given email by telnetting to an SGI system 
and using elm.  One day, I visited her office as she was composing a 
message.  Intrigued, I asked her what the editor was. She did not know 
and pointed to her cheat-sheet listing editor commands.  One was ^X^C to 
exit-and-send.  She is not a programmer and I was a bit surprised at 
their choice.

N.

>
>
> meillo


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors / machine load
  2020-01-10 15:00       ` Mary Ann Horton
@ 2020-01-10 15:48         ` Clem Cole
  2020-01-10 22:18           ` Adam Thornton
  0 siblings, 1 reply; 28+ messages in thread
From: Clem Cole @ 2020-01-10 15:48 UTC (permalink / raw)
  To: Mary Ann Horton; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 3191 bytes --]

On Fri, Jan 10, 2020 at 10:00 AM Mary Ann Horton <mah@mhorton.net> wrote:

> Yes, it was a real concern. Physical memory on the shared PDP-11 was
> limited, and if everyone had a separate copy of vi running the machine
> would swap itself silly.
>
> This only mattered if everyone had their own separate copy of vi
> installed. The fix was to put vi in a single system directory, such as
> /usr/ucb or /exptools. The instruction part of its memory would be
> shared among all the users, resulting in much less swapping.
>
Actually it was much worse than that...

What Mary Ann points out was mostly true of your PDP-11 had DH11's
installed; which had deeper hardware buffering and 16 character DMA on
output.   But these were expensive from DEC and also took up a 'full system
unit' in the CPU for 16 lines.   Until Able (much later) released the
DMAX-11 (*a.k.a.* DH/DM) product of a DH11 clone on a single board, many
university sites did not use them; but used multiple DL-11/KL-11's instead.

If your system was configured with DL/KL11s or similar (CMU had it's own
called 'ASLIs' - a synchronous line interfaces) each character took one
interrupt for each either input or output.  Moreover, the UARTS that DEC
used which were made by Western Digital had 2 >>or less<< characters of
input buffering, so they could drop chars[1].  The ASLI's used a later chip
with a slightly better buffer IIRC but I admit I've forgotten the details
(Jim Tetter probably remembers them).

So if you had a single line, the interrupt load was huge on a PDP-11.  For
this reason, a lot of sites limited glass TTYs to speeds like 2400 or 4800
baud, not the full 9600.

DEC later released the DZ-11 which worked on units of 8 ports per board.
Unfortunately, it was not DMA and the buffering was still pretty shallow.
 Joy did a lot of work on 4.1BSD in the DZ driver to cut down the
interrupts because 9600 baud DZ lines could swamp a vax and when running
the BerkNet between systems (before UCB had ethernet), 9600 baud serial
lines were standard.


[1]  Two things
 A) The original WD UART chip had very limited buffering.   The timing was
such that as high rates it could not empty accept a second character
without the first being overwritten.  This was a long-standing issue for
many UARTs long in the 1990s.  The original chip NS built and IBM used on
the PC (the NS8250) was notorious for the same problem.  By the time of
Motorola's 6881, it had 8 characters of buffering IIRC.

B) As I understand the history, Gordon developed the original idea of the
UART at DEC for the PDP-1. But I'm not sure of the patent details. He does
not list the UART patent on his web site although he does mention inventing
it.   I have been under the impression CMU was somehow mixed up in the
patent and licensing of it, *i.e.* WD got the license from CMU to make them
not DEC; which was part of why we had the ASLI's.  Again, IIRC, we got the
UART chips from WD at cost and could make the ALSI's locally much cheaper
than DL-11s.  >>I think<< the story was that one of Gordon's student's
designed a chip, which WD fabbed and licensed.  Before that DEC had built
UARTs on boards from transistors and later logic gates.

[-- Attachment #2: Type: text/html, Size: 5009 bytes --]

<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 10, 2020 at 10:00 AM Mary Ann Horton &lt;<a href="mailto:mah@mhorton.net">mah@mhorton.net</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yes, it was a real concern. Physical memory on the shared PDP-11 was <br>
limited, and if everyone had a separate copy of vi running the machine <br>
would swap itself silly.<br>
<br>
This only mattered if everyone had their own separate copy of vi <br>
installed. The fix was to put vi in a single system directory, such as <br>
/usr/ucb or /exptools. The instruction part of its memory would be <br>
shared among all the users, resulting in much less swapping.<br></blockquote><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">Actually it was much worse than that...</span></div><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">What Mary Ann points out was mostly true of your PDP-11 had DH11&#39;s installed; which had deeper hardware buffering and 16 character DMA on output.   But these were expensive from DEC and also took up a &#39;full system unit&#39; in the CPU for 16 lines.</span> <span class="gmail_default" style="font-family:arial,helvetica,sans-serif">  Until Able (much later) released the DMAX-11 (<i>a.k.a.</i> DH/DM) product of a DH11 clone on a single board, many university sites did not use them; but used multiple DL-11/KL-11&#39;s instead.</span></div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">If your system was configured with DL/KL11s or similar (CMU had it&#39;s own called &#39;ASLIs&#39; - a synchronous line interfaces) each character took one interrupt for each either input or output.  Moreover, the UARTS that DEC used which were made by Western Digital had 2 &gt;&gt;or less&lt;&lt; characters of input buffering, so they could drop chars[1].  The ASLI&#39;s used a later chip with a slightly better buffer IIRC but I admit I&#39;ve forgotten the details (Jim Tetter probably remembers them).</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">So if you had a single line, the interrupt load was huge on a PDP-11.  For this reason, a lot of sites limited glass TTYs to speeds like 2400 or 4800 baud, not the full 9600.   </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">DEC later released the DZ-11 which worked on units of 8 ports per board.  Unfortunately, it was not DMA and the buffering was still pretty shallow.   Joy did a lot of work on 4.1BSD in the DZ driver to cut down the interrupts because 9600 baud DZ lines could swamp a vax and when running the BerkNet between systems (before UCB had ethernet), 9600 baud serial lines were standard.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">[1]  Two things</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"> A) The original WD UART chip had very limited buffering.   The timing was such that as high rates it could not empty accept a second character without the first being overwritten.  This was a long-standing issue for many UARTs long in the 1990s.  The original chip NS built and IBM used on the PC (the NS8250) was notorious for the same problem.  By the time of Motorola&#39;s 6881, it had 8 characters of buffering IIRC.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">B) As I understand the history, Gordon developed the original idea of the UART at DEC for the PDP-1. But I&#39;m not sure of the patent details. He does not list the UART patent on his web site although he does mention inventing it.   I have been under the impression CMU was somehow mixed up in the patent and licensing of it, <i>i.e.</i> WD got the license from CMU to make them not DEC; which was part of why we had the ASLI&#39;s.  Again, IIRC, we got the UART chips from WD at cost and could make the ALSI&#39;s locally much cheaper than DL-11s.  &gt;&gt;I think&lt;&lt; the story was that one of Gordon&#39;s student&#39;s designed a chip, which WD fabbed and licensed.  Before that DEC had built UARTs on boards from transistors and later logic gates.<br></div><br></div></div></div>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-10  8:13   ` markus schnalke
                       ` (2 preceding siblings ...)
  2020-01-10 15:31     ` [TUHS] screen editors Nemo Nusquam
@ 2020-01-10 15:58     ` Theodore Y. Ts'o
  3 siblings, 0 replies; 28+ messages in thread
From: Theodore Y. Ts'o @ 2020-01-10 15:58 UTC (permalink / raw)
  To: markus schnalke; +Cc: tuhs

On Fri, Jan 10, 2020 at 09:13:04AM +0100, markus schnalke wrote:
> 
> I was quite shocked when I first realized that I had to do
> `apt-get install ed' to have it available ... on a Unix-like
> system. But on the other hand, who of today's users is even
> capable of exiting it?!

For what it's worth, I regularly edit configuration files and shell
scripts using /bin/ed in environments where I can't use (due to
terminal limitations) or can't fit a more sophisticated editors.
These days this is typically in small appliance VM's.

I've also been known to do things like this in shell scripts[1]:

ed /etc/lighttpd/lighttpd.conf <<EOF
/^server.document-root/s/^/#/p
/^index-file.names/s/^/#/p
/^include_shell.*create-mime/s/^/#/p
w
q
EOF

[1] https://github.com/tytso/xfstests-bld/blob/master/kvm-xfstests/test-appliance/gce-xfstests-bld.sh

And for years, I knew how to exit ed and emacs, but had trouble
exiting vi.  :-)

					- Ted
					




> 
> 
> On my own systems I like to install Heirlomm ed, which I have
> outfactored from the Heirloom tools package. If you want to
> actually use it every now and then, Gunnar's ed is much more
> usable than GNU ed ... which seems to be more a demonstration
> object than actually a programmer's editor.
> 
> 
> Anyways, I'm having a great pleasure reading those historic
> spotlights on editors these days. :-)
> 
> 
> meillo

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-10 15:31     ` [TUHS] screen editors Nemo Nusquam
@ 2020-01-10 16:04       ` Clem Cole
  2020-01-10 17:10       ` Dan Cross
  1 sibling, 0 replies; 28+ messages in thread
From: Clem Cole @ 2020-01-10 16:04 UTC (permalink / raw)
  To: Nemo Nusquam; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam <cym224@gmail.com> wrote:

> Intrigued, I asked her what the editor was. She did not know
> and pointed to her cheat-sheet listing editor commands.  One was ^X^C to
> exit-and-send.  She is not a programmer and I was a bit surprised at
> their choice.
>
Similar fun Unix/ITS emacs story.

In the mid/later 1970s, my least techie sister Cynthia was/is a concert
harpist with a degree from Oberlin's conservatory.  She can type extremely
fast as she has super manual dexterity.  But playing the harp is not
something that paid a great deal or offered her 'regular' gigs, so to make
the monthly rent she got a job working at MIT as Ron Rivest's admin .  She
typed all the RSA papers in emacs and tex on one of the MIT systems.  She
did not know any better, that's what they gave her/taught her.   When she
later would look for a job at other places and they would ask her, 'do you
know how to use a Wang System' and she would say: "No, I know emacs" [for
the younger set, longer before MS-Word, "Wang" was synonymous with "word
processor" and many/most commercial offices had a 'Wang unit" for the folks
doing the typing.].

 [As a side note when she found out the elevators were hacked and
controlled by the student's different computers, she stopped using them and
would take the stairs in Tech Sq].

[-- Attachment #2: Type: text/html, Size: 2373 bytes --]

<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam &lt;<a href="mailto:cym224@gmail.com">cym224@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Intrigued, I asked her what the editor was. She did not know <br>
and pointed to her cheat-sheet listing editor commands.  One was ^X^C to <br>
exit-and-send.  She is not a programmer and I was a bit surprised at <br>
their choice.<br></blockquote><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">Similar fun Unix/ITS emacs story.</span></div><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">In the mid/later 1970s, my least techie sister Cynthia was/is a concert harpist with a degree from Oberlin&#39;s conservatory.  She can type extremely fast as she has super manual dexterity.  But playing the harp is not something that paid a great deal or offered her &#39;regular&#39; gigs, so to make the monthly rent </span><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">she got a job working at MIT as Ron Rivest&#39;s admin .  She typed all the RSA papers in emacs and tex on one of the MIT systems.  She did not know any better, that&#39;s what they gave her/taught her.   When she later would look for a job at other places and they would ask her, &#39;do you know how to use a Wang System&#39; and she would say: &quot;No, I know emacs&quot; [for the younger set, longer before MS-Word, &quot;Wang&quot; was synonymous with &quot;word processor&quot; and many/most commercial offices had a &#39;Wang unit&quot; for the folks doing the typing.].</span></div><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> [As a side note when she found out the elevators were hacked and controlled by the student&#39;s different computers, she stopped using them and would take the stairs in Tech Sq].</span></div></div></div>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-10 15:31     ` [TUHS] screen editors Nemo Nusquam
  2020-01-10 16:04       ` Clem Cole
@ 2020-01-10 17:10       ` Dan Cross
  2020-01-10 17:18         ` Steve Nickolas
  1 sibling, 1 reply; 28+ messages in thread
From: Dan Cross @ 2020-01-10 17:10 UTC (permalink / raw)
  To: Nemo Nusquam; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam <cym224@gmail.com> wrote:

> In earlier days, my wife was given email by telnetting to an SGI system
> and using elm.  One day, I visited her office as she was composing a
> message.  Intrigued, I asked her what the editor was. She did not know
> and pointed to her cheat-sheet listing editor commands.  One was ^X^C to
> exit-and-send.  She is not a programmer and I was a bit surprised at
> their choice.
>

Hmm, I'm actually kind of not. Starting users off with a modal editor (that
starts in command mode, no less!) can be surprising for novices; with
emacs, at least you can start typing text and, well, see text.

I think that one of the smartest things Marc Crispin ever did was write
`pico` to go with `pine`. A simple editor targeted at the novice was really
useful for casual and/or new users, particularly as the Internet spread and
an account on a Unix system was the default introduction to email etc for
so many.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 1364 bytes --]

<div dir="ltr"><div dir="ltr">On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam &lt;<a href="mailto:cym224@gmail.com">cym224@gmail.com</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In earlier days, my wife was given email by telnetting to an SGI system <br>
and using elm.  One day, I visited her office as she was composing a <br>
message.  Intrigued, I asked her what the editor was. She did not know <br>
and pointed to her cheat-sheet listing editor commands.  One was ^X^C to <br>
exit-and-send.  She is not a programmer and I was a bit surprised at <br>
their choice.<br></blockquote><div><br></div><div>Hmm, I&#39;m actually kind of not. Starting users off with a modal editor (that starts in command mode, no less!) can be surprising for novices; with emacs, at least you can start typing text and, well, see text.</div><div><br></div><div>I think that one of the smartest things Marc Crispin ever did was write `pico` to go with `pine`. A simple editor targeted at the novice was really useful for casual and/or new users, particularly as the Internet spread and an account on a Unix system was the default introduction to email etc for so many.</div><div><br></div><div>        - Dan C.</div><div><br></div></div></div>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-10 17:10       ` Dan Cross
@ 2020-01-10 17:18         ` Steve Nickolas
  2020-01-18  1:55           ` Michael Parson
  0 siblings, 1 reply; 28+ messages in thread
From: Steve Nickolas @ 2020-01-10 17:18 UTC (permalink / raw)
  To: Dan Cross; +Cc: TUHS main list

On Fri, 10 Jan 2020, Dan Cross wrote:

> On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam <cym224@gmail.com> wrote:
>
>> In earlier days, my wife was given email by telnetting to an SGI system
>> and using elm.  One day, I visited her office as she was composing a
>> message.  Intrigued, I asked her what the editor was. She did not know
>> and pointed to her cheat-sheet listing editor commands.  One was ^X^C to
>> exit-and-send.  She is not a programmer and I was a bit surprised at
>> their choice.
>>
>
> Hmm, I'm actually kind of not. Starting users off with a modal editor (that
> starts in command mode, no less!) can be surprising for novices; with
> emacs, at least you can start typing text and, well, see text.

This is one of the reasons I liked E when I first used it: it was modal, 
but it started in edit mode.  (Also you KNEW what mode you were in, which 
I understand isn't always the case with vi, although it usually is in the 
clones iirc?)

> I think that one of the smartest things Marc Crispin ever did was write
> `pico` to go with `pine`. A simple editor targeted at the novice was really
> useful for casual and/or new users, particularly as the Internet spread and
> an account on a Unix system was the default introduction to email etc for
> so many.

And I still use nano - which is a rewrite of pico.

pico Just Works(R)(TM)(C), and it's not enormous.  nano adds a few things 
I like, but the UI is the same.  Heck...I still use PINE and am sending 
this message from it ;)

-uso.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors / machine load
  2020-01-10 15:48         ` Clem Cole
@ 2020-01-10 22:18           ` Adam Thornton
  2020-01-11  0:30             ` Christopher Browne
  0 siblings, 1 reply; 28+ messages in thread
From: Adam Thornton @ 2020-01-10 22:18 UTC (permalink / raw)
  To: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 3899 bytes --]

A) The original WD UART chip had very limited buffering.   The timing was
such that as high rates it could not empty accept a second character
without the first being overwritten.  This was a long-standing issue for
many UARTs long in the 1990s.  The original chip NS built and IBM used on
the PC (the NS8250) was notorious for the same problem.  By the time of
Motorola's 6881, it had 8 characters of buffering IIRC.

Great, now I'm having flashbacks to upgrading my 4-port serial card with
16450s and then 16550s in the early 90s.


On Fri, Jan 10, 2020 at 8:49 AM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Fri, Jan 10, 2020 at 10:00 AM Mary Ann Horton <mah@mhorton.net> wrote:
>
>> Yes, it was a real concern. Physical memory on the shared PDP-11 was
>> limited, and if everyone had a separate copy of vi running the machine
>> would swap itself silly.
>>
>> This only mattered if everyone had their own separate copy of vi
>> installed. The fix was to put vi in a single system directory, such as
>> /usr/ucb or /exptools. The instruction part of its memory would be
>> shared among all the users, resulting in much less swapping.
>>
> Actually it was much worse than that...
>
> What Mary Ann points out was mostly true of your PDP-11 had DH11's
> installed; which had deeper hardware buffering and 16 character DMA on
> output.   But these were expensive from DEC and also took up a 'full system
> unit' in the CPU for 16 lines.   Until Able (much later) released the
> DMAX-11 (*a.k.a.* DH/DM) product of a DH11 clone on a single board, many
> university sites did not use them; but used multiple DL-11/KL-11's instead.
>
> If your system was configured with DL/KL11s or similar (CMU had it's own
> called 'ASLIs' - a synchronous line interfaces) each character took one
> interrupt for each either input or output.  Moreover, the UARTS that DEC
> used which were made by Western Digital had 2 >>or less<< characters of
> input buffering, so they could drop chars[1].  The ASLI's used a later chip
> with a slightly better buffer IIRC but I admit I've forgotten the details
> (Jim Tetter probably remembers them).
>
> So if you had a single line, the interrupt load was huge on a PDP-11.  For
> this reason, a lot of sites limited glass TTYs to speeds like 2400 or 4800
> baud, not the full 9600.
>
> DEC later released the DZ-11 which worked on units of 8 ports per board.
> Unfortunately, it was not DMA and the buffering was still pretty shallow.
>  Joy did a lot of work on 4.1BSD in the DZ driver to cut down the
> interrupts because 9600 baud DZ lines could swamp a vax and when running
> the BerkNet between systems (before UCB had ethernet), 9600 baud serial
> lines were standard.
>
>
> [1]  Two things
>  A) The original WD UART chip had very limited buffering.   The timing was
> such that as high rates it could not empty accept a second character
> without the first being overwritten.  This was a long-standing issue for
> many UARTs long in the 1990s.  The original chip NS built and IBM used on
> the PC (the NS8250) was notorious for the same problem.  By the time of
> Motorola's 6881, it had 8 characters of buffering IIRC.
>
> B) As I understand the history, Gordon developed the original idea of the
> UART at DEC for the PDP-1. But I'm not sure of the patent details. He does
> not list the UART patent on his web site although he does mention inventing
> it.   I have been under the impression CMU was somehow mixed up in the
> patent and licensing of it, *i.e.* WD got the license from CMU to make
> them not DEC; which was part of why we had the ASLI's.  Again, IIRC, we got
> the UART chips from WD at cost and could make the ALSI's locally much
> cheaper than DL-11s.  >>I think<< the story was that one of Gordon's
> student's designed a chip, which WD fabbed and licensed.  Before that DEC
> had built UARTs on boards from transistors and later logic gates.
>
>

[-- Attachment #2: Type: text/html, Size: 5996 bytes --]

<div dir="ltr"><div style="margin-left:40px">A) The original WD UART chip had very limited buffering.   The timing 
was such that as high rates it could not empty accept a second character
 without the first being overwritten.  This was a long-standing issue 
for many UARTs long in the 1990s.  The original chip NS built and IBM 
used on the PC (the NS8250) was notorious for the same problem.  By the 
time of Motorola&#39;s 6881, it had 8 characters of buffering IIRC.</div><div><br></div><div>Great, now I&#39;m having flashbacks to upgrading my 4-port serial card with 16450s and then 16550s in the early 90s.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 10, 2020 at 8:49 AM Clem Cole &lt;<a href="mailto:clemc@ccc.com">clemc@ccc.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 10, 2020 at 10:00 AM Mary Ann Horton &lt;<a href="mailto:mah@mhorton.net" target="_blank">mah@mhorton.net</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yes, it was a real concern. Physical memory on the shared PDP-11 was <br>
limited, and if everyone had a separate copy of vi running the machine <br>
would swap itself silly.<br>
<br>
This only mattered if everyone had their own separate copy of vi <br>
installed. The fix was to put vi in a single system directory, such as <br>
/usr/ucb or /exptools. The instruction part of its memory would be <br>
shared among all the users, resulting in much less swapping.<br></blockquote><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">Actually it was much worse than that...</span></div><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">What Mary Ann points out was mostly true of your PDP-11 had DH11&#39;s installed; which had deeper hardware buffering and 16 character DMA on output.   But these were expensive from DEC and also took up a &#39;full system unit&#39; in the CPU for 16 lines.</span> <span class="gmail_default" style="font-family:arial,helvetica,sans-serif">  Until Able (much later) released the DMAX-11 (<i>a.k.a.</i> DH/DM) product of a DH11 clone on a single board, many university sites did not use them; but used multiple DL-11/KL-11&#39;s instead.</span></div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">If your system was configured with DL/KL11s or similar (CMU had it&#39;s own called &#39;ASLIs&#39; - a synchronous line interfaces) each character took one interrupt for each either input or output.  Moreover, the UARTS that DEC used which were made by Western Digital had 2 &gt;&gt;or less&lt;&lt; characters of input buffering, so they could drop chars[1].  The ASLI&#39;s used a later chip with a slightly better buffer IIRC but I admit I&#39;ve forgotten the details (Jim Tetter probably remembers them).</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">So if you had a single line, the interrupt load was huge on a PDP-11.  For this reason, a lot of sites limited glass TTYs to speeds like 2400 or 4800 baud, not the full 9600.   </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">DEC later released the DZ-11 which worked on units of 8 ports per board.  Unfortunately, it was not DMA and the buffering was still pretty shallow.   Joy did a lot of work on 4.1BSD in the DZ driver to cut down the interrupts because 9600 baud DZ lines could swamp a vax and when running the BerkNet between systems (before UCB had ethernet), 9600 baud serial lines were standard.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">[1]  Two things</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"> A) The original WD UART chip had very limited buffering.   The timing was such that as high rates it could not empty accept a second character without the first being overwritten.  This was a long-standing issue for many UARTs long in the 1990s.  The original chip NS built and IBM used on the PC (the NS8250) was notorious for the same problem.  By the time of Motorola&#39;s 6881, it had 8 characters of buffering IIRC.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">B) As I understand the history, Gordon developed the original idea of the UART at DEC for the PDP-1. But I&#39;m not sure of the patent details. He does not list the UART patent on his web site although he does mention inventing it.   I have been under the impression CMU was somehow mixed up in the patent and licensing of it, <i>i.e.</i> WD got the license from CMU to make them not DEC; which was part of why we had the ASLI&#39;s.  Again, IIRC, we got the UART chips from WD at cost and could make the ALSI&#39;s locally much cheaper than DL-11s.  &gt;&gt;I think&lt;&lt; the story was that one of Gordon&#39;s student&#39;s designed a chip, which WD fabbed and licensed.  Before that DEC had built UARTs on boards from transistors and later logic gates.<br></div><br></div></div></div>
</blockquote></div>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors / machine load
  2020-01-10 22:18           ` Adam Thornton
@ 2020-01-11  0:30             ` Christopher Browne
  0 siblings, 0 replies; 28+ messages in thread
From: Christopher Browne @ 2020-01-11  0:30 UTC (permalink / raw)
  To: Adam Thornton; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

On Fri, 10 Jan 2020 at 17:19, Adam Thornton <athornton@gmail.com> wrote:

> A) The original WD UART chip had very limited buffering.   The timing was
> such that as high rates it could not empty accept a second character
> without the first being overwritten.  This was a long-standing issue for
> many UARTs long in the 1990s.  The original chip NS built and IBM used on
> the PC (the NS8250) was notorious for the same problem.  By the time of
> Motorola's 6881, it had 8 characters of buffering IIRC.
>
> Great, now I'm having flashbacks to upgrading my 4-port serial card with
> 16450s and then 16550s in the early 90s.
>

Yep, same sorts of memories here.  I recall the 16450 upgrade being a big
deal for Internet connectivity in that a PC lacking the extra bytes of
buffering in the UART would find that the 80386 was having clock cycles
eaten nearly completely by PPP connections.
It was amazing to realize how a few bytes of memory lurking in a crucial
system interface could affect performance in such dramatic ways.
Tagged command queueing on SCSI controllers had a slightly less dramatic
effect on I/O performance, but again, a few hundred bytes of memory in the
right spot could nevertheless have dramatic effects.

[-- Attachment #2: Type: text/html, Size: 1699 bytes --]

<div dir="auto"><div dir="ltr"><div dir="ltr">On Fri, 10 Jan 2020 at 17:19, Adam Thornton &lt;<a href="mailto:athornton@gmail.com" target="_blank" rel="noreferrer">athornton@gmail.com</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="margin-left:40px">A) The original WD UART chip had very limited buffering.   The timing 
was such that as high rates it could not empty accept a second character
 without the first being overwritten.  This was a long-standing issue 
for many UARTs long in the 1990s.  The original chip NS built and IBM 
used on the PC (the NS8250) was notorious for the same problem.  By the 
time of Motorola&#39;s 6881, it had 8 characters of buffering IIRC.</div><div><br></div><div>Great, now I&#39;m having flashbacks to upgrading my 4-port serial card with 16450s and then 16550s in the early 90s.</div></div></blockquote><div><br></div><div>Yep, same sorts of memories here.  I recall the 16450 upgrade being a big deal for Internet connectivity in that a PC lacking the extra bytes of buffering in the UART would find that the 80386 was having clock cycles eaten nearly completely by PPP connections.  </div><div dir="auto">It was amazing to realize how a few bytes of memory lurking in a crucial system interface could affect performance in such dramatic ways.  </div><div dir="auto">Tagged command queueing on SCSI controllers had a slightly less dramatic effect on I/O performance, but again, a few hundred bytes of memory in the right spot could nevertheless have dramatic effects.</div></div></div></div>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-10  8:17     ` U'll Be King of the Stars
@ 2020-01-11 19:58       ` markus schnalke
  2020-01-11 20:54         ` Derek Fawcus
  2020-01-11 21:27         ` Henry Bent
  0 siblings, 2 replies; 28+ messages in thread
From: markus schnalke @ 2020-01-11 19:58 UTC (permalink / raw)
  To: tuhs

Hoi.

[2020-01-10 08:17] U'll Be King of the Stars <ullbeking@andrewnesbit.org>
> On 10/01/2020 08:13, markus schnalke wrote:
> >
> > GNU ed [...] seems to be more a demonstration
> > object than actually a programmer's editor.
> 
> Hi Markus, in what way is GNU ed a "demonstration object"?

Thanks for questioning this statement! It seems as if I might have
mixed different memories up. A quick look at GNU ed showed nothing
to support my statement. Sorry for pretending stuff without fact
checking.


My look was at version 1.4, which is the newest one I could look
into. I'm pretty sure I examined GNU ed 1.6 back then, because
that version is in the Pkgfile of my system, but unfortunately I
am unable to find it anywhere. The GNU release mirrors lack all
version 1.5 through 1.10 -- why that? They must have been
released, at least 1.6, because that is used on my system.
Unfortunately I also was unable to access the Changelog of a
newer version to check for changes, because these are lzip
compressed (tar.lz) ... whatever that is, I cannot uncompress it
on my system. Furthermore I neither could find an online
browsable web repo view for checking out version 1.6 or at least
viewing the files within the browser. There's only a cvs repo
access (no cvs on my machine) and it talks about the web page
repo not the ed source repo. Not sure what to think of that.

That's not how things should be. Actually, I'm a bit depressed
now ...


meillo


P.S.
Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like
``vee-eye''), is that what you english speakers do? To me (a
native German speaker) it naturally was ``ed'' (like ``sam'').
As reference some Computerphile video is given, which is now
deleted. Is there a better source?

And what about the pronounciations of `ex' and `qed'?

What about `od'? (That I pronouce ``oh-dee''.)

https://en.wikipedia.org/wiki/Ed_(text_editor)

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-11 19:58       ` markus schnalke
@ 2020-01-11 20:54         ` Derek Fawcus
  2020-01-11 21:27         ` Henry Bent
  1 sibling, 0 replies; 28+ messages in thread
From: Derek Fawcus @ 2020-01-11 20:54 UTC (permalink / raw)
  To: tuhs

On Sat, Jan 11, 2020 at 08:58:53PM +0100, markus schnalke wrote:
> 
> Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like
> ``vee-eye''), is that what you english speakers do? To me (a
> native German speaker) it naturally was ``ed'' (like ``sam'').

As a native english speaker...

'ed', as in the man's name. I pronounce 'vi' as you have it above,
but others at work pronounce it as 'vye' (as in 'vying'), so no
consistency there.

We also have local inconsistencies for how JIRA is pronounced,
so don't expect a canonical answer.

> And what about the pronounciations of `ex' and `qed'?

I can't say I've pronounced them before, but I think of
former as 'ee-x', I'd be inclined to pronounce the latter
as 'queue-ed'.  Since Q-E-D has its own meaning.

> What about `od'? (That I pronouce ``oh-dee''.)

agreed; otherwise confusing with 'odd'.

But who knows how the authors pronounced them.

DF

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-11 19:58       ` markus schnalke
  2020-01-11 20:54         ` Derek Fawcus
@ 2020-01-11 21:27         ` Henry Bent
  1 sibling, 0 replies; 28+ messages in thread
From: Henry Bent @ 2020-01-11 21:27 UTC (permalink / raw)
  To: markus schnalke; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 3161 bytes --]

On Sat, 11 Jan 2020 at 14:59, markus schnalke <meillo@marmaro.de> wrote:

> Hoi.
>
> [2020-01-10 08:17] U'll Be King of the Stars <ullbeking@andrewnesbit.org>
> > On 10/01/2020 08:13, markus schnalke wrote:
> > >
> > > GNU ed [...] seems to be more a demonstration
> > > object than actually a programmer's editor.
> >
> > Hi Markus, in what way is GNU ed a "demonstration object"?
>
> Thanks for questioning this statement! It seems as if I might have
> mixed different memories up. A quick look at GNU ed showed nothing
> to support my statement. Sorry for pretending stuff without fact
> checking.
>
>
> My look was at version 1.4, which is the newest one I could look
> into. I'm pretty sure I examined GNU ed 1.6 back then, because
> that version is in the Pkgfile of my system, but unfortunately I
> am unable to find it anywhere. The GNU release mirrors lack all
> version 1.5 through 1.10 -- why that? They must have been
> released, at least 1.6, because that is used on my system.
> Unfortunately I also was unable to access the Changelog of a
> newer version to check for changes, because these are lzip
> compressed (tar.lz) ... whatever that is, I cannot uncompress it
> on my system. Furthermore I neither could find an online
> browsable web repo view for checking out version 1.6 or at least
> viewing the files within the browser. There's only a cvs repo
> access (no cvs on my machine) and it talks about the web page
> repo not the ed source repo. Not sure what to think of that.
>
> That's not how things should be. Actually, I'm a bit depressed
> now ...
>

GNU ed appears to be written entirely by one person (as in, no changelog
entries by anyone else since 1994), who perhaps not coincidentally is also
the author of the lzip compression program.  As you noted, ed source is
distributed only as lzip-compressed tarballs, so you have to be able to
compile and run lzip to compile and run ed.  lzip is written in C++, so to
have access to GNU ed you need a C++ compiler.  Which is very strange, as
GNU ed is a very simple C program, much as one would expect.

The configure program is extremely basic, which is great - why have more
than you need? - but when it detected that my $(CC) was not gcc, it
hard-coded $(CC) to cc and $(CFLAGS) to -O2, ignoring what I had passed to
the script.  A strange choice, but one that can easily be edited later in
the Makefile.  The basic C source compiled with no warnings whatsoever,
always a good sign.  At the linking stage I noticed that I needed a library
for some functions it wanted.  Okay, easy enough, just add a library to the
Makefile's LDFLAGS.  But the Makefile had this braindamage:

$(progname) : $(objs)
        $(CC) $(LDFLAGS) $(CFLAGS) -o $@ $(objs)

so on any platform that needs libraries linked after objects, it will fail.

At that point, I gave up.  This is clearly one person's pet project and has
"but it works on my Linux box!" written all over it.  That, coupled with
the fact that the GNU folks are willing to endorse something that is solely
distributed in what can only be described as an extremely obscure
compression format, was just too much for me to handle.

-Henry

[-- Attachment #2: Type: text/html, Size: 3832 bytes --]

<div dir="ltr"><div dir="ltr">On Sat, 11 Jan 2020 at 14:59, markus schnalke &lt;<a href="mailto:meillo@marmaro.de">meillo@marmaro.de</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hoi.<br>
<br>
[2020-01-10 08:17] U&#39;ll Be King of the Stars &lt;<a href="mailto:ullbeking@andrewnesbit.org" target="_blank">ullbeking@andrewnesbit.org</a>&gt;<br>
&gt; On 10/01/2020 08:13, markus schnalke wrote:<br>
&gt; &gt;<br>
&gt; &gt; GNU ed [...] seems to be more a demonstration<br>
&gt; &gt; object than actually a programmer&#39;s editor.<br>
&gt; <br>
&gt; Hi Markus, in what way is GNU ed a &quot;demonstration object&quot;?<br>
<br>
Thanks for questioning this statement! It seems as if I might have<br>
mixed different memories up. A quick look at GNU ed showed nothing<br>
to support my statement. Sorry for pretending stuff without fact<br>
checking.<br>
<br>
<br>
My look was at version 1.4, which is the newest one I could look<br>
into. I&#39;m pretty sure I examined GNU ed 1.6 back then, because<br>
that version is in the Pkgfile of my system, but unfortunately I<br>
am unable to find it anywhere. The GNU release mirrors lack all<br>
version 1.5 through 1.10 -- why that? They must have been<br>
released, at least 1.6, because that is used on my system.<br>
Unfortunately I also was unable to access the Changelog of a<br>
newer version to check for changes, because these are lzip<br>
compressed (tar.lz) ... whatever that is, I cannot uncompress it<br>
on my system. Furthermore I neither could find an online<br>
browsable web repo view for checking out version 1.6 or at least<br>
viewing the files within the browser. There&#39;s only a cvs repo<br>
access (no cvs on my machine) and it talks about the web page<br>
repo not the ed source repo. Not sure what to think of that.<br>
<br>
That&#39;s not how things should be. Actually, I&#39;m a bit depressed<br>
now ...<br></blockquote><div><br></div><div>GNU ed appears to be written entirely by one person (as in, no changelog entries by anyone else since 1994), who perhaps not coincidentally is also the author of the lzip compression program.  As you noted, ed source is distributed only as lzip-compressed tarballs, so you have to be able to compile and run lzip to compile and run ed.  lzip is written in C++, so to have access to GNU ed you need a C++ compiler.  Which is very strange, as GNU ed is a very simple C program, much as one would expect.</div><div><br></div><div>The configure program is extremely basic, which is great - why have more than you need? - but when it detected that my $(CC) was not gcc, it hard-coded $(CC) to cc and $(CFLAGS) to -O2, ignoring what I had passed to the script.  A strange choice, but one that can easily be edited later in the Makefile.  The basic C source compiled with no warnings whatsoever, always a good sign.  At the linking stage I noticed that I needed a library for some functions it wanted.  Okay, easy enough, just add a library to the Makefile&#39;s LDFLAGS.  But the Makefile had this braindamage:</div><div><br></div><div>$(progname) : $(objs)<br>        $(CC) $(LDFLAGS) $(CFLAGS) -o $@ $(objs)</div><div><br></div><div>so on any platform that needs libraries linked after objects, it will fail.</div><div><br></div><div>At that point, I gave up.  This is clearly one person&#39;s pet project and has &quot;but it works on my Linux box!&quot; written all over it.  That, coupled with the fact that the GNU folks are willing to endorse something that is solely distributed in what can only be described as an extremely obscure compression format, was just too much for me to handle.</div><div><br></div><div>-Henry<br></div></div></div>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-08 22:01   ` Clem Cole
@ 2020-01-17 23:38     ` Dave Horsfall
  2020-01-18  0:07       ` Ryan Casalino
  2020-01-18 23:02       ` greg travis
  0 siblings, 2 replies; 28+ messages in thread
From: Dave Horsfall @ 2020-01-17 23:38 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Wed, 8 Jan 2020, Clem Cole wrote:

> Although the famous ? error from the original version was annoying.

Was it Ken or Dennis who thought of a car with but a single alarm 
indicator; "the experienced driver will know what it means".

-- Dave

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-17 23:38     ` Dave Horsfall
@ 2020-01-18  0:07       ` Ryan Casalino
  2020-01-18 23:02       ` greg travis
  1 sibling, 0 replies; 28+ messages in thread
From: Ryan Casalino @ 2020-01-18  0:07 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

On Fri, Jan 17, 2020, at 3:38 PM, Dave Horsfall wrote:
> On Wed, 8 Jan 2020, Clem Cole wrote:
> 
> > Although the famous ? error from the original version was annoying.
> 
> Was it Ken or Dennis who thought of a car with but a single alarm 
> indicator; "the experienced driver will know what it means".
> 
> -- Dave
> 

I actually just started using ed for the first time last week (based on one of your earlier comments, Clem) and I couldn't disagree more. 

? is refreshing in its simplicity. Anyway, back to being a fly on the wall. :) 

[-- Attachment #2: Type: text/html, Size: 989 bytes --]

<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Fri, Jan 17, 2020, at 3:38 PM, Dave Horsfall wrote:<br></div><blockquote type="cite" id="qt"><div>On Wed, 8 Jan 2020, Clem Cole wrote:<br></div><div><div><br></div></div><div>&gt; Although the famous ? error from the original version was annoying.<br></div><div><div><br></div></div><div>Was it Ken or Dennis who thought of a car with but a single alarm&nbsp;<br></div><div>indicator; "the experienced driver will know what it means".<br></div><div><div><br></div></div><div>-- Dave<br></div><div><div><br></div></div></blockquote><div><br></div><div>I actually just started using ed for the first time last week (based on one of your earlier comments, Clem) and I couldn't disagree more. <br></div><div><br></div><div>? is refreshing in its simplicity. Anyway, back to being a fly on the wall. :) <br></div></body></html>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-10 17:18         ` Steve Nickolas
@ 2020-01-18  1:55           ` Michael Parson
  0 siblings, 0 replies; 28+ messages in thread
From: Michael Parson @ 2020-01-18  1:55 UTC (permalink / raw)
  To: TUHS main list

On Fri, 10 Jan 2020, Steve Nickolas wrote:
> On Fri, 10 Jan 2020, Dan Cross wrote:
>> On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam <cym224@gmail.com>
>> wrote:
>>
>>> In earlier days, my wife was given email by telnetting to an SGI
>>> system and using elm.  One day, I visited her office as she was
>>> composing a message.  Intrigued, I asked her what the editor
>>> was. She did not know and pointed to her cheat-sheet listing editor
>>> commands.  One was ^X^C to exit-and-send.  She is not a programmer
>>> and I was a bit surprised at their choice.
>>
>>
>> Hmm, I'm actually kind of not. Starting users off with a modal
>> editor (that starts in command mode, no less!) can be surprising for
>> novices; with emacs, at least you can start typing text and, well,
>> see text.
>
> This is one of the reasons I liked E when I first used it: it was
> modal, but it started in edit mode.  (Also you KNEW what mode you were
> in, which I understand isn't always the case with vi, although it
> usually is in the clones iirc?)
>
>> I think that one of the smartest things Marc Crispin ever did was
>> write `pico` to go with `pine`. A simple editor targeted at the
>> novice was really useful for casual and/or new users, particularly as
>> the Internet spread and an account on a Unix system was the default
>> introduction to email etc for so many.
>
> And I still use nano - which is a rewrite of pico.

The 'gnu' version (or maybe just gnu licensed) of pico, cuz there has to
be a 'gnu' licensed of everything :-/

> pico Just Works(R)(TM)(C), and it's not enormous.  nano adds a few things I 
> like, but the UI is the same.  Heck...I still use PINE and am sending this 
> message from it ;)

I used pine for years, now alpine, fingers are as hard wired for moving
around in it as they are for doing things in vi(m).  However, I also
have (al)pine use vi for the message editing. :)

I learned ed a long time ago because I once had some box that would boot
into single-user mode, but not far enough to get any termcap/info stuff
loaded, vi didn't work, ex didn't work, but ed did.  Not too long ago, I
used ed to fix a hosed up passwd file via salt... did something like:

sudo salt some-box cmd.run 'printf "1\n/mparson\ns/foo/bar/\nw\nq\n" | ed /etc/passwd'

I don't remember what exactly was wrong, but it prevented someone from
being able to log in and it wasn't fixable with the 'users' state.
Maybe it was a bad path to root's shell and we couldn't log in on the
console or something.  I've slept since then, lost the details.

The guy watching over my shoulder didn't even know what 'ed' was.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors
  2020-01-17 23:38     ` Dave Horsfall
  2020-01-18  0:07       ` Ryan Casalino
@ 2020-01-18 23:02       ` greg travis
  1 sibling, 0 replies; 28+ messages in thread
From: greg travis @ 2020-01-18 23:02 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

'Ken Thompson has an automobile which he helped design. Unlike most
automobiles, it has neither speedometer, nor gas gauge, nor any of the
other numerous idiot lights which plague the modern driver. Rather, if the
driver makes a mistake, a giant “?” lights up in the center of the
dashboard. “The experienced driver,” says Thompson, “will usually know
what’s wrong.”'

On Fri, Jan 17, 2020 at 6:39 PM Dave Horsfall <dave@horsfall.org> wrote:

> On Wed, 8 Jan 2020, Clem Cole wrote:
>
> > Although the famous ? error from the original version was annoying.
>
> Was it Ken or Dennis who thought of a car with but a single alarm
> indicator; "the experienced driver will know what it means".
>
> -- Dave
>

[-- Attachment #2: Type: text/html, Size: 1170 bytes --]

<div dir="ltr">&#39;Ken Thompson has an automobile which he helped design. Unlike most automobiles, it has neither speedometer, nor gas gauge, nor any of the other numerous idiot lights which plague the modern <span class="gmail-il">driver</span>. Rather, if the <span class="gmail-il">driver</span> makes a mistake, a giant “?” lights up in the center of the dashboard. “The <span class="gmail-il">experienced</span> <span class="gmail-il">driver</span>,” says Thompson, “will usually know what’s wrong.”&#39;<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 17, 2020 at 6:39 PM Dave Horsfall &lt;<a href="mailto:dave@horsfall.org">dave@horsfall.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 8 Jan 2020, Clem Cole wrote:<br>
<br>
&gt; Although the famous ? error from the original version was annoying.<br>
<br>
Was it Ken or Dennis who thought of a car with but a single alarm <br>
indicator; &quot;the experienced driver will know what it means&quot;.<br>
<br>
-- Dave<br>
</blockquote></div>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors / machine load
@ 2020-01-10 15:35 jnc
  0 siblings, 0 replies; 28+ messages in thread
From: jnc @ 2020-01-10 15:35 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > When Bernie Greenberg did EMACS for Multics, he had a similar issue. I
    > recall reading a document with an extensive discussion of how they dealt
    > with this ... If anyone's really interested in this, and can't find it
    > themselves, I can try looking for it.

I got a request for this; a Web search turned up:

  https://www.multicians.org/mepap.html

which covers the points I mentioned (and more besides, such as why LISP was
chosen). I don't think this is the thing I remembered (which was, IIRC, an
informal note), but it does seem to be a later version of that.

	 Noel

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [TUHS] screen editors / machine load
@ 2020-01-10 14:35 jnc
  0 siblings, 0 replies; 28+ messages in thread
From: jnc @ 2020-01-10 14:35 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Otto Moerbeek <otto@drijf.net>

    > I believe it was not only vi itself that was causing the load, it was
    > also running many terminals in raw mode that killed performance.

I'm not familiar with the tty driver in late versions of Unix like 4.1 (sic),
but I'm very familiar with the one in V6, and it's not the raw mode _itself_
that caused the load (the code paths in the kernel for cooked and raw aren't
that different), but rather the need to wake up and run a process on every
character that was the real load.

When Bernie Greenberg did EMACS for Multics, he had a similar issue. I recall
reading a document with an extensive discussion of how they dealt with this,
especially when using the system over the ARPANET. IIRC, normal printing
characters were echoed without waking up the process; remotely, when using
the network. If anyone's really interested in this, and can't find it themselves,
I can try looking for it.

	Noel


^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, back to index

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-08  7:39 [TUHS] screen editors Thomas Paulsen
2020-01-08 15:58 ` Steve Nickolas
2020-01-08 23:41   ` Dave Horsfall
2020-01-09  1:43     ` Nemo Nusquam
2020-01-08 21:49 ` Dave Horsfall
2020-01-08 22:01   ` Clem Cole
2020-01-17 23:38     ` Dave Horsfall
2020-01-18  0:07       ` Ryan Casalino
2020-01-18 23:02       ` greg travis
2020-01-10  8:13   ` markus schnalke
2020-01-10  8:17     ` U'll Be King of the Stars
2020-01-11 19:58       ` markus schnalke
2020-01-11 20:54         ` Derek Fawcus
2020-01-11 21:27         ` Henry Bent
2020-01-10 13:41     ` [TUHS] screen editors / machine load Mike Markowski
2020-01-10 13:56       ` Otto Moerbeek
2020-01-10 15:00       ` Mary Ann Horton
2020-01-10 15:48         ` Clem Cole
2020-01-10 22:18           ` Adam Thornton
2020-01-11  0:30             ` Christopher Browne
2020-01-10 15:31     ` [TUHS] screen editors Nemo Nusquam
2020-01-10 16:04       ` Clem Cole
2020-01-10 17:10       ` Dan Cross
2020-01-10 17:18         ` Steve Nickolas
2020-01-18  1:55           ` Michael Parson
2020-01-10 15:58     ` Theodore Y. Ts'o
2020-01-10 14:35 [TUHS] screen editors / machine load jnc
2020-01-10 15:35 jnc

The Unix Heritage Society mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/tuhs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git