> From: Clem Cole
> the idea of a text editor existed long before Ken's version of QED,
> much less, ed(1). Most importantly, Ken's QED came after the original
> QED, which came after other text editors.
Yes; some of the history is given here:
An incomplete history of the QED Text Editor
https://www.bell-labs.com/usr/dmr/www/qed.html
Ken would have run into the original on the Berkeley Time-Sharing System; he
apparently wrote the CTSS one based on his experience with the one on the BTSS.
Oddly enough, CTSS seems to have not had much of an editor before. The
Programmer's Guide has an entry for 'Edit' (Section AH.3.01), but 'edit file'
seems to basically do a (in later terminology) 'cat >> file'. Section AE
seems to indicate that most 'editing' was done by punching new cards on a
key-punch!
The PDP-1 was apparently similar, except that it used paper tape. Editing
paper tapes was difficult enough that Dan Murphy came up with TECO - original
name 'Tape Editor and Corrector':
https://opost.com/tenex/anhc-31-4-anec.pdf
> Will had asked -- how did people learn to use reg-ex?
I learned it from reading the 'sh' and 'ed' V6 man pages.
The MIT V6 systems had TECO (with a ^R mode even), but I started out with ed,
since it was more like editors I had previously used.
Noel
Might interest the bods here too...
-- Dave
---------- Forwarded message ----------
From: Paul Ruizendaal
To: "tuhs(a)tuhs.org" <tuhs(a)tuhs.org>
Subject: [TUHS] RIP Niklaus Wirth, RIP John Walker
Earlier this year two well known computer scientists passed away.
On New Year’s Day it was Niklaus Wirth aged 90. A month later it was John Walker aged 75. Both have some indirect links to Unix.
For Wirth the link is that a few sources claim that Plan 9 and the Go language are in part influenced by the design ideas of Oberon, the language and the OS. Maybe others on this list know more about those influences.
For Walker, the link is via the company that he was running as a side-business before he got underway with AutoCAD: https://www.fourmilab.ch/documents/marinchip/
In that business he was selling a 16-bit system for the S-100 bus, based around the TI9900 CPU (which from a programmer perspective is quite similar to a PDP11). For that system he wrote a Unix-like operating system around 1978-1980, called NOS/MT. He had never worked with Unix, but had spelled the BSTJ issues about it. It was fully written in assembler.
The design was rather unique, maybe inspired by Heinz Lycklama’s “Satellite Processor” paper in BSTJ 57-6. It has a central microkernel that handles message exchange, process scheduling and memory management. Each system call is a message. However, the system call message is then passed on to a privileged “fat kernel” process that handles it. The idea was to provide multiprocessor and network transparency: the microkernel could decide to run processes on other boards in the same rack or on remote systems over a network. Also the kernel processes could be remote. Hence its name “Network Operating System / Multitasking” or “NOS/MT”.
The system calls are pretty similar to Unix. The file system is implemented very similar to Unix (with i-nodes etc.), with some notable differences (there are file locking primitives and formatting a disk is a system call). File handles are not shareable, so special treatment for stdin/out/err is hardcoded. Scheduling and memory management are totally different -- unsurprising as in both cases it reflects the underlying hardware.
Just as NOS/MT was getting into a usable state, John decided to pivot to packaged software including a precursor of what would become the AutoCAD package. What was there worked and saw some use in the UK and Denmark in the 1980’s -- there are emulators that can still run it, along with its small library of tools and applications. “NOS/MT was left in an arrested state” as John puts it. I guess it will remain one of those many “what if” things in computer history.
A friend of mine has a DECmate-II word processor. It is in perfect
working order except for one thing. The field encoding the current
date/time has overflowed. It is impossible to set a date/time in the
21st century.
He says that the software in question is a version of WPS-8 for the
PDP-8. It should be possible to fix the date/time problem by dumping
the DECmate's ROM and disassembling the code. It ought not be too
hard to locate the date/time encode/decode routine and come up with a
fix to the time epoch problem.
Is anyone out there familiar with the DECmate-II software? Or, even
better, knows how to get its source code?
Advice greatly appreciated.
-Paul W.
I've just uploaded a couple new items to archive.org that
folks may find interesting:
https://archive.org/details/5ess-2000-switch-es5431-office-data-base-1998https://archive.org/details/5ess-2000-switch-es5432-system-analysis-1998
Linked above are the ES5431 (Office Data Base Installation)
and ES5432 (System Analysis) training CDs as produced by
Bell Laboratories (Lucent era) for the 5ESS-2000 switch.
Among other things, these CDs contain a 5ESS simulator which
you can see a screenshot of here:
https://www.classicrotaryphones.com/forum/index.php?topic=28001.msg269652#m…
I was able to successfully get it to run on Windows 98 SE in
a virtual machine, although did break one rule of archiving
optical media in that I didn't take iso rips. I intend to
throw an old FreeBSD hard disk in that computer sometime soon
and do some proper rips with dd(1). In the meantime,
this means using the above archives presents only a partial
experience in that the Training section of the software
appears to depend on the original discs being inserted.
In any case, the simulator interests me greatly. I intend
to do a little digging around in it as time goes on to see
if there may be traces of 3B20 emulation or DMERT in the
guts. I'm not holding my breath, but who knows. Either way,
it'll be interesting to play with. Thus far I've only
verified the simulator launches, but have done nothing
with it yet. Picked up Steele's Common Lisp (2nd Edition)
in the same eBay session so time will be split between this,
learning Lisp, and plenty of other little oddball projects
I have going, but if I find anything interesting I'll be
sure to share.
Given that Nokia is shedding 5ESS stuff pretty heavily right
now (or so I've heard) I have to wonder if more of this
stuff will start popping up in online market places. Word
over on the telephone forum is that some folks in Nokia
do have an interest in preserving 5ESS knowledge and
materials but are getting the expected apathy and lack of
engagement from higher ups. Hopefully this at least means
Nokia doesn't mind too much this stuff getting archived if
they don't have to do any of the footwork :)
- Matt G.
On Wed Feb 23 16:33, 1994, I turned on the web service on my machine
"minnie", originally minnie.cs.adfa.edu.au, now minnie.tuhs.org (aka
www.tuhs.org) The web service has been running continuously for thirty
years, except for occasional downtimes and hardware/software upgrades.
I think this makes minnie one of the longest running web services
still in existence :-)
For your enjoyment, I've restored a snapshot of the web site from
around mid-1994. It is visible at https://minnie.tuhs.org/94Web/
Some hyperlinks are broken.
## Web Logs
The web logs show me testing the service locally on Feb 23 1994,
with the first international web fetches on Feb 26:
```
sparcserve.cs.adfa.oz.au [Wed Feb 23 16:33:13 1994] GET / HTTP/1.0
sparcserve.cs.adfa.oz.au [Wed Feb 23 16:33:18 1994] GET /BSD.html HTTP/1.0
sparcserve.cs.adfa.oz.au [Wed Feb 23 16:33:20 1994] GET /Images/demon1.gif HTTP/1.0
...
estcs1.estec.esa.nl [Sat Feb 26 01:48:21 1994] GET /BSD-info/BSD.html HTTP/1.0
estcs1.estec.esa.nl [Sat Feb 26 01:48:30 1994] GET /BSD-info/Images/demon1.gif HTTP/1.0
estcs1.estec.esa.nl [Sat Feb 26 01:49:46 1994] GET /BSD-info/cdrom.html HTTP/1.0
shazam.cs.iastate.edu [Sat Feb 26 06:31:20 1994] GET /BSD-info/BSD.html HTTP/1.0
shazam.cs.iastate.edu [Sat Feb 26 06:31:24 1994] GET /BSD-info/Images/demon1.gif HTTP/1.0
dem0nmac.mgh.harvard.edu [Sat Feb 26 06:32:04 1994] GET /BSD-info/BSD.html HTTP/1.0
dem0nmac.mgh.harvard.edu [Sat Feb 26 06:32:10 1994] GET /BSD-info/Images/demon1.gif HTTP/1.0
```
## Minnie to This Point
Minnie originally started life in May 1991 as an FTP server running KA9Q NOS
on an IBM XT with a 30M RLL disk, see https://minnie.tuhs.org/minannounce.txt
By February 1994 Minnie was running FreeBSD 1.0e on a 386DX25 with 500M
of disk space, 8M of RAM and a 10Base2 network connection. I'd received a copy
of the BSDisc Vol.1 No.1 in December 1993. According to the date on the file
`RELNOTES.FreeBSD` on the CD, FreeBSD 1.0e was released on Oct 28 1993.
## The Web Server
I'd gone to a summer conference in Canberra in mid-February 1994 (see
pg. 29 of https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V15.1.pdf
and https://minnie.tuhs.org/94Web/Canberra-AUUG/cauugs94.html, 10am)
and I'd seen the Mosaic web browser in action. With FreeBSD running on
minnie, it seemed like a good idea to set up a web server on her.
NCSA HTTPd server v1.1 had been released at the end of Jan 1994, see
http://1997.webhistory.org/www.lists/www-talk.1994q1/0282.html
It was the obvious choice to be the web server on minnie.
## Minnie from Then to Now
You can read more about minnie's history and her hardware/software
evolution here: https://minnie.tuhs.org/minnie.html
I obtained the "tuhs.org" domain in May 2000 and switched minnie's
domain name from "minnie.cs.adfa.edu.au" to "minnie.tuhs.org".
Cheers!
Warren
P.S. I couldn't wait until Friday to post this :-)
After learning of Dave's death, a professor I very much enjoyed as a U
of Delaware EE student, I came across this page
https://www.eecis.udel.edu/~mills/gallery/gallery9.html
This reminds me of his lectures, the occasional 90 degree turn into who
knows what, but guaranteed to be interesting. And if anyone has a UDel
Hollerith card they're willing to part with, please get in touch. I
have none. :-(
Mike Markowski
Howdy folks, just finished an exciting series of repairs and now have a DEC VT100 plumbed into a Western Electric Data Set 103J. I was able to supply an answer tone (~2250Hz) at which point the modem began transmitting data. I could then pull the answer tone down and the connection remained, with keypresses on the VT100 properly translating to noise on the line.
Really all I have left is to see if it can do the real thing. I'm keeping an eye out for another such modem but in the meantime, is anyone aware of any 300-baud systems out there in the world that are currently accepting dials in? I don't have POTS at home but they do at my music practice space and if there is such a machine out there, I kinda wanna take my terminal and modem down there and see if I can straight up call a computer over this thing.
I've got other experiments planned too like just feeding it 300-baud modem noise to see if I get the proper text on the screen, that sort of thing, but figured this would be an interesting possibility to put feelers out for.
On that same note, if I get another modem and a stable POTS number to expose it via, I'm considering offering the same, a 300-baud UNIX-y system folks can just call and experiment with (realistically probably a SimH machine with the pty/tty socat'd together)
- Matt G.
Seen on TUHS...
-- Dave
---------- Forwarded message ----------
Date: Sat, 20 Jan 2024 12:27:41 +1000
From: George Michaelson <ggm(a)algebras.org>
To: The Eunuchs Hysterical Society <TUHS(a)tuhs.org>
Subject: [TUHS] (Off topic) Dave Mills
Dave Mills, of fuzzball and ntp fame, one time U Delaware died on the 17th
of January.
He was an interesting, entertaining, prolific and rather idosyncratic
emailer. Witty and informative.
G
Not really UNIX -- so I'm BCC TUHS and moving to COFF
On Tue, Jan 9, 2024 at 12:19 PM segaloco via TUHS <tuhs(a)tuhs.org> wrote:
> On the subject of troff origins, in a world where troff didn't exist, and
> one purchases a C/A/T, what was the general approach to actually using the
> thing? Was there some sort of datasheet the vendor supplied that the end
> user would have to program a driver around, or was there any sort of
> example code or other materials provided to give folks a leg up on using
> their new, expensive instrument? Did they have any "packaged bundles" for
> users of prominent systems such as 360/370 OSs or say one of the DEC OSs?
>
Basically, the phototypesetter part was turnkey with a built-in
minicomputer with a paper tape unit, later a micro and a floppy disk as a
cost reduction. The preparation for the typesetter was often done
independently, but often the vendor offered some system to prepare the PPT
or Floppy. Different typesetter vendors targeted different parts of the
market, from small local independent newspapers (such as the one my sister
and her husband owned and ran in North Andover MA for many years), to
systems that Globe or the Times might. Similarly, books and magazines
might have different systems (IIRC the APS-5 was originally targeted for
large book publishers). This was all referred to as the 'pre-press'
industry and there were lots of players in different parts.
Large firms that produced documentation, such as DEC, AT&T *et al*., and
even some universities, might own their own gear, or they might send it out
to be set.
The software varied greatly, depending on the target customer. For
instance, by the early 80s, the Boston Globe's input system was still
terrible - even though the computers had gotten better. I had a couple of
friends working there, and they used to b*tch about it. But big newspapers
(and I expect many other large publishers) were often heavy union shops on
the back end (layout and presses), so the editors just wanted to set strips
of "column wide" text as the layout was manual. I've forgotten the name of
the vendor of the typesetter they used, but it was one of the larger firms
-- IIRC, it had a DG Nova in it. My sister used CompuGraphic Gear, which
was based on 8085's. She had two custom editing stations and the
typesetter itself (it sucked). The whole system was under $35K in
late-1970s money - but targeted to small newspapers like hers. In the
mid-1908s, I got her a Masscomp at a reduced price and put 6 Wyse-75
terminals on it, so she could have her folks edit their stories with vi,
run spell, and some of the other UNIX tools. I then reverse-engineered the
floppy enough to split out the format she wanted for her stories -- she
used a manual layout scheme. She still has to use the custom stuff for
headlines and some other parts, but it was a load faster and more parallel
(for instance, we wrote an awk script to generate the School Lunch menus,
which they published each week).
ᐧ
[TUHS bcc, moved to COFF]
On Thursday, January 4th, 2024 at 10:26 AM, Kevin Bowling <kevin.bowling(a)kev009.com> wrote:
> For whatever reason, intel makes it difficult to impossible to remove
> the ME in later generations.
Part of me wonders if the general computing industry is starting to cheat off of the smartphone sector's homework, this phenomenon where whole critical components of a hardware device you literally own are still heavily controlled and provisioned by the vendor unless you do a whole bunch of tinkering to break through their stuff and "root" your device. That I can fully pay for and own a "computer" and I am not granted full root control over that device is one of the key things that keeps "smart" devices besides my work issued mobile at arms length.
For me this smells of the same stuff, they've gotten outside of the lane of *essential to function* design decisions and instead have now put in a "feature" that you are only guaranteed to opt out of by purchasing an entirely different product. In other words, the only guaranteed recourse if a CPU has something like this going on is to not use that CPU, rather than as the device owner having leeway to do what you want. Depends on the vendor really, some give more control than others, but IMO there is only one level of control you give to someone who has bought and paid for a complete device: unlimited. Anything else suggests they do not own the device, it is a permanently leased product that just stops requiring payments after a while, but if I don't get the keys, I don't consider myself to own it, I'm just borrowing it, kinda like how the Bell System used to own your telephone no matter how many decades it had been sitting on your desk.
My two cents, much of this can also be said of BIOS, UEFI, anything else that gets between you and the CPUs reset vector. Is it a nice option to have some vendor provided blob to do your DRAM training, possibly transition out of real mode, enumerate devices, whatever. Absolutely, but it's nice as an *option* that can be turned off should I want to study and commit to doing those things myself. I fear we are approaching an age where the only way you get reset vector is by breadboarding your own thing. I get wanting to protect users from say bricking the most basic firmware on a board, but if I want to risk that, I should be completely free to do so on a device I've fully paid for. For me the key point of contention is choice and consent. I'm fine having this as a selectable option. I'm not fine with it becoming an endemic "requirement." Are we there yet? Can't say, I don't run anything serious on x86-family stuff, not that ARM and RISC-V don't also have weird stuff like this going on. SBI and all that are their own wonderful kettle of fish.
BTW sorry that's pretty rambly, the lack of intimate user control over especially smart devices these days is one of the pillars of my gripes with modern tech. Only time will tell how this plays out. Unfortunately the general public just isn't educated enough (by design, not their own fault) on their rights to really get a big push on a societal scale to change this. People just want I push button I get Netflix, they'll happily throw all their rights in the garbage over bread and circuses....but that ain't new...
- Matt G.
