COFF January 2024

coff@tuhs.org

11 participants
6 discussions

by segaloco

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.

11 months

[TUHS] (Off topic) Dave Mills (fwd)

by Dave Horsfall

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

11 months

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

by Clem Cole

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). ᐧ

11 months, 2 weeks

Re: Intel ME, UEFI, User Control was Re: Question about BSD disklabel history

by segaloco

[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.

11 months, 3 weeks

Seeking March 1980 Bell Laboratories Record (And New/Ongoing ESS Scans)

by segaloco

Hello, I wanted to share this evening a scan I just finished. It is linked to in this thread where I will continue adding ESS-related materials (for those interested in that sort of thing): http://www.classicrotaryphones.com/forum/index.php?topic=28001.0 The document therein is the Guide to Stored Program Control Switching, a Bell System document concerning #1 and #2 ESS telephone exchanges and varieties of networking connections. It's interesting in that the guide is three separate little flip decks of cards, some of which can represent steps in a network. Flip to the components you need and the traces at the edges meet to create a diagram of that particular configuration. I quite like the concept, seems like a great way to visualize variable networks. Anywho, as mentioned I'm going to be putting some more ESS stuff up there, mostly related to 5ESS and 3B20 computers. That seems to now squarely be my main documentation focus since I'm starting to bleed the Bell System UNIX well a bit dry of stuff I can randomly find on eBay. 5ESS and 3B20 are still adjacent enough that I'm sure UNIX-y things will be scattered throughout this material. Finally, a long shot but is anyone aware of preserved copies (or in possession of) the March 1980 issue of the Bell Laboratories Record? An index on archive.org indicates that issue has a focus piece on the 3B20 which I am quite interested in getting eyes on. I've come across several other copies around this time frame, some of which I've purchased to scan, but not this one yet. As always happy to answer any questions about what I'm working on or consider scanning jobs for other documentation folks have leads on, happy new year everyone! - Matt G.

11 months, 3 weeks

Sad news: Niklaus Wirth

by Dan Cross

[TUHS as Bcc] I just saw sad news from Bertrand Meyer. Apparently, Niklaus Wirth passed away on the 1st. :-( I think it's fair to say that it is nearly impossible to overstate his influence on modern programming. - Dan C.

11 months, 3 weeks

2024

2023

2022

2021

2020

2019

2018

COFF January 2024