- COFF - www.tuhs.org

Re: [TUHS] Mailer History -- was Berkeley CSRG Building

by Steffen Nurpmeso

Kevin Bowling wrote in <CAK7dMtAH0km=RLqY0Wtuw6R7jXyWg=xQ+SPWcQA-PLLaTZii0w(a)mail.gmail.com>: |On Wed, Aug 14, 2024 at 11:59 AM segaloco via TUHS <tuhs(a)tuhs.org> wrote: |> On Wednesday, August 14th, 2024 at 9:45 AM, Clem Cole <clemc(a)ccc.com> \ |> wrote: |>> ... |>> The issue came when people started using the mail system as a programmat\ |>> ic messaging scheme (i.e., fork: some_program | mail user) and other \ |>> programs started to parse the output. |>> ... |> Mail as IPC...that's what I'm reading from that anyway...now that's \ |> an interesting concept. Did that idea ever grow any significant \ |> legs? I can't tell if the general concept is clever or systems abuse, \ |> in those days it seems like it could've gone either way. | |I like Clem's answer on mail IPC/RPC. | |To add I have heard some stories of NNTP being used once upon a time |at some service providers the way ansible/mcollective/salt might be |used to orchestrate UNIX host configurations and application |deployments. The concept of Control messages is somewhat critical to |operations, so it's not totally crazy, but isolating article flows |would give me some heartburn if the thing has privileged system |access.. would probably want it on a totally distinct |instance+port+configuration. | |Email and Usenet both have some nice properties of implementing a |"Message Queue" like handling offline hosts when they come back. But |the complexity of mail and nntp implementations lean more towards |system abuse IMO. The IETF will go for SML (structured email) https://datatracker.ietf.org/group/sml/about/ which then goes for machine interpretable email message( part)s. |> I guess it sorta did survive in the form of automated systems today \ |> expecting specially formatted emails to trigger "stuff" to happen. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

4 months, 1 week

1
0
0 0

Re: [TUHS] Re: Mailer History -- was Berkeley CSRG Building

by Clem Cole

Matt - I'm going to BCC: TUHS and move this to COFF - since while UNIX was certainly in the mix in all this, it was hardly first or the only place it happenned. On Wed, Aug 14, 2024 at 2:59 PM segaloco via TUHS <tuhs(a)tuhs.org> wrote: > On Wednesday, August 14th, 2024 at 9:45 AM, Clem Cole <clemc(a)ccc.com> > wrote: > > > > > ... > > The issue came when people started using the mail system as a > programmatic messaging scheme (i.e., fork: some_program | mail user) and > other programs started to parse the output. > > ... > > Mail as IPC...that's what I'm reading from that anyway...now that's an > interesting concept. It's kind of funny the history. ARPANET gives us FTP as a way to exchange files. So, people figure out how to hack the mailer to call FTP to send a file remotely and set up a submit a cron/batch submission, a.k.a RJE. This is encouraged by DARPA because part of the justification of the ARAPNET was to be able to share resources, and this enables supercomputers of the day to be able to provide cycles to DARPA folks who might not have access to larger systems. Also, remember, mailers were local to systems at that point. So someone gets the bright idea to hooker the mailer into this system -- copy the "mail file" and set up a remote job to mail it locally. Let's just say this prioves to be a cool idea and the idea of intersystem email begins in the >>ARPANET<< community. So the idea of taking it to the next level was not that far off. The mailer transports started to offer (limited) features to access services. By the time of Kurt's "delivermail" but he added a feature, thinking it was system logs that allowed specific programs to be called. In fact, it may have been invented elsewhere but before Eric would formalize "vacation" - Jim Kleckner and I hacked together a "awk" script to do that function on the UCB CAD 4.1 systems. I showed it to Sam and a few other people, and I know it went from Cory to Evans fairly quickly. Vacation(1) was written shortly there after to be a bit more flexible than our original script. Did that idea ever grow any significant legs? I guess the word here is significant. It certainly was used where it made sense. In the CAD group, we had simulations that might run for a few days. We used to call the mailer every so often to send status and sometimes do something like a checkpoint. It lead to Sam writing syslogd, particularly after Joy created UNIX domain sockets. But I can say we used it a number of places in systems oriented or long running code before syslogd as a scheme to log errors, deal with stuff. > I can't tell if the general concept is clever or systems abuse, in those > days it seems like it could've gone either way. > > I guess it sorta did survive in the form of automated systems today > expecting specially formatted emails to trigger "stuff" to happen. Exactly. ᐧ

4 months, 1 week

1
0
0 0

Re: [TUHS] SDF Beget's ICM - Interim Computer Museum

by Clem Cole

Greg, this needs to move to COFF, so I'm BCCing TUHS in my reply. (My error in the original message was that I should have BCC'd everyone but COFF, so replies were directed there. Mei culpa). However, since I have seen different people on all these lists bemoan the loss of the LCM+L, I hope that by the broader announcement, a number of you will consider the $36/yr membership to help Stephen and his team to be able to keep these systems running and the at least the "labs" port of the old LCM+L mission alive. On Thu, Aug 1, 2024 at 9:56 PM Gregg Levine <gregg.drwho8(a)gmail.com> wrote: > Hello! > Pardon me for asking Clem, but would you mind naming the survivors? The details are still coming out from Stephen and friends -- I would recommend listening to his presentation and then maybe joining the List Server at SDF by sending a (plain text) email to majordomo(a)sdf.org with the subject and body containing the line: subscribe museum-l I have an idea what these Toads are, and of course what Multics happened to > be, but that's it. > LCM+L owned a real Honeywell 6180 front panel. The folks in their lab interfaced it to a microcontroller (I think it was an RP3 or 4, but it could be something like a BeagleBone, I never knew). It was running Multics Release 12.8 on a SimH-derived Honeywell 6180 [I'm not sure if those changes ever made it back to OpenSIMH - I have not personally tried it myself]. This system seems to have been moved to SDF's new site. Also, a number of the MIT Multics tapes had been donated to the LCM+L. These have survived, and the SDF has them. I'll not repeat Stephen's report here, but he describes what they have and are doing. Miss Piggy is the PDP 11/70 that Microsoft purchased and used for their SW original development. It has been running a flavor of Unix Seventh Edition - I do not know what type of updates were added, but I expect the DEC v7m and the V7 addendum to be there. You can log in and try it yourself by ssh menu(a)sdf.org" and picking Miss Piggy in the UNIX submenu. Miss Piggy used to live and be on display at the LCM+L, but Stephen and the SDF were involved in its admin/operation. Stephen says in his presentation that they are trying to get Miss Piggy back up and running [my >>guess<< is that the "Miss Piggy" instance on the SDF menu is currently running on an OpenSIMH instance while the real hardware is being set up at the new location]. In the early 1980s, as DEC started to de-commit to the 36-bit line after they introduced the 32-bit Vax systems, a number of PDP-10 clones appeared on the market. For instance, the System Concepts SC-40 was what Comp-U-Serve primarily switched to. Similarly, many ex-Stanford AI types forked to create the Toad Systems XXL, a KL10 clone. SDF and LCM+L owned several of these two styles of systems and were on display and available for login. Since Twenex.org is live (and has been) and Stephen shows a picture of the SC40, again, I am (again) >>guessing<< that these have all been moved to the new location for SDF. Stephen mentioned in his presentation that they have the LCM-L's Vax7000 but do not yet have the 3-phase power in their computer room. He suggested that it is one of the most popular machines in the SDF menu, and they intend to make it live shortly. It is unclear what became of some of the other items. It was pointed out that running a CDC6500 is extremely expensive to operate from a power standpoint, so they offer an NOS login using the DTCyber simulator. He never mentioned what became of the former Purdue machine that the LCM owned and had restored. I am interested in knowing what happened to the two PDP-7s. I know that at least one was privately owned, but was being restored and displayed at the LCM+L. It was one of these systems that Unix V0 was resurrected and ran for the UNIX 50th Anniversary Party that the LCM+L hosted. The LCM+L had some interesting peripherals. For instance, the console for Miss Piggy was a somewhat rare ASR37 [which is Upper/Lower case and the "native" terminal for Research Unix]. I hope they have it also. The LCM+L had a number of different types of tape transports for recovering old data. Stephen mentioned that they have some of these but did not elaborate. Clem

4 months, 2 weeks

3
2
0 0

Re: [TUHS] Re: SDF Beget's ICM - Interim Computer Museum

by Lars Brinkhoff

I think this is off topic for TUHS and more appropriate for COFF. Gregg Levine wrote: > Pardon me for asking Clem, but would you mind naming the survivors? I > have an idea what these Toads are, and of course what Multics happened > to be, but that's it. We don't know exactly yet, but according to the video, there's a VAX 7000 and a DEC-2020. The TOAD computers are XKL's PDP-10 remake; there's also another one called SC-40. Stephen also mentions Multics tapes were rescued. Maybe the best way to see what is there right now, is to dial into "ssh menu(a)sdf.org" [-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-] -+- SDF Vintage Systems REMOTE ACCESS -+- [-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-] [a] multics Multics MR12.8 Honeywell 6180 [b] toad-2 TOPS-20 7(110131)-1 XKL TOAD-2 [c] twenex TOPS-20 7(63327)-6 XKL TOAD-2 [d] sc40 TOPS-20 7(21733) SC Group SC40 [e] lc ITS ver 1648 PDP-10 KS10 [f] ka1050 TOPS-10 6.03a sim KA10 1050 [g] kl2065 TOPS-10 7.04 sim KL10 2065 [h] rosenkrantz OpenVMS 7.3 VAX 7000-640 [i] tss8 TSS/8 PDP-8/e [j] ibm4361 VM/SP5 Hercules 4361 [k] ibm7094 CTSS i7094 [l] cdc6500 NOS 1.3 DTCyber CDC-6500 [z] bitzone NetBSD BBS AMD64 [1] Proceed to the UNIX Systems sub-menu [2] Information about Vintage Systems at SDF.ORG And the Unix section: [a] misspiggy UNIX v7 PDP-11/70 [c] lcm3b2 UNIX SVR3.2.3 AT&T 3B2/1000-70 [d] guildenstern BSD 4.3 simh MicroVAX 3900 [e] snake BSD 2.11 PDP-11/84 [f] hkypux HP/UX 10.20 HP9000/715 [g] truly TRU64 5.0 DEC Alpha 500au [h] three SunOS 4.1.1 Sun-3/160 [i] indy IRIX 6.5 SGI Indy R5000 [j] ultra Ultrix 4.5 simh MicroVAX 3900

4 months, 3 weeks

1
0
0 0

SDF Beget's ICM - Interim Computer Museum

by Clem Cole

Please excuse the wide distribution, but I suspect this will have general interest in all of these communities due to the loss of the LCM+Labs. The good folks from SDF.org are trying to create the Interim Computer Museum: https://icm.museum/join.html As Lars pointed out in an earlier message to COFF there is a 1hr presentation on the plans for the ICM. https://toobnix.org/w/ozjGgBQ28iYsLTNbrczPVo FYI: The yearly (Bootstrap) subscription is $36 They need to money to try to keep some of these systems online and available. The good news is that it looks like many of the assets, such as Miss Piggy, the Multics work, the Toads, and others, from the old LCM are going to be headed to a new home. ᐧ

4 months, 3 weeks

1
0
0 0

Commodity hardware for paper terminal experience

by Sijmen J. Mulder

Hi all, Some time ago I dived into ed and tried programming with it a bit. It was an interesting experience but I feel like the scrolling visual terminal can't properly emulate the paper terminal. You can't do rip out a printout and put it next to you, scribble on it, etc. I'd like to try replicating the experience more closely but I'm not interested in acquiring collector's items or complex mechanical hardware. There don't seem to be contemporary equivalents of the TI Silent 700 so I've been looking at are standalone printing devices to combine with a keyboard. But the best I can find is line printing, which is unsuitable for input. Any suggestions? Sijmen

4 months, 3 weeks

3
2
0 0

Re: [TUHS] Re: UNIX Roff Manual

by John R Levine

> Yeah, I wasn't specific enough. > The ownership of the model 67 changed to the State of NJ, but it was > operated and present at Princeton, until replaced by a 370/158, which in > turn changed owners back to Princeton in 75. > > What OS did you use on the 67? On the /67 I used TSS with a free account they gave me for being in a local computer club. On the /91 I mostly used the free stuff but one summer in the early 70s I had a job speeding up an Ecom professor's Fortran model. Compiling it with Fortran H rather than G, and adjusting an assembler routine that managed an external file not to open and close the file on every call helped a lot. Paul Hilfinger had a long career at UC Berkeley and is easy to find if you want to ask him if he has any of his old papers. R's, John > > On Wed, Jul 17, 2024 at 6:58 PM John Levine <johnl(a)taugh.com> wrote: > >> It appears that Tom Lyon <pugs78(a)gmail.com> said: >>> -=-=-=-=-=- >>> >>> Jonathan - awesome! >>> Some Princeton timing: the 360/67 arrived in 1967, but was replaced in the >>> summer of 1969 by the 360/91. >> >> No, the /67 and /91 were there at the same time. I used them both in high >> school. >> I graduated in 1971 so that must have been 1969 to 71, and when I left I'm >> pretty >> sure both were still there. >> >> R's, >> John >> >> >>> BWK must've got started on the 7094 that preceded the 67, but since it was >>> FORTRAN the port wasn't hard. >>> Now I wonder what Paul Hilfinger did and whether it was still FORTRAN. >>> >>> I graduated in 1978, ROFF usage was still going strong! >>> >>> On Wed, Jul 17, 2024 at 5:42 PM Jonathan Gray <jsg(a)jsg.id.au> wrote: >>> >>>> On Wed, Jul 17, 2024 at 09:45:57PM +0000, segaloco via TUHS wrote: >>>>> On Wednesday, July 17th, 2024 at 1:51 PM, segaloco < >>>> segaloco(a)protonmail.com> wrote: >>>>> >>>>>> Just sharing a copy of the Roff Manual that I had forgotten I >> scanned a little while back: >>>>>> >>>>>> https://archive.org/details/roff_manual

5 months

1
0
0 0

Re: ancient macros, machine code translation,as mental architecture models

by Douglas McIlroy

In 1959, when Doug Eastwood and I, at the suggestion of George Mealy, set out to add macro capability to SAP (Share assembly program), the word "macro"--short for "macroinstruction"--was in the air, though none of us had ever seen a macroprocessor. We were particularly aware that GE had a macro-capable assembler. I still don't know where or when the term was coined. Does anybody know? We never considered anything but recursive expansion, where macro definitions can contain macro calls; thus the TX-0 model comes as quite a surprise. We kept a modest stack of the state of each active macro expansion. We certainly did not foresee that within a few years some applications would need a 70-level stack! General stack-based programming was not common practice (and the term "stack" did not yet exist). This caused disaster the first time we wrote a macro that generated a macro definition, because a data-packing subroutine with remembered state, which was used during both definition and expansion, was not reentrant. To overcome the bug we had in effect to introduce another small stack to keep the two uses out of each other's way. Luckily there were no more collisions between expansion and definition. Moreover, this stack needed to hold only one suspended state because expansion could trigger definition but not vice versa. Interestingly, the problem in the previous paragraph is still with us 65 years later in many programming languages. To handle it gracefully, one needs coroutines or higher-order functions. Doug

5 months

5
6
0 0

The inexorable passage of time

by Adam Thornton

I was idly leafing through Padlipsky's _Elements Of Network Style_ the other day, and on page 72, he was imagining a future in which a cigar-box sized PDP-10 would be exchanging data with a breadbox-sized S/370. And here we are, only 40 years later, and 3 of my PDP-10s and my S/370 are all running on the same cigarette-pack sized machine, which cost something like $75 ($25 in 1984 dollars). Adam

5 months, 1 week

2
1
0 0

Re: machine code translation,as mental architecture models

by Douglas McIlroy

> the DEC PDP-1 MACRO assembler manual says that a macro call > is expanded by copying the *sequence of 'storage words' and > advancing the current location (.) for each word copied* > I am quite surprised. I am, too. It seems that expansion is not recursive. And that it can only allocate storage word by word, not in larger blocks. Doug

5 months, 1 week

5
7
0 0

2024

2023

2022

2021

2020

2019

2018

COFF