From clemc at ccc.com Mon Jan 1 05:29:53 2024 From: clemc at ccc.com (Clem Cole) Date: Sun, 31 Dec 2023 14:29:53 -0500 Subject: [COFF] [simh] Old VAX/VMS Tapes In-Reply-To: <17A5C98F69111E59.18542@groups.io> References: <656c72ae-2b6e-487c-a7bc-6e3a3896b49f@ieee.org> <53587999-897f-4b69-b476-b1c83dfaf816@ieee.org> <2cafc131-3e5d-4bf1-b0ee-537e3ed0f4cd@ieee.org> <75e8f333-98fc-45da-b109-fedaa9d78fdb@ieee.org> <17A5C98F69111E59.18542@groups.io> Message-ID: Small PS below... On Sat, Dec 30, 2023 at 9:27 PM Clement T Cole via groups.io wrote: > > I did not say that or imply it. But variable vs. fixed blocking has > implications on both mechanical requirements and ends up being reflected in > how the sw handles it. Traditional 9-track allows you to mix record sizes > on each tape. Streamer formats don’t traditionally allow that because they > restrict / remove inter record gaps in the same manner 9-track supports. > This increases capacity of the tape (less waste). > In my explanation, I may have been a tad confusing. When I say fixed records -- I mean on-tape fixed records, what the QIC-24/120/150 standard refers to as: "*A group of consecutive bits comprising of a preamble, data block marker, a single data block, block address and CRC and postamble*" [the standard previous defines a data black os 512 consecutive bytes] --* i.e*., if you put an o'scope on the tape head and looked at the bit stream (see page 16 of QIC-120 Rev F - Section 5 "Recorded Block" for a picture of this format -- note is can only address 2^20 blocks per track, but it supports addressing to 256 tracks -- with 15 tracks of QIC-120 that means 15728640 unique 512-byte blocks). STOP/STOP does something similar but encodes the LRECL used [I don't have the ANSI tape standard handy - but I remember seeing a wonderful picture of all this from said documents when I first was educated about tapes in my old IBM days ~50 years ago]. After each record, STOP/STOP needs an "Inter-Record-Gap" (IRC) to allow for the motor's spin-up/spin-down time before continuing the bit stream of the next data block. The IRC distance is something like 5-10 mm [which is a great deal compared to the size of a bit when using GCR encoding (which is what 6250 BPI and QIC both use). These gaps take space (capacity) from the tape, so people tend to write with larger blocking factors [UNIX traditionally uses 10240 bytes- other systems use other values - as I said, I believe the standard says the max is 64K bytes). Since streamers (like QIC tape) are supposed to be continuous, the QIC inter-records gaps resemble fixed disk records and can be extremely small. Remember, each bit is measured in micrometers -- about *2 micrometers*, IIRC for QIC and around 10 for ½" formats -- again, and I would need to check the ANSI spec, which is not handy. But this is a huge space savings even with a smallish block (512) -- again - this was lifted from disk technology of the day which had often standardized on 512 8-bit byte blocks by then. BTW: this is again why I suspect a TK25 tape is not going to be able to read on QIC-24/120/150 drive if, indeed, page 1-5 of the TK25 user manual says it supports four different block sizes [1K/2K/4K/8K]. First, the data block format would have to be variable to 4 sizes, and second, the preamble would need to encode and write what size block to expect on read. Unfortunately, that document does not say much more about the physical tape format other than it can use cartridges "similar to ANSI Standard X3.55-1982" (which is a 3M DC-600A tape cartridge), has "11 tracks, 8000 bpi" recording density (/w 10000 flux reversals per in), using a "single track NRZI dat in a serpentine pattern, with 4-5 run length limited code similar to GCR." That said, most modern SW will allow you to *write* different size record sizes (LRECL) in the user software, but the QIC drives and I believe things like DAT and Exabyte will only write 512-byte blocks, so somewhere between your user program and tape itself, the write will be broken into N 512 byte blocks and then pad (with null is typical) the last block to 512 bytes. My memory is the QIC standard is silent on where that is done, but I suspect it's done in the controller and the driver is forced to send it 512-byte blocks. So, while you may define blocks of different sizes, unlike ½", it will always be written as 512-byte blocks. That said, using larger record sizes in your application SW can have huge performance wins (which I mentioned in my first message) - *e.g.*, keeping the drive streaming as more user data has been locked down in memory for a DMA. But by the time the driver and the controller are finished, it's fixed 512-byte blocks on the tape. One other thing is WRT to QIC, which differs from other schemes. I previously mentioned tape files - a feature of the ½" physical tape formats not typically supported for QIC tapes. QIC has an interesting feature that allows a block to be rewritten and replaced later on the tape (see the section of spec/you user manual WRT for "rewritten" or "replacement "blocks). I've forgotten all the details, but I seem to remember that features were why multiple tape files were difficult to implement. Someone who knows more about tapes may remember the details/be able to explain -- I remember dealing with tape files was a PITA in QIC, and the logic in a standard ½" tape driver could not be just cloned for the QIC driver. ᐧ ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Jan 1 07:38:45 2024 From: clemc at ccc.com (Clem Cole) Date: Sun, 31 Dec 2023 16:38:45 -0500 Subject: [COFF] [simh] Old VAX/VMS Tapes In-Reply-To: <17A601627CB0546A.18542@groups.io> References: <656c72ae-2b6e-487c-a7bc-6e3a3896b49f@ieee.org> <53587999-897f-4b69-b476-b1c83dfaf816@ieee.org> <2cafc131-3e5d-4bf1-b0ee-537e3ed0f4cd@ieee.org> <75e8f333-98fc-45da-b109-fedaa9d78fdb@ieee.org> <17A5C98F69111E59.18542@groups.io> <17A601627CB0546A.18542@groups.io> Message-ID: Dyslexia sucks... sorry, if it was not obvious, please globally substitute s:STOP/STOP:START/STOP: ᐧ On Sun, Dec 31, 2023 at 2:30 PM Clement T Cole via groups.io wrote: > Small PS below... > > On Sat, Dec 30, 2023 at 9:27 PM Clement T Cole via groups.io ccc.com at groups.io> wrote: > >> >> I did not say that or imply it. But variable vs. fixed blocking has >> implications on both mechanical requirements and ends up being reflected in >> how the sw handles it. Traditional 9-track allows you to mix record sizes >> on each tape. Streamer formats don’t traditionally allow that because they >> restrict / remove inter record gaps in the same manner 9-track supports. >> This increases capacity of the tape (less waste). >> > > In my explanation, I may have been a tad confusing. When I say fixed > records -- I mean on-tape fixed records, what the QIC-24/120/150 standard > refers to as: "*A group of consecutive bits comprising of a preamble, > data block marker, a single data block, block address and CRC and postamble*" > [the standard previous defines a data black os 512 consecutive bytes] --* > i.e*., if you put an o'scope on the tape head and looked at the bit > stream (see page 16 of QIC-120 Rev F - Section 5 "Recorded Block" for a > picture of this format -- note is can only address 2^20 blocks per track, > but it supports addressing to 256 tracks -- with 15 tracks of QIC-120 that > means 15728640 unique 512-byte blocks). > > STOP/STOP does something similar but encodes the LRECL used [I don't have > the ANSI tape standard handy - but I remember seeing a wonderful picture of > all this from said documents when I first was educated about tapes in my > old IBM days ~50 years ago]. After each record, STOP/STOP needs an > "Inter-Record-Gap" (IRC) to allow for the motor's spin-up/spin-down time > before continuing the bit stream of the next data block. The IRC distance > is something like 5-10 mm [which is a great deal compared to the size of a > bit when using GCR encoding (which is what 6250 BPI and QIC both use). > These gaps take space (capacity) from the tape, so people tend to write > with larger blocking factors [UNIX traditionally uses 10240 bytes- other > systems use other values - as I said, I believe the standard says the max > is 64K bytes). > > Since streamers (like QIC tape) are supposed to be continuous, the QIC > inter-records gaps resemble fixed disk records and can be extremely small. > Remember, each bit is measured in micrometers -- about *2 micrometers*, > IIRC for QIC and around 10 for ½" formats -- again, and I would need to > check the ANSI spec, which is not handy. But this is a huge space savings > even with a smallish block (512) -- again - this was lifted from disk > technology of the day which had often standardized on 512 8-bit byte blocks > by then. > > BTW: this is again why I suspect a TK25 tape is not going to be able to > read on QIC-24/120/150 drive if, indeed, page 1-5 of the TK25 user manual > says it supports four different block sizes [1K/2K/4K/8K]. First, the > data block format would have to be variable to 4 sizes, and second, the > preamble would need to encode and write what size block to expect on > read. Unfortunately, that document does not say much more about the > physical tape format other than it can use cartridges "similar to ANSI > Standard X3.55-1982" (which is a 3M DC-600A tape cartridge), has "11 > tracks, 8000 bpi" recording density (/w 10000 flux reversals per in), using > a "single track NRZI dat in a serpentine pattern, with 4-5 run length > limited code similar to GCR." > > That said, most modern SW will allow you to *write* different size record > sizes (LRECL) in the user software, but the QIC drives and I believe things > like DAT and Exabyte will only write 512-byte blocks, so somewhere between > your user program and tape itself, the write will be broken into N 512 byte > blocks and then pad (with null is typical) the last block to 512 bytes. > My memory is the QIC standard is silent on where that is done, but I > suspect it's done in the controller and the driver is forced to send it > 512-byte blocks. > > So, while you may define blocks of different sizes, unlike ½", it will > always be written as 512-byte blocks. > > That said, using larger record sizes in your application SW can have huge > performance wins (which I mentioned in my first message) - *e.g.*, > keeping the drive streaming as more user data has been locked down in > memory for a DMA. But by the time the driver and the controller are > finished, it's fixed 512-byte blocks on the tape. > > > One other thing is WRT to QIC, which differs from other schemes. I > previously mentioned tape files - a feature of the ½" physical tape formats > not typically supported for QIC tapes. QIC has an interesting feature that > allows a block to be rewritten and replaced later on the tape (see the > section of spec/you user manual WRT for "rewritten" or "replacement > "blocks). I've forgotten all the details, but I seem to remember that > features were why multiple tape files were difficult to implement. > Someone who knows more about tapes may remember the details/be able to > explain -- I remember dealing with tape files was a PITA in QIC, and the > logic in a standard ½" tape driver could not be just cloned for the QIC > driver. > ᐧ > ᐧ > ᐧ > _._,_._,_ > ------------------------------ > Groups.io Links: > > You receive all messages sent to this group. > > View/Reply Online (#3631) | Reply > To Group > > | Reply To Sender > > | Mute This Topic | New Topic > > Your Subscription | Contact > Group Owner | Unsubscribe > [ > clemc at ccc.com] > _._,_._,_ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Jan 4 05:35:00 2024 From: crossd at gmail.com (Dan Cross) Date: Wed, 3 Jan 2024 14:35:00 -0500 Subject: [COFF] Sad news: Niklaus Wirth Message-ID: [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. From brantley at coraid.com Thu Jan 4 05:44:10 2024 From: brantley at coraid.com (Brantley Coile) Date: Wed, 3 Jan 2024 14:44:10 -0500 Subject: [COFF] [TUHS] Sad news: Niklaus Wirth In-Reply-To: References: Message-ID: Sorry to hear. I knew him, I flew us across the US in a small single engine airplane, a rare blessing in a blessed life. We share the month of February as a birth date and would exchange emails every year. (Thompson is another in the February club.) Dennis once said that if you look at C and Pascal you might think there was information exchange, even though there was none. Oberon is Pascal++, ++. Over the years C got more type-safe and Klaus' language got more flexible. Most of the objections to Pascal were gone after he designed Oberon. Very sad. Brantley > On Jan 3, 2024, at 2:35 PM, Dan Cross wrote: > > [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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: HOPL2009Jun09-2.jpg Type: image/jpeg Size: 99296 bytes Desc: not available URL: From coff at tuhs.org Thu Jan 4 15:52:16 2024 From: coff at tuhs.org (segaloco via COFF) Date: Thu, 04 Jan 2024 05:52:16 +0000 Subject: [COFF] Seeking March 1980 Bell Laboratories Record (And New/Ongoing ESS Scans) Message-ID: 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. From coff at tuhs.org Fri Jan 5 05:10:02 2024 From: coff at tuhs.org (segaloco via COFF) Date: Thu, 04 Jan 2024 19:10:02 +0000 Subject: [COFF] Intel ME, UEFI, User Control was Re: Question about BSD disklabel history Message-ID: [TUHS bcc, moved to COFF] On Thursday, January 4th, 2024 at 10:26 AM, Kevin Bowling 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. From crossd at gmail.com Fri Jan 5 07:20:44 2024 From: crossd at gmail.com (Dan Cross) Date: Thu, 4 Jan 2024 16:20:44 -0500 Subject: [COFF] Intel ME, UEFI, User Control was Re: Question about BSD disklabel history In-Reply-To: References: Message-ID: On Thu, Jan 4, 2024 at 2:20 PM segaloco via COFF wrote: > [TUHS bcc, moved to COFF] > > On Thursday, January 4th, 2024 at 10:26 AM, Kevin Bowling 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. We've been there for a while. I've been swimming in these waters for a couple of years now, and it _is_ an issue. That said, I can kind of sympathize with the vendors to an extent; they're between a rock and a hard place in a lot of ways. Starting up a modern CPU (even one in an end-user device like a phone or a laptop) is, I imagine, a bit like starting the engines on a container ship. You don't just press a switch and have massive two-story diesel pistons start firing in enormous cylinders; instead, you push a switch which starts an electric motor which turns on something like a V8 engine, which starts up a larger engine that starts the process of compressing the big pistons so the thing can start; it's a slow, multi-stage process out of physical necessity. Modern CPUs follow a similar process: you apply power to a board and it's going to do all sorts of stuff like power sequencing for DIMM sockets, asking them what's there, whether they're working properly, etc. Then there's turning on thermal sensors, the IO bus, flash, etc. A slew of internal diagnostics are going to run across a number of components. And all of this is happening before you even begin bringing the CPU socket online, let alone allowing the CPUs to come out of reset. And most of this is going to be done with FPGAs or little rinky-dink microcontrollers embedded in various places (an interesting exercise might be trying to count the number of CPUs on a modern mainboard): and that's not even counting the CPUs on IO devices. Most of those aren't just hidden, they're invisible to anyone other than the device manufacturer. Even if I had the documentation and the means to replace the images in those disparate components, it'd be a daunting task from a time/reward perspective. Most of the time, it's just not possible. How did we get here? Well, in part because systems are a lot more complex now than they were in the past, and that has reflected itself back onto software. The reality is that, for most users, even those who care about what software they run, most of this stuff just isn't that _interesting_. We care what runs on the x86 CPU (or whatever) sure, but how many people even _know_ about the little CPU embedded in their USB flash stick? So there's little incentive for the software vendors to put a lot of effort into supporting this stuff, and so it falls on board vendors, who just do what they've got to do to ship a product. I've mentioned the Oxide architecture before: we have no UEFI and we have no BIOS. We also designed our own custom boards. At Oxide, we build a service processor board based on an ARM Cortex-M profile microcontroller that runs its own OS that we built in-house most of the pre-CPU-poweron tasks. And yet, there are still some things that we can't get away from (firmware on peripherals, and the aforementioned PSP). The PSP is an interesting case in point; even if we _wanted_ to bypass it entirely, we can't; it's built into the CPU SoC complex and it's just how the thing works. And we build the computers! Imagine the situation for a user of a commodity COTS system. > 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... I think most people just want a computer (or phone, tablet, whatever) at all and the entire system has congealed (again, to use Roscoe's term) around the way that things are now. Even for those of us who don't like it, it's damned hard to change the status quo. - Dan C. From nevin at eviloverlord.com Fri Jan 5 08:14:23 2024 From: nevin at eviloverlord.com (Nevin Liber) Date: Thu, 4 Jan 2024 16:14:23 -0600 Subject: [COFF] [TUHS] Re: Intel ME, UEFI, User Control was Re: Question about BSD disklabel history In-Reply-To: References: Message-ID: On Thu, Jan 4, 2024 at 1:10 PM segaloco via TUHS wrote: > 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. > Except for a lot of devices, you haven't "fully paid for" it, because the price most people pay up front takes into account other revenue streams. Take smart TVs for example: < https://www.businessinsider.com/smart-tv-data-collection-advertising-2019-1 >. That being said, of course they want to keep those revenue streams going as long as possible, and once done, they aren't going to pay for any engineering effort to remove it. How much more are you willing to pay up front for that same TV (2x? 3x? 4x?), and are there enough of you for a manufacturer to offer it? 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. Now scale it. How do you keep bad actors from bricking *my* device, especially if my device is on the internet? Then scale it to all the security threats besides DoS. You can disagree with the solutions to these threats, but please don't minimize that these are very real threats. 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. That is a pretty arrogant statement. It is far more likely that, instead of the rest of us not being as educated as you, we just value different things. Traditional Unix systems have, at best, focused on the developer experience, and have been dwarfed for decades by systems companies focusing on the *user* experience. I'm old enough to remember the decades when Unix was always just a year away from doing better than being a distant third behind Windows and Mac OS on the desktop. I want devices that are easy to get things done, don't require much futzing, and isn't a nightmare for my life (due to my data that it can access) if I happen to break it, lose it or it gets stolen. For example: last year when I was hiking in the AZ desert, I got an email about winning a lottery that I had entered for inexpensive show tickets for the next day, and I bought tickets securely with Apple Pay before the deadline expired. All of that was performed confidently and securely with my iPhone (well, I possibly got the email notification on my watch). While it may not be the world you want to participate in or care about, that is the kind of amazing experience that I value, and it seems the kind of experience that lots of people value, as evidenced by the size of the smartphone market compared with the size of the computer market. The open source world and hackable hardware world don't offer this kind of experience. > People just want I push button I get Netflix, Why wouldn't you?? While Netflix isn't perfect, are you seriously arguing people should *want* a far worse user experience? > they'll happily throw all their rights in the garbage over bread and > circuses....but that ain't new... > It isn't about happily throwing away "rights" (whatever that means). It's about we aren't willing to *pay* for it. It's a tradeoff, and those who want everything hackable haven't shown much value to the rest of us, and there are very real concerns about the costs both in terms of security threats and monetary costs. -- Nevin ":-)" Liber +1-847-691-1404 -------------- next part -------------- An HTML attachment was scrubbed... URL: From silent700 at gmail.com Fri Jan 5 09:02:37 2024 From: silent700 at gmail.com (Jason T) Date: Thu, 4 Jan 2024 17:02:37 -0600 Subject: [COFF] Seeking March 1980 Bell Laboratories Record (And New/Ongoing ESS Scans) In-Reply-To: References: Message-ID: On Thu, Jan 4, 2024, 00:10 segaloco via COFF wrote: > > 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. > Hi Matt - my spreadsheet tells me that I have the March 1980 issue of the Record. Locating the box it's in will be a little more difficult but I will start the search. If it's in decent condition, I will scan it and post the link. J -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Fri Jan 5 12:03:16 2024 From: coff at tuhs.org (segaloco via COFF) Date: Fri, 05 Jan 2024 02:03:16 +0000 Subject: [COFF] [TUHS] Re: Intel ME, UEFI, User Control was Re: Question about BSD disklabel history In-Reply-To: References: Message-ID: On Thursday, January 4th, 2024 at 2:14 PM, Nevin Liber wrote: > It isn't about happily throwing away "rights" (whatever that means). It's about we aren't willing to pay for it. It's a tradeoff, and those who want everything hackable haven't shown much value to the rest of us, and there are very real concerns about the costs both in terms of security threats and monetary costs.-- > > Nevin ":-)" Liber +1-847-691-1404 I've tried (and failed) at a thoughtful response a few times now, so I think I need to at least accept that yeah, I'm in the extreme minority in not preferring convenience over autonomy. Good luck with this conversation, I don't think I have anything else to contribute, I think I'm on a different world than the prevailing opinions on this stuff...but such is life. Better than an echo chamber that's for sure. - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Jan 5 12:35:35 2024 From: crossd at gmail.com (Dan Cross) Date: Thu, 4 Jan 2024 21:35:35 -0500 Subject: [COFF] [TUHS] Re: Intel ME, UEFI, User Control was Re: Question about BSD disklabel history In-Reply-To: References: Message-ID: On Thu, Jan 4, 2024 at 5:15 PM Nevin Liber wrote: >[snip] >> 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. > > Now scale it. How do you keep bad actors from bricking *my* device, especially if my device is on the internet? The obvious answer is, "by preventing bad actors from getting access to the means to manipulate your firmware." > Then scale it to all the security threats besides DoS. You can disagree with the solutions to these threats, but please don't minimize that these are very real threats. This is a false dichotomy, as one must bear in mind that the _existing_ firmware may already be vulnerable. We saw this with the infamous `strncmp` bug on the Intel ME a few years ago, and we saw it again just the other day with the JPEG parser bug in a number of UEFI installations in the wild. _An_ issue with closed and hidden firmware blobs is that you just don't know; that is, it's not just about abstract notions of freedom but also about transparency. >> 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. > > That is a pretty arrogant statement. It is far more likely that, instead of the rest of us not being as educated as you, we just value different things. > > Traditional Unix systems have, at best, focused on the developer experience, and have been dwarfed for decades by systems companies focusing on the *user* experience. I'm old enough to remember the decades when Unix was always just a year away from doing better than being a distant third behind Windows and Mac OS on the desktop. > > I want devices that are easy to get things done, don't require much futzing, and isn't a nightmare for my life (due to my data that it can access) if I happen to break it, lose it or it gets stolen. One of the reasons I use a Mac is because macOS _is_ Unix on the desktop. :-) > For example: last year when I was hiking in the AZ desert, I got an email about winning a lottery that I had entered for inexpensive show tickets for the next day, and I bought tickets securely with Apple Pay before the deadline expired. All of that was performed confidently and securely with my iPhone (well, I possibly got the email notification on my watch). While it may not be the world you want to participate in or care about, that is the kind of amazing experience that I value, and it seems the kind of experience that lots of people value, as evidenced by the size of the smartphone market compared with the size of the computer market. > > The open source world and hackable hardware world don't offer this kind of experience. Ironically, the systems you mentioned are built on Unix and open source software as a foundation. >> People just want I push button I get Netflix, > > Why wouldn't you?? While Netflix isn't perfect, are you seriously arguing people should want a far worse user experience? > >> >> they'll happily throw all their rights in the garbage over bread and circuses....but that ain't new... > > It isn't about happily throwing away "rights" (whatever that means). It's about we aren't willing to pay for it. It's a tradeoff, and those who want everything hackable haven't shown much value to the rest of us, and there are very real concerns about the costs both in terms of security threats and monetary costs. I get the whole "different strokes for different folks" argument, but I think you may be underestimating the impact that the whole hackable thing has had. The whole industry seems to be over a barrel with the way that things have evolved. In many respects, we have amazing technology that lets us do really cool things (cf your examples above) and that's both valuable and important. On the other hand, in a lot of ways, it feels like we're just waiting for the other shoe to drop with something going really wrong in a hurry because we've undervalued investment in the foundations for too long. UEFI is a train wreck; ACPI is a train wreck; a lot of binary-only firmware is of dubious (at best) quality and provenance, but the industry writ large doesn't have a better solution to the real problems with these specific technologies. It's a real problem waiting to happen, and it does us as engineers, researchers, computer scientists, etc, no good to minimize that. - Dan C. From clemc at ccc.com Wed Jan 10 08:07:40 2024 From: clemc at ccc.com (Clem Cole) Date: Tue, 9 Jan 2024 17:07:40 -0500 Subject: [COFF] [TUHS] Re: Original print of V7 manual? / My own version of troff In-Reply-To: References: <20240108032428.co3ozmlneoop6sa2@illithid> <20240108051049.7643537404E9@freecalypso.org> <20240108071109.ykg42tw2gjeacs5f@illithid> <20240109093851.2A29737401E3@freecalypso.org> Message-ID: Not really UNIX -- so I'm BCC TUHS and moving to COFF On Tue, Jan 9, 2024 at 12:19 PM segaloco via TUHS 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). ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Wed Jan 10 17:25:38 2024 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 10 Jan 2024 07:25:38 +0000 Subject: [COFF] [TUHS] Re: Original print of V7 manual? / My own version of troff In-Reply-To: (Clem Cole's message of "Tue, 9 Jan 2024 17:07:40 -0500") References: <20240108032428.co3ozmlneoop6sa2@illithid> <20240108051049.7643537404E9@freecalypso.org> <20240108071109.ykg42tw2gjeacs5f@illithid> <20240109093851.2A29737401E3@freecalypso.org> Message-ID: <7wv881tzt9.fsf@junk.nocrew.org> Clem Cole writes: > 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. Here's something about Camex used at Boston Globe. https://gunkies.org/wiki/Camexec Any comments or additions to this? I occasionally bug Speciner about scanning his printouts. From clemc at ccc.com Thu Jan 11 03:26:02 2024 From: clemc at ccc.com (Clem Cole) Date: Wed, 10 Jan 2024 12:26:02 -0500 Subject: [COFF] [TUHS] Re: Original print of V7 manual? / My own version of troff In-Reply-To: <7wv881tzt9.fsf@junk.nocrew.org> References: <20240108032428.co3ozmlneoop6sa2@illithid> <20240108051049.7643537404E9@freecalypso.org> <20240108071109.ykg42tw2gjeacs5f@illithid> <20240109093851.2A29737401E3@freecalypso.org> <7wv881tzt9.fsf@junk.nocrew.org> Message-ID: Rich Salz reminded me of the name of the system I was thinking of -- Atex. Given my later interactions with their editorial and IT departments, I'm not sure that Carnex was in the production system there (particularly given the Gunkies description). I never saw it but it could have been before anyone I knew was working there. By the mid/late 80's, they were using Atex for most things. FWIW: By the mid/late 1980s, the IBM PC had been out for a few years, and many people had access to DOS systems. At the Globe, their Atex System had a 300-baud modem on it (and it was 300 baud, not 1200 because the IT folks at the Globe claimed that the Atex required something special about that model modem -- I never knew what -- I've always guessed it was something to do with the maintenance contract not technical but it was not my job -- I just took it as a wonderment and dealt with it). But the big feature Atex offered the Globe was it allowed the reporters to upload and spool their stories, and then the Atex set the type for the editors independent of the filing. But the reporters had to file their story using a very rigid format convention that they all hated (*i.e.*, ask humans to conform to the needs of the computer, not the other way round). By then, most of the reporters used a PC and a simple word processor to edit and then upload to Atex via a terminal emulator program such as ProComm or Kermit. The Atex side was exceedingly dumb and unforgiving. If the user or the system made any error, Atex would toss the story (*i.e.,* not put anything in the spool), and there was no communications protection so that line noise could cause issues. I never saw their side, but I gather Atex was not too friendly to the editors, as there was no way to find out what had been accepted remotely, so they often had to ask the reporters to file the stories multiple times. My sister was working as an occasional stringer for them, given her statehouse connections. I got her to get me the specs for the Atex input system, and I wrote some scripts for her to use the Masscomp box to prep her stories for them and send them off to the Atex System. I became an informal help desk for several of her reporter and photographer friends. :-) I have some interesting stories WRT to all that - but they are not particularly computer-based -- the Richard Reed (the shoe bomber) story and its famous picture you have all undoubtedly seen is one of my favorites. Clem ᐧ On Wed, Jan 10, 2024 at 2:25 AM Lars Brinkhoff wrote: > Clem Cole writes: > > 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. > > Here's something about Camex used at Boston Globe. > https://gunkies.org/wiki/Camexec > > Any comments or additions to this? > > I occasionally bug Speciner about scanning his printouts. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sun Jan 21 06:48:46 2024 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 21 Jan 2024 07:48:46 +1100 (EST) Subject: [COFF] [TUHS] (Off topic) Dave Mills (fwd) Message-ID: Seen on TUHS... -- Dave ---------- Forwarded message ---------- Date: Sat, 20 Jan 2024 12:27:41 +1000 From: George Michaelson To: The Eunuchs Hysterical Society 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 From clemc at ccc.com Sun Jan 21 08:33:46 2024 From: clemc at ccc.com (Clem Cole) Date: Sat, 20 Jan 2024 17:33:46 -0500 Subject: [COFF] [TUHS] (Off topic) Dave Mills (fwd) In-Reply-To: References: Message-ID: There has been a lot of discussion on the Internet History list. Vint is putting together a file of Mill's stories. [While I met him a few times, I did not know him very well, so I'm not going to be a source of any of them]. ᐧ On Sat, Jan 20, 2024 at 4:50 PM Dave Horsfall wrote: > Seen on TUHS... > > -- Dave > > ---------- Forwarded message ---------- > Date: Sat, 20 Jan 2024 12:27:41 +1000 > From: George Michaelson > To: The Eunuchs Hysterical Society > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjenkin at canb.auug.org.au Sun Jan 21 10:50:07 2024 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Sun, 21 Jan 2024 11:50:07 +1100 Subject: [COFF] (Off topic) Dave Mills In-Reply-To: References: Message-ID: <3A209BF5-756D-452F-AE4F-77D15C1D43E3@canb.auug.org.au> This list post by Vint Points to this Google Doc > On 21 Jan 2024, at 09:33, Clem Cole wrote: > > There has been a lot of discussion on the Internet History list. Vint is putting together a file of Mill's stories. > [While I met him a few times, I did not know him very well, so I'm not going to be a source of any of them]. -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From rtomek at ceti.pl Sun Jan 21 15:03:56 2024 From: rtomek at ceti.pl (Tomasz Rola) Date: Sun, 21 Jan 2024 06:03:56 +0100 Subject: [COFF] (Off topic) Dave Mills (fwd) In-Reply-To: References: Message-ID: On Sun, Jan 21, 2024 at 07:48:46AM +1100, Dave Horsfall wrote: > Seen on TUHS... > > -- Dave > > ---------- Forwarded message ---------- > Date: Sat, 20 Jan 2024 12:27:41 +1000 > From: George Michaelson > To: The Eunuchs Hysterical Society > 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 An article on Ars Technica with a bunch of links: https://arstechnica.com/gadgets/2024/01/inventor-of-ntp-protocol-that-keeps-time-on-billions-of-devices-dies-at-age-85/ and some reflections from HN users with some more tech-related links: https://news.ycombinator.com/item?id=39051246 -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From coff at tuhs.org Tue Jan 23 14:38:38 2024 From: coff at tuhs.org (segaloco via COFF) Date: Tue, 23 Jan 2024 04:38:38 +0000 Subject: [COFF] Any 300-Baud Dataset Systems Up? Message-ID: 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. From coff at tuhs.org Tue Jan 23 16:15:01 2024 From: coff at tuhs.org (Arno Griffioen via COFF) Date: Tue, 23 Jan 2024 07:15:01 +0100 Subject: [COFF] Any 300-Baud Dataset Systems Up? In-Reply-To: References: Message-ID: On Tue, Jan 23, 2024 at 04:38:38AM +0000, segaloco via COFF wrote: > is anyone aware of any 300-baud systems out there in the world that are > currently accepting dials in? This should be one that should even work over VOIP (eg. using a modem connected to a POTS 'phone' port on a VOIP gateway) via a 300BPS modem: https://bbs.retrobattlestations.com/ 916 965 1701 Bye, Arno. From clemc at ccc.com Wed Jan 24 06:32:14 2024 From: clemc at ccc.com (Clem Cole) Date: Tue, 23 Jan 2024 15:32:14 -0500 Subject: [COFF] Any 300-Baud Dataset Systems Up? In-Reply-To: References: Message-ID: On Mon, Jan 22, 2024 at 11:39 PM segaloco via COFF wrote: > 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. > There are plenty to be found, so I'm not going to answer that question directly but offer a slightly different possibility, which might make debugging easier. If you have a second (known working) modem, get something like the Viking DLE-200B, which is about $125 or less on eBay/Amazon or the like. It will simulate a traditional POTS line -- has two RJ11 ports in it. I used to have access to a similar unit a few years ago (it actually could support 4 lines, IIRC), but for your purposes, I suspect it will work. But that makes everything a closed system under your control. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: