> On 15 Sep 2024, at 20:21, Rik Farrow <rik(a)rikfarrow.com> wrote:
>
> Was the brevity typical of Unix command names a function of the tiny disk and memory available? Or more a function of having a Teletype 33 for input? Of course, it could simply be that 'cat' is more convenient than 'catenate'...
Hangover from assembly mnemonics, perhaps.
J
—
John Dow <jmd(a)nelefa.org>
Written by a human.
> https://retronaut.com/retronaut-capsules/1967-life-at-bell-labs
Luckham's introductory remark that all the programmers were men contrasts
with the situation 10 years before, when most of the programmers were
women. Women got shoved aside when it became apparent that programming was
an honorable and challenging engineering profession, not mere routine
translation of conceptual designd into machine language. It took almost 10
more years for the Labs to recognize that women programmers were engineers,
too.
Yet de jure recognition of women programmers has not yet become de facto.
Here at Dartmouth, as at many schools, women form a far smaller fraction of
computer science than they do of the engineering school. In engineering the
proportion of women reflects that in the general population.
Hi all,
I was working with my IRIX 4 machine recently and noticed a mysterious file
- /usr/lib/ecfe. It turns out that this is the Edison Design Group C (not
C++) Front End, included almost certainly by accident with the last release
of the Developer Toolkit for IRIX 4. No other piece of the compiler
toolchain references the EDG product in any way and there is no
documentation for it whatsoever.
The research that I did seems to indicate that this is a source to source
translator, akin to the contemporary Kuck & Associates product - is that
correct? I also found a reference to EDG's tool being used in the Apogee C
compiler. I have a copy of Apogee C for SunOS and it does appear that
"cfe" is the same EDG product. Unfortunately there is no documentation
specific to the C front end, and I don't have a license for Apogee C so I
can't run the compiler to see how it's calling cfe. Just running a C file
"blah.c" through the IRIX front end with no switches results in a
transformed file "blah.int.c". Unfortunately running anything even
moderately complex through the front end results in code that either
doesn't compile or doesn't run, so I feel that I must be missing some flags
or basic options.
Does anyone have any information about SGI's use of this software, or any
documentation/information in general about the EDG product? My usual
sources came up empty.
-Henry
>> I've despaired over the term ever since it wormed its way into
>> computer folks' vocabulary. How does a "use case" differ from a "use"?
>
> Clarity as to whether one is employing a noun or a verb. Both "use" and
> "case" can be either (he said, casing the joint for tomorrow's heist),
> but juxtaposing them thus unambiguously makes a noun phrase.
Usually context makes the nominal use of "use" clear : "many uses", "the
use",
"some uses". I'm not persuaded that "use case" disambiguates any more
reliably.
How do supermarkets display their wares?
For some use cases they use cases.
Metacomment. While the "use" in "nominal use" above must be a noun,
"nominal" isn't compelled to have the intended meaning of "being a noun".
It's a game of whac-a-mot. Kill one ambiguity and spawn another.
Doug
Two remarks about Plan 9, one about an antecedent and the other about the
limits of its influence.
"Communication files" in the Dartmouth Time Sharing System have been cited
as a predecesssor of Unix pipes, although we at Bell Labs were unaware of
the DTSS feature when pipes were first implemented. In fact, communication
files more directly foreshadow Plan 9 than they do Unix.
Unlike Unix processes, which need not be aware that they are talking to
pipes, the process at one end of a communication file, designated as
"master", must be aware that it is a communication file. The master end
controls the semantics of reads, writes and seeks(!) issued at the other
end. Because of this asymmetry, a communication file cannnot serve as a
pipe between pairs of unprepared processes. A pipe could be simulated in
DTSS by a master process that relays flow between communications files
connected to arbitrary end processes, but that seems never to have been
done.
Communication files are a closer antecedent to Plan 9. A master process's
controls correspond to the part of Plan 9's foundational 9P protocol that
handles open files. Though I don't think there's an actual ancestral
connection, this likeness strengthens DTSS's claim to fame and extends
their lead to nearly a quarter century.
Linux has adopted surface features of Plan 9 like union directories,
append-only files and system data access via file interfaces. Meanwhile
Plan 9's revolutionary realization of what Vic Vyssotsky called
distributable computing has not caught on. In distributable computing, the
physical location of processes does not affect their logical interaction.
In today's distributed computing, though, there is a world of difference
between how processes interact remotely and locally. When will the crevasse
between the possible and the normal be bridged?
Doug
Having recently read about the playful literary consortium, Oulipo, I am
reminded of their term for little-known antecedents of their revolutionary
works: "anticipatory plagiarism".
Long before there was Markdown, there was a similar Unix tool. I remember
reading about it before the Internet was popular, probably mid-to-late
1980s. I may have read about it in “Communications of the ACM”.
It was designed to let secretaries compose memos, without learning the dot
commands of troff or nroff. If you indented a space or two, it started a
new paragraph. If you indented several spaces, it centered the line; very
similar to Markdown in concept. It generated a file that could be fed into
troff.
I was thinking it might have been part of the System V Documentors
Workbench, but I read through the doc for it and could not find anything
like that.
Does anyone remember this?
Thanks!
Hi all, Edouard asked me to pass this e-mail on to both TUHS and COFF lists.
Cheers, Warren
----- Forwarded message from Edouard Klein <edouardklein(a)gmail.com> -----
Subject: History tract during the next IWMP9 in Paris next May
Date: Thu, 29 Aug 2024 22:46:30 +0200 (1 week, 4 days, 19 hours ago)
Dear Unix history enthusiasts,
The 11th International Workshop on Plan 9 will be held in Paris on May
22-24 2025.
One of the focus area this year will be Plan 9's history and its
influence on later computer science and industry trends.
The history team at the CNAM (where the conference will be held) has
agreed to help us prepare for the event and stands ready to record oral
histories, or any other format that would make the participants happy.
They had organized in 2017 a "colloque" at which Clem spoke (and I
listened somewhere in the audience) on UNIX:
https://technique-societe.cnam.fr/colloque-international-unix-en-europe-ent…
I will keep the list posted as our efforts pan out, but I thought I'd
get the word out as soon as possible.
I you have historical resources on Plan 9 or Inferno, or are reminded of
any interesting tidbits, you can also share them here, as this list is
already recognized by historians as a legitimate source.
The program committee members, many (if not all) of whom roam this very
list, would welcome any proposal or contributions in this area :)
The CfP is at:
http://iwp9.org/
Looking forward to read what you care to share, or to seeing you in
person in Paris,
Cheers,
Edouard.
----- End forwarded message -----
> From: Kevin Bowling
> https://gunkies.org/wiki/BSD/386 and the parent page on seem to suggest
> it originated off Net/2 directly.
I wouldn't be putting too much weight on what that page says; most of the
*BSD pages were done by people I don't know well, and who might have gotten
details wrong
I myself later just tried to quickly, without much effort, work out roughly
what the relationship was between those *BSD systems, based on what other
people had written. E.g the now-'BSD/OS' page was originally at '386/BSD',
and I seem to have worked out that it's correct name was BSD/OS and moved it
there. The BSD/386 page is probably roughly correct, since it contains a scan
of a contemporary ad for it.
(So confusing that '386BSD' is something different from 'BSD/386'. Was there ever
actually a '386/BSD'?)
Someone who knows the early history of all the *BSD systems (as in, you lived
through all that) is welcome, nay invited, to fix any errors therein.
Noel
So I was flipping through a System V software catalog from Fall 1984 and among
the many AT&T Bell Laboratories items is the "COBOL Syntax Checker".
From the text:
---QUOTE---
The COBOL Syntax Checker allows programmers to edit and check the syntax of COBOL
programs before they are transmitted to mainframes for compilation and execution.
The software increases the chances of a 'clean' compilation and execution and
reduces the chance of a program being rejected due to syntax and simple semantic
errors. As a result, expensive mainframe CPU time is reduced.
The COBOL Syntax Checker processes a COBOL source program and produces three
listings:
1. a diagnostic listing,
2. a cross-reference listing,
3. a source listing.
---END QUOTE---
There are two distributions listed, a C binary distribution for SVR2 for the
3B20 for $2000 and a C source distribution for SVR2 for the VAX 11/780 for $7500,
both listed as released 2Q84.
Some quick Googling only offers up additional catalog and magazine mentions.
To me this sounds like a linter with some extra bits. Does anyone have any
recollections of this software or know if there's much likelihood of the software
itself or any documentation surviving?
Thanks for any insights!
- Matt G.
