https://www.theregister.com/2025/11/07/unix_fourth_edition_t...
Unix V4 is otherwise lost. It was the first version in C.
This video on the linked github page for the analysis software[1] is interesting:
> This is rare enough that I'm pushing the recovery
> of it up near the top of my project queue.
Tapes from back then haven’t held up over the years. It all depends on the environment it was stored in.
Check out this extraction/decoding of a 1987 VHS recording of The Cure:
https://www.youtube.com/watch?v=ks1wE_NXWv8
Play if full screen at whatever the highest resolution your screen can take advantage of, It's amazing! Check out the quality of the big headshots of Robert Smith, the resolution of stuff like his hair is way beyond what I believed VHS to be capable of - based on growing up recording similar music acts in the 70s and 80s.
Here's the software (and descriptions of the hardware and VHS player mods) they use:
https://github.com/oyvindln/vhs-decode
I suspect the recording technique/format on those is a similar analog signal on the tape - and from The Reg's article (quoting various sources) it sounds like they're already planning on similar approach:
"The software librarian at the CHM is the redoubtable Al Kossow of Bitsavers, who commented in the thread that he is on the case. On the TUHS mailing list, he explained how he plans to do it:
taping off the head read amplifier, using a multi-channel high speed analog to digital converter which dumps into 100-ish gigabytes of RAM, then an analysis program Len Shustek wrote: https://github.com/LenShustek/readtape
It is a '70s 1200ft 3M tape, likely 9 track, which has a pretty good chance of being recoverable."
And then the ones with manual tracking are even more rare, or out of the price range, which you likely need as the tracks degrade.
So I wondered about a modern day equivalent, looked up 1tb micro-sd cards (sold locally for Nintendo Switch) and calculated that there'd be roughly space for 400 exabytes of data in a shipping container filled to the brim with SD-cards.
(SDcard being 1tb for 1.092 x 1,499 x 0,102 CM's and a shipping container being 1203 x 235 x 239 CM's inside so holding 400 million SD cards)
That's because whoever's attempting to load an ideal 400 million micro-SD cards into one will take approximately forever carefully trying to line up even one row of them on the floor of a shipping container, before having the whole thing fall over like dominoes.
And even if they manage that, the whole thing will tumble over once they need to deal with the first row of the container's side corrugation. Nobody at the department of Spherical Cows in Vacuums thought to account for those dimensions[1] not lining up with the size of micro-SD cards.
If they do manage some approximation of this it'll take forever just to drive this down the road, let alone get the necessary permits to take the thing on the highway.
Turns out not a lot of semi truck trailers or roads are prepared to deal with a 40 ft container weighing around 100 metric tons (the weight of one packed to the brim with sand, a close approximation).
The good news is that such transportation gets more fuel efficient the longer the trip is.
The bad news is that the container will arrive mostly empty, as it's discovered that shipping container door panel gaps and road vibrations conspire to spread a steady stream of micro-SD cards behind you the entire way there.
Commuters in snowy areas held up behind the slowly moving "OVERSIZED LOAD!" with a mandatory police escort wonder if it's a trial for a new type of road salt that makes a pleasant crunchy sound as you drive over it.
Finally, an attempt to recover the remaining data fails. The sharding strategy chosen didn't account for failure due to road salt ingression into the container, cards at the bottom of the container being crushed to dust by the weight of those above, or that the leased container hadn't been thoroughly cleaned since last transporting, wait, what is that smell?
1. https://www.discovercontainers.com/wp-content/uploads/contai...
That's not even mentioning Australian road trains that seem to commonly pull around 150 tons with some being up to 200 tons (The load would be slightly spread out to more containers but still one truck-load).
Still, 400 million SD-cards is still a silly experiment.
Also, packing it up "taking forever" is irrelevant, that's latency, not bandwidth.
He started with "Well, first we need to know how big our station wagon is. I hereby arbitrarily declare it to be a 1985 Volvo 240, which has 2.2 cubic metres of cargo capacity." and "I'm also going to assume that the wagon isn't really packed totally full of memory cards, such that they cascade into the front whenever you brake and will avalanche out of the tailgate when it's opened. Let's say they are packed almost to the roof of the car, but in cardboard boxes, which reduce the usable cargo capacity to a nice round two cubic metres."
The calculated "Assuming uniform and perfect stacking of objects of this volume, with zero air space, you can fit 24,242,424 of them into two cubic metres."
But he also addressed the packing problem, saying:
"In the real world there'd obviously be air spaces, even if you painstakingly stack the tiny cards in perfect layers. My size approximation, that ignores the more-than-0.5mm height of the thick end of the card, could make the perfect-layers calculation quite inaccurate. But if you're just shovelling cards into the boxes and not stacking them, though, there will be even more empty space between cards, and the thicker ends won't matter much.
To use a few words you may have to hit Wikipedia about - I know I did - a random close pack of monodisperse microSD-shaped objects will be considerably tighter than one for, say, spheres. I wouldn't be surprised if it only reduced the theoretical no-air-space density by 20%, provided you shake the boxes while you're filling them.
So let's stick with a 20% density reduction from random packing, giving 0.8 times the theoretical density of perfectly-packed cards. Or nineteen million, three hundred and ninety-three thousand, nine hundred and thirty-nine cards, in the boxes, in the station wagon."
He was writing in 2015, and settled on 16GB cards and being reasonable, getting 275 pebibytes. If we switched them to the 1TB cards mentioned upthread that'd be 17 exabytes in a 2 cubic meter stationwagon cargo area, or in a 67 cubic meter shipping container you'd get 575 exibytes. And that's the "load with a shovel and shack to pack down" number, so perhaps 720EiB if someone took that forever to carefully pack them.
Your 100 tons problem is real, it seems shipping containers (both 20 and 40 foot) seem to top out with a cargo payload of 28 tons. So let's call it "only" 161EiB shovel loads.
The font of all hallucinations and incompetent math tells me "The total amount of data on the internet is estimated to be around 40 zettabytes as of 2025, which is equivalent to 40,000 exabytes." So you'd only need 250 shipping containers or so to store a copy of the entire internet. And that's barely 1% of the capacity of a modern large cargo ship. I guess for reliability you'd use 500 shipping containers in redundant mirrored RAID1 config, each half travelling on a different ship.
Dan also noted: "Unfortunately, even if your cards and card readers could all manage 50 mebibytes per second of read and write speed, getting all of that data onto and off of the cards at each end of the wagon-trip in no more than 24 hours would require around 68,400 parallel copy operations, at each end."
That works out to 2.3 million readers for one parallel copy of one containers worth of data in one day. And 570 million for 250 container's worth.
https://web.archive.org/web/20250313181659/http://dansdata.c...
anyways, in took 2-3 months for it to arrive (and most of that time it was waiting in either port), but by my calculation, I have needed to transfer it at a consistent 80MB/s or so (close to gigabit) to be able to net the equivalent transfer rate.
Not old enough to have this kind of knowledge or confidence. I wonder if instead one day I'll be helping some future generation read old floppies, CDs, and IDE/ATA disks *slaps top of AT tower*.
Because you will need several hundred gigabytes of RAM and a very fast IO bus.
The gold standard today for archiving magnetic media is to make a flux image.
The media is treated as if it were an analog recording and sampled at such a high rate that the smallest details are captured. Interpretation is done later, in software. The only antique electronics involved are often the tape or drive head, directly connected to a high speed digitizer.
And indeed that appears to be the plan Al Kossow has for the tape: https://www.tuhs.org/pipermail/tuhs/2025-November/032765.htm...
As for CDs, I don't see the rush; the ones that were properly made will likely outlast human civilization.
Printed ones will last a lot more, but writable ones will degrade to unreadable state in a few years. I lost countless of them years ago, including the double backup of a project I worked on. Branded disks written and verified, properly stored, no sunlight, no objects or anything above them, no moisture or whatever. All gone just because of time. As I read other horror stories like mine, I just stopped using them altogether and never looked back.
recordable CD-Rs or DVD-Rs do not last close to that long, and those are the ones that hold the only copies of certain bits (original versions of software, etc) that people are most interested in not losing.
manufactured CDs and DVDs hold commericial music and films that are for the most part not rare at all.
After 10 years, which was longer than the assumed shelf life of writable/rewritable DVDs at the time, I never found a single corrupt file on the disks. They were stored in ideal conditions though, in a case, in a closed climate controlled shelf, and rarely if ever removed or used.
Also, just because I think it's funny, the archive was over 4000 DVDs. (We had a redundant copies of the data compressed and uncompressed, I think it was like 3000 uncompressed 1k compressed) there was also an offsite redundant copy we put on portable IDE (and eventually SATA) drives.
My team used to maintain go-kits for continuity of operations for a government org. We ran into a few scenarios where the dye on optical media would just go, and another where replacement foam for the pelican cases off gassed and reacted with the media!
OTOH, some 12 years ago I worked IT at a newspaper and we were moving offices. The archivist got an intern in a room in our section of the building and together they spent a month or two scanning, then committing whatever physical media to burned CDs (maybe DVDs) before chucking the former to the bin. Maybe a year after the move, a ticket was opened and I went to check the disks. None of them worked, CRC failures all over. I don't think they even considered testing them, or burning duplicates, or maybe they used a really bad drive which would produce media unreadable by anything else - although I'm only aware that this is a thing with floppies for example.
My oldest disc is some bright blue Verbatim disk my childhood friend made for me so I could play our favorite game at home pre-2000. I have a bit-perfect copy, but the actual disc still reads fine in 2025 when I last tested it.
I recently got to talk to a big-ish name in the Boston music scene, who republished one of his band's original 1985 demos after cleaning the signal up with AI. He told me that he found that tape in a bedroom drawer.
https://github.com/amakukha/tmg
https://news.ycombinator.com/item?id=26722097
""Douglas McIlroy ported TMG to an early version of Unix. According to Ken Thompson, McIlroy wrote TMG in TMG on a piece of paper and "decided to give his piece of paper his piece of paper," hand-compiling assembly language that he entered and assembled on Thompson's Unix system running on PDP-7."
We are not worthy, friends. We are not worthy."
Tons of info, but not much source:
"The first B compiler was written by Ken Thompson in the TMG language around 1969. Thompson initially used the TMG compiler to create a version of B for the PDP-7 minicomputer, which generated threaded code. The B compiler was later rewritten in BCPL and cross-compiled on a GE 635 mainframe to produce object code, which was then re-written in B itself to create a self-hosting compiler. "
So... a B compiler would use GE 635/Multics as a OS.
https://retrocomputingforum.com/t/b-a-simple-interpreter-com...
(I didn't like the guy either, by the way, or at least I knew enough about him that I knew I have much better things to do than listen to him. There are more than a few people like that, all of whom I wish find some peace in their hearts, and none of whom I wish to come to any harm.)
Mastodon is packed to the brim with literal psychopaths and people pretending to be psychopaths for imaginary Internet points. It is not an experience I suggest for anyone who is neither of those things.
But I have the freedom to decide what I want to consume.
Very proud to have had this found at my University :-)
That was a full 40 years ago. And yet, 4th Edition is ancient history even to me.
https://news.ycombinator.com/item?id=45846438
I wrote that article, but I no longer post my stories to HN because I am subject to a block and anything of my own I submit is flagged [dead]. I do not know why, and I have written to ask with no reply.
I only write 5-10 articles a week so I don't exactly spam the site at high frequency, and if I don't feel I can add more context or insight to a story, I don't write it -- except at the very slowest times of the year, and I wouldn't post those stories here.
Ah well.
