The Unix Heritage Society mailing list
 help / color / Atom feed
* Re: [TUHS] [TUHS -> moving to COFF] # and the Preprocessor
@ 2020-01-08 16:02 Clem Cole
  2020-01-08 22:25 ` Dr Iain Maoileoin
  0 siblings, 1 reply; 2+ messages in thread
From: Clem Cole @ 2020-01-08 16:02 UTC (permalink / raw)
  To: Brian Walden; +Cc: Computer Old Farts Followers, TUHS main list

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

below...  -- warning veering a little from pure UNIX history, but trying to
clarify what I can and then moving to COFF for follow up.

On Wed, Jan 8, 2020 at 12:23 AM Brian Walden <tuhs@cuzuco.com> wrote:

> ....
>
> - CMU's ALGOL68S from 1978 list all these ways --
>   co            comment
>   comment       comment
>   pr            pragmat
>   pragmat       pragmat
>   #             (comment symbol) comment
>   ::            (pragmat symbol) pragmat
>   (its for UNIX v6 or v7 so not surprising # is a comment)
>   http://www.softwarepreservation.org/projects/ALGOL/manual/a68s.txt/view

Be careful of overthinking here.   The comment in that note says was it was
for* PDP-11's *and lists V6 and V7 was *a possible target*, but it did not
say it was.  Also, the Speach and Vision PDP-11/40e based systems ran a
very hacked v6 (which a special C compiler that supported CMU's csv/cret
instructions in the microcode), which would have been the target systems.
[1]

To my knowledge/memory, the CMU Algol68 compiler never ran anywhere but
Hydra (and also used custom microcode).  IIRC there was some talk to move
it to *OS (Star OS for CM*)  I've sent a note to dvk to see if he remembers
it otherwise. I also ask Liebensperger what he remembers, he was hacking on
*OS in those days.  Again, IIRC Prof. Peter Hibbard was the mastermind
behind the CMU Algol68 system.  He was a Brit from Cambridge (and taught
the parallel computing course which I took from him at the time).

FWIW: I also don't think the CMU Algol68 compiler was ever completely
self-hosting, and like BLISS, required the PDP-10 to support it.  As to why
it was not moved to the Vax, I was leaving/had left by that time, but I
suspect the students involved graduated and by then the Perq's had become
the hot machine for language types and ADA would start being what the gvt
would give research $s too.


>
>
> ...
>
> But look! The very first line of that file! It is a single # sitting all
> by itself.  Why? you ask. Well this is a hold over from when the C
> preprocessor was new. C orginally did not have it and was added later.
> PL/I had a %INCLUDE so Ritchie eventaully made a #include -- but pre 7th
> Edition the C preprocessor would not be inkoved unless the very first
> character of the C source file was an #
>
That was true of V7 and Typesetter C too.  It was a separate program (
/lib/cpp) that the cc command called if needed.



> Since v7 the preprocessor always run on it. The first C preprocessor was
> Ritchie's work with no nested includes and no macros. v7's was by John
> Reiser which added those parts.
>
Right, this is what I was referring too last night in reference to Sean
comments.  As I said, the /bin/cc command was a shell script and it peaked
at the first character to see if it was #.   I still find myself starting
all C programs with a # on a line by itself ;-)

Note that the Ritchie cpp was influenced by Brian's Ratfor work, so using #
is not surprising.

This leads to a question/thought for this group, although I think needs to
move to COFF (which I have CC'ed for follow up).

I have often contended, that one of the reasons why C, Fortran, and PL/1
were so popular as commercial production languages were because they could
be preprocessed.  For a commercial place where lots of different targets is
possible, that was hugely important.  Pascal, for instance, has semantics
that makes writing a preprocessor like cpp or Ratfor difficult (which was
one of the things Brian talks about in his "*Why Pascal is not my favorite
Programming Language <http://www.lysator.liu.se/c/bwk-on-pascal.html>*"
paper). [2]

So, if you went to commercial ISV's and looked at what they wrote in.   It
was usually some sort of preprocessed language.   Some used Ratfor like a
number of commercial HPC apps vendors, Tektronix wrote PLOT10 in MORTRAN.
 I believe it was Morgan-Stanley had a front-end for PL/1, which I can not
recall the name.  But you get the point ... if you had to target different
runtime environments, it was best for your base code to not be specific.

However ... as C became the system programming language, the preprocessor
was important.  In fact, it even gave birth the other tools like autoconfig
to help control them.  Simply, the idiom:
#ifdef SYSTEMX
#define SOME_VAR (1)
... do something specific
#endif /* SYSTEMX */

While loathsome to read, it actually worked well in practice.

That fact is I hate the preprocessor in many ways but love it for what it
for the freedom it actually gave us to move code.  Having programmed since
the 1960s, I remember how hard it was to move things, even if the language
was the same.

Today, modern languages try to forego the preprocessor.   C++'s solution is
to throw the kitchen sink into the language and have 'frameworks', none of
which work together.   Java's and its family tries to control it with the
JVM.  Go is a little too new to see if its going to work (I don't see a lot
of production ISV code in it yet).

Note: A difference between then and now, is 1) we have few target
architectures and 2) we have fewer target operating environments, 3) ISV
don't like multiple different versions of their SW, they much prefer very
few for maintenance reasons so they like # 1 and #2 [i.e. Cole's law of
economics in operation here].

So ... my question, particularly for those like Doug who have programmed
longer and at least as long as I, what do you think?   You lived the same
time I did and know the difficulties we faced.   Is the loss of a
preprocessor good or bad?

Clem

[1] Historical footnote about CMU.   I was the person that brought V7 into
CMU and I never updated the Speach or Vision systems and I don't think
anyone did after I left.  We ran a CMU V7 variant mostly on the 11/34s (and
later on a couple of 11/44s I believe) that had started to pop up.
Although later if it was a DEC system, CS was moving to Vaxen when they
could get the $s (but the Alto's and Perq's had become popular with the CMU
SPICE proposal).  Departments like bio-engineering, mech ee, ran the
cheaper systems on-site and then networked over the Computer Center's Vaxen
and PDP-20's when they needed address space).

[2] Note: Knuth wrote "Web" to handle a number of the issues, Kernighan
talks about - but he had to use an extended Pascal superset and his program
was notable for not being portable (he wrote for it for the PDP-10
Pascal).  [BTW: Ward Cunningham, TW Cook and I once counted over 8
different 'Tek Pascal' variants and 14 different 'HP Basics'].

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

<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">below...  -- warning veering a little from pure UNIX history, but trying to clarify what I can and then moving to COFF for follow up.</font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><font color="#ff0000">On Wed, Jan 8, 2020 at 12:23 AM Brian Walden &lt;<a href="mailto:tuhs@cuzuco.com">tuhs@cuzuco.com</a>&gt; wrote:<br></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font color="#ff0000"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">....</span><br>
<br>
- CMU&#39;s ALGOL68S from 1978 list all these ways --<br>
  co            comment<br>
  comment       comment<br>
  pr            pragmat<br>
  pragmat       pragmat<br>
  #             (comment symbol) comment<br>
  ::            (pragmat symbol) pragmat<br>
  (its for UNIX v6 or v7 so not surprising # is a comment)<br>
  <a href="http://www.softwarepreservation.org/projects/ALGOL/manual/a68s.txt/view" rel="noreferrer" target="_blank">http://www.softwarepreservation.org/projects/ALGOL/manual/a68s.txt/view</a></font></blockquote><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">Be careful of overthinking here.   The comment in that note says was it was for<i> PDP-11&#39;s </i>and lists V6 and V7 was <i>a possible target</i>, but it did not say it was.  Also, the Speach and Vision PDP-11/40e based systems ran a very hacked v6 (which a special C compiler that supported CMU&#39;s csv/cret instructions in the microcode), which would have been the target systems. [1]</font></span><span style="color:rgb(0,0,255);font-family:arial,helvetica,sans-serif"> </span></div><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff"><br></font></span></div><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">To my knowledge/memory, the CMU Algol68 compiler never ran anywhere but Hydra (and also used custom microcode).  IIRC there was some talk to move it to *OS (Star OS for CM*)  I&#39;ve sent a note to dvk to see if he remembers it otherwise. I also ask Liebensperger what he remembers, he was hacking on *OS in those days.  Again, IIRC Prof. Peter Hibbard was the mastermind behind the CMU Algol68 system.  He was a Brit from Cambridge (and taught the parallel computing course which I took from him at the time).</font></span></div><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff"><br></font></span></div><div><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">FWIW: I also don&#39;t think the CMU Algol68 compiler was ever completely self-hosting, and </span>like BLISS<span class="gmail_default" style="font-family:arial,helvetica,sans-serif">, </span><span style="font-family:arial,helvetica,sans-serif">required the PDP-10<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> </span>to support it.  As to why it was not moved to the Vax,<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> I was leaving/had left by that time, but</span> I suspect the students involved graduated and by then the Perq&#39;s had become the hot machine for language types<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> and ADA would start being what the gvt would give research $s too.</span><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"></span><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"></span><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"></span><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">  </span></span></font></div><div><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"></span> </font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font color="#ff0000"><br>
<br><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">...</span><br>
<br>
But look! The very first line of that file! It is<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> </span>a single # sitting all by itself.  Why? you ask. Well this is a hold<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> </span>over from when the C preprocessor was new. C orginally did not<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> </span>have it and was added later. PL/I had a %INCLUDE so Ritchie eventaully<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> </span>made a #include -- but pre 7th Edition the C preprocessor would not be<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> </span>inkoved unless the very first character of the C source file was an #<br></font></blockquote><div><div class="gmail_default" style=""><font face="arial, helvetica, sans-serif"></font><font face="arial, helvetica, sans-serif" style="color:rgb(0,0,255)">That was true of V7 and Typesetter C too.  It was a separate program (</font><font face="monospace" style="" color="#000000">/lib/cpp</font><font face="arial, helvetica, sans-serif" style="color:rgb(0,0,255)">) that the cc command called if needed.</font></div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font color="#ff0000">
Since v7 the preprocessor always run on it. The first C preprocessor<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> </span>was Ritchie&#39;s work with no nested includes and no macros. v7&#39;s was by<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> </span>John Reiser which added those parts.<br></font></blockquote><div><div class="gmail_default" style=""><font face="arial, helvetica, sans-serif" style="color:rgb(0,0,255)">Right, this is what I was referring too last night in reference to Sean comments.  As I said, the </font><font face="monospace" style="" color="#000000">/bin/cc</font><font face="arial, helvetica, sans-serif" style="color:rgb(0,0,255)"> command was a shell script and it peaked at the first character to see if it was #.   I still find myself starting all C programs with a # on a line by itself ;-)</font></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"><font color="#0000ff">Note that the Ritchie cpp was influenced by Brian&#39;s Ratfor work, so using # is not surprising.</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff"><br></font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">This leads to a question/thought for this group, although I think needs to move to COFF (which I have CC&#39;ed for follow up).</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(0,0,255)"><br></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(0,0,255)">I have often contended, that one of the reasons why C, Fortran, and PL/1 were so popular as commercial production languages were because they could be preprocessed.  For a commercial place where lots of different targets is possible, that was hugely important.  Pascal, for instance, has semantics that makes writing a preprocessor like cpp or Ratfor difficult (which was one of the things Brian talks about in his &quot;<i><a href="http://www.lysator.liu.se/c/bwk-on-pascal.html">Why Pascal is not my favorite Programming Language</a></i>&quot; paper). [2]</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(0,0,255)"><br></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(0,0,255)">So, if you went to commercial ISV&#39;s and looked at what they wrote in.   It was usually some sort of preprocessed language.   Some used Ratfor like a number of commercial HPC apps vendors, Tektronix wrote PLOT10 in MORTRAN.   I believe it was Morgan-Stanley had a front-end for PL/1, which I can not recall the name.  But you get the point ... if you had to target different runtime environments, it was best for your base code to not be specific.</span></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"><span style="color:rgb(0,0,255)">However ... as C became the system programming language, the preprocessor was important.  In fact, it even gave birth the other tools like autoconfig to help control them.  Simply, the idiom:</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(0,0,255)">#ifdef SYSTEMX</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(0,0,255)">#define SOME_VAR (1)</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(0,0,255)">... do something specific</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(0,0,255)">#endif /* SYSTEMX */</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(0,0,255)"><br></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">While loathsome to read, it actually worked well in practice. </font></div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff"><br></font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">That fact is I hate the preprocessor in many ways but love it for what it for the freedom it actually gave us to move code.  Having programmed since the 1960s, I remember how hard it was to move things, even if the language was the same.</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff"><br></font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">Today, modern languages try to forego the preprocessor.   C++&#39;s solution is to throw the kitchen sink into the language and have &#39;frameworks&#39;, none of which work together.   Java&#39;s and its family tries to control it with the JVM.  Go is a little too new to see if its going to work (I don&#39;t see a lot of production ISV code in it yet).</font></div><div><font color="#0000ff"><br></font></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">Note: A difference between then and now, is 1) we have few target architectures and 2) we have fewer target operating environments, 3) ISV don&#39;t like multiple different versions of their SW, they much prefer very few for maintenance reasons so they like # 1 and #2 [i.e. Cole&#39;s law of economics in operation here].</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff"><br></font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">So ... my question, particularly for those like Doug who have programmed longer and at least as long as I, what do you think?   You lived the same time I did and know the difficulties we faced.   Is the loss of a preprocessor good or bad?</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff"><br></font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">Clem</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff"><br></font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><div><span class="gmail_default"><font color="#0000ff">[1] Historical footnote about CMU.   I was the person that brought V7 into CMU and I never updated the Speach or Vision systems and I don&#39;t think anyone did after I left.  We ran a CMU V7 variant mostly on the 11/34s (and later on a couple of 11/44s I believe) that had started to pop up.  Although later if it was a DEC system, CS was moving to Vaxen when they could get the $s (but the Alto&#39;s and Perq&#39;s had become popular with the CMU SPICE proposal).  Departments like bio-engineering, mech ee, ran the cheaper systems on-site and then networked over the Computer Center&#39;s Vaxen and PDP-20&#39;s when they needed address space).</font></span></div><div><span class="gmail_default"><font color="#0000ff"><br></font></span></div><div><span class="gmail_default"><font color="#0000ff">[2] </font></span><font color="#0000ff">Note: Knuth wrote &quot;Web&quot; to handle a number of the issues, Kernighan talks about - but he had to use an extended Pascal superset and his program was notable for not being portable (he wrote for it for the PDP-10 Pascal).  [BTW: Ward Cunningham, TW Cook and I once counted over 8 different &#39;Tek Pascal&#39; variants and 14 different &#39;HP Basics&#39;].</font></div><div></div></div><br></div></div></div>

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

* Re: [TUHS] [TUHS -> moving to COFF] # and the Preprocessor
  2020-01-08 16:02 [TUHS] [TUHS -> moving to COFF] # and the Preprocessor Clem Cole
@ 2020-01-08 22:25 ` Dr Iain Maoileoin
  0 siblings, 0 replies; 2+ messages in thread
From: Dr Iain Maoileoin @ 2020-01-08 22:25 UTC (permalink / raw)
  To: Clem Cole; +Cc: Computer Old Farts Followers, TUHS main list, Brian Walden

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


> On 8 Jan 2020, at 16:02, Clem Cole <clemc@ccc.com> wrote:
> 
> below...  -- warning veering a little from pure UNIX history, but trying to clarify what I can and then moving to COFF for follow up.
> 
> On Wed, Jan 8, 2020 at 12:23 AM Brian Walden <tuhs@cuzuco.com <mailto:tuhs@cuzuco.com>> wrote:
> ....
> 
> - CMU's ALGOL68S from 1978 list all these ways --
>   co            comment
>   comment       comment
>   pr            pragmat
>   pragmat       pragmat
I remember that a pragma (at least in Algol68R (ICL 1900 series) and I would need to reread the formal definition to see if it was general) was not a comment.
It was a note to the compiler - which could choose to use it or lose it.
>   #             (comment symbol) comment
>   ::            (pragmat symbol) pragmat
>   (its for UNIX v6 or v7 so not surprising # is a comment)
>   http://www.softwarepreservation.org/projects/ALGOL/manual/a68s.txt/view <http://www.softwarepreservation.org/projects/ALGOL/manual/a68s.txt/view>
> 


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

<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 8 Jan 2020, at 16:02, Clem Cole &lt;<a href="mailto:clemc@ccc.com" class="">clemc@ccc.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff" class="">below...&nbsp; -- warning veering a little from pure UNIX history, but trying to clarify what I can and then moving&nbsp;to COFF for follow up.</font></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><font color="#ff0000" class="">On Wed, Jan 8, 2020 at 12:23 AM Brian Walden &lt;<a href="mailto:tuhs@cuzuco.com" class="">tuhs@cuzuco.com</a>&gt; wrote:<br class=""></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font color="#ff0000" class=""><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">....</span><br class="">
<br class="">
- CMU's ALGOL68S from 1978 list all these ways --<br class="">
&nbsp; co&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; comment<br class="">
&nbsp; comment&nbsp; &nbsp; &nbsp; &nbsp;comment<br class="">
&nbsp; pr&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; pragmat<br class="">
&nbsp; pragmat&nbsp; &nbsp; &nbsp; &nbsp;pragmat<br class=""></font></blockquote></div></div></div></blockquote>I remember that a pragma (at least in Algol68R (ICL 1900 series) and I would need to reread the formal definition to see if it was general) was not a comment.</div><div>It was a note to the compiler - which could choose to use it or lose it.<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><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"><font color="#ff0000" class="">
&nbsp; #&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(comment symbol) comment<br class="">
&nbsp; ::&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (pragmat symbol) pragmat<br class="">
&nbsp; (its for UNIX v6 or v7 so not surprising # is a comment)<br class="">
&nbsp; <a href="http://www.softwarepreservation.org/projects/ALGOL/manual/a68s.txt/view" rel="noreferrer" target="_blank" class="">http://www.softwarepreservation.org/projects/ALGOL/manual/a68s.txt/view</a></font></blockquote><div class=""><br class=""></div></div></div>
</div></blockquote></div><br class=""></body></html>

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

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-08 16:02 [TUHS] [TUHS -> moving to COFF] # and the Preprocessor Clem Cole
2020-01-08 22:25 ` Dr Iain Maoileoin

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