I heard we lost Brian Kantor WB6CYT recently. Those in the Amateur radio
community (esp. packet radio) will have heard of him of course, but
apparently he also had a hand in SMTP and NNTP (remember them?) both used
heavily many years ago, along with IPIP.
http://tech.slashdot.org/story/19/11/24/0051236/brian-kantor-internet-and-a…
-- Dave VK2KFU
Weird day...
Computer architect Gene Amdahl was born in on this day in 1922; he had a hand
in the IBM 704 and the System/360, founded Amdahl Corporation (maker of /360
clones), and devised Amdahl's Law in relation to parallel processing.
But we lost Jay W. Forrester in 2016; another computer pioneer, he invented
core memory (remember that, with its destructive read cycle?).
Oh, and LSD was first synthesised in 1938 by Dr. Hofmann of Sandoz Labs,
Switzerland; it had nothing to do with Berkeley and BSD, man...
-- Dave
On this day in 1970 computer pioneer Douglas Engelbart was awarded the patent
for the computer mouse. It was a fugly thing: just a squarish box with two
wheels underneath it mounted at right-angles and a button. Ergonomic it
wasn't...
-- Dave
Meant to go to the list...
-- Dave
---------- Forwarded message ----------
Date: Fri, 15 Nov 2019 07:23:19 +1100 (EST)
From: Dave Horsfall <dave(a)horsfall.org>
To: Paul Winalski
Subject: Re: [COFF] [TUHS] History of m6?
On Thu, 14 Nov 2019, Paul Winalski wrote:
> I used to think that "Emacs" stood for
> "escape-meta-alt-control-shift". :-) It's too finger-busy with all
> that alt, escape, and meta stuff for my taste.
Hey, that's a bit old :-)
Date: Sat, 2 Aug 2014 17:28:41 +0000
From: Benjamin Huntsman
To: "tuhs(a)minnie.tuhs.org" <tuhs(a)minnie.tuhs.org>
Subject: Re: [TUHS] Unix taste (Re: terminal - just for fun)
>> EMACS - eight megs and constantly swapping :)
>I like my own version: "Enough Memory? A Concept Strange!"
I thought it stood for Escape-Meta-Alt-Control-Shift :)
I thought I came up with it independently, but obviously it was in the back of
my mind.
-- Dave
Moving to a COFF
On Wed, Nov 13, 2019 at 4:16 AM Thomas Paulsen <thomas.paulsen(a)firemail.de>
wrote:
> 'T'was before my time, but the legend has it that the original BLISS-10 bootstrap
> compiler was a set of TECO macros that Chuck Geschke (Adobe's
> founder) wrote.'
> Really? TECO = Tape Editor and Corrector
TECO started as that for PDP-1 or maybe TX-1 (at MIT I believe). But over
time, TECO became the primary text editor on the PDP-10's for many, many
people in the ARPA community. I learned it as my second, PDP-10 text
editor (I learned a line editor, who's name I forget, that was similar to
the IBM's editor when I got my first PDP-10 account, but quickly moved to
TECO). FWIW: The original EMACS was a set of TECO macros. The historical
truth is that besides being the primary text editor, it was so rich in
function that TECO became for the PDP-10 what Jon Bentley describes as a
'little language' and was used for all sorts of small hacks.
The later Unix world created other tools, be it sed, later awk, and the
like. But for the PDP-10 world, TECO very much that low level engine that
a lot of people used.
When BLISS was written, CMU did not have UNIX (and thus nor any of the UNIX
tools - as I had a small hand in making UNIX happen @ CMU in the early
1970s). But when I arrived, the two PDP-10's (CMU-A and CMU-B) reigned
supreme as primary CS (and EE) systems, along with the CMU hacked version
of IBM's TSS running on the 360 for everyone else (and where I got my first
real programming job), plus CMU's own TSS/8 on couple of PDP-8s that were
scattered about.
FWIW: Chuck used the PDP-10's for his work as a grad student. He also is
famous for being the first PhD to produce his thesis on a 'laser printer',
the CMU XGP (it was not a laser as today, it was modified FAX machine made
by Xerox). The fun story is that CMU's administration would not accept
his thesis originally because the library wanted the 'originals' to put in
the archives. It took 6-9 months for his thesis advisor (Bill Wulf) to
convince the library, that they had the originals.
Anyway, the use of TECO in such a manner was very much the way things were
done in those days, so the legend is very much possible.
I suggest continuing this on COFF.
Thomas Paulsen wrote:
> I have a account on a remote twenex PDP10. There is a editor named
> emacs. This is a very archaic piece of software. It doesn't know any
> teco commands no matter how I tried. I'm pretty sure that this is
> teco-emacs.
Yes, it should be TECO Emacs. Normal use of Emacs rarely needs TECO
commands.
To get a TECO minibuffer type Meta-Altmode (Esc Esc). You should get a
small window at the top of the terminal in which you can enter TECO
commands. Execute them with double altmode as you would in any TECO.
> I draw my own conclusions from these observations which are far away
> from all these myths.
I try to stay with the facts. I actually use TECO Emacs almost daily,
and I have built it from sources. Some other information is based on
email conversations among those who wrote Emacs.
On 2019-Nov-12 17:49:46 -0500, Arthur Krewat <krewat(a)kilonet.net> wrote:
>On 11/12/2019 5:41 PM, Robert Clausecker wrote:
>> Oh please no. One of the things we've hopefully all learned from Pascal
>> is that length-prefixed strings suck because you can't perform anything
>> useful without copying the entire string.
Keep in mind that C doesn't have a "string" type. The use of a NUL
terminated char array is purely convention. There's nothing to stop
someone using a length-prefixed array (though there's virtually no
standard library support for that).
>> Rob Pike and friends showed
>> how to get strings and vectors right in the Go language where you have a
>> builtin slice type which is essentially a structure
>>
>> struct slice(type) {
>> type *data;
>> size_t len, cap;
>> };
That approach would have incurred a 12-byte overhead for each string or
vector on a PDP-11 - that would have been a substantial disincentive on
a memory-constrained system.
>And none of that stops some programmer from doing slice.cap=255 - or is
>it read-only? ;)
Slices and strings are built-in types in Go. They can be modelled as the
above structure but that is an implementation detail. It is possible to
reduce the capacity of a slice (but not a string) but attempting to
increase it will result in a runtime exception ("panic" in Go speak).
--
Peter Jeremy
Computer scientist Per Brinch Hansen was born on this day in 1938; he was known
for his work on "monitors" (now known as operating systems), concurrent
programming, parallel processing, etc.
-- Dave
(Narrowly diverted in time to COFF from TUHS when I saw Warren's email, so
I hope Warner is on it.)
On Tue, 12 Nov 2019, Warner Losh wrote:
> POSIX can't even recognize that leap seconds exist :(
There's a movement afoot to abolish leap seconds because they are
"inconvenient" or something; that will upset the astronomers and other
people who care about the exact time.
> All is not lost, though; use strncpy() instead of strcpy() etc.
>
> strncpy has two issues. First, it doesn't guarantee NUL termination.
> Second, it always writes N bytes. It's for a fixed width data field, not
> a variable length string whose buffer size is known. strlcpy is much
> better, but still has some issues...
Yeah, I knew about the NUL termination (or lack of it) - I didn't think to
mention it. When I use it, I copy n-1 bytes and plant the NUL in there
myself (depending on how I'm using it).
And I wasn't aware of strlcpy() - thanks. Too many functions to keep
track of these days....
Trivia: curious to see how Australia's "talking clock" (long gone in
favour of NTP, alas) handled the leap second, I recorded it (it puts a gap
before the last beep). It can be heard (and seen!) over on
www.horsfall.org/leapsecond.webm .
And yes, that old long-haired hippie is me...
-- Dave