52-year-old data tape could contain only known copy of UNIX V4 A tape-based piece of unique Unix history may have been lying quietly in storage at the University of Utah for 50+ years. The question is whether researchers will be able to take this piece of middle-aged media and rewind it back to the 1970s to get the data off. The news was posted to Mastodon by Professor Robert Ricci of the …
When I saw the text "The software librarian at the CHM is the redoubtable Al Kossow of Bitsavers" I swore and said what the "heck" does AI have to do with this.. last thing we need is AI screwing up this important piece of history.
After reparsing that text several times I realized that:
- it referred to a bloke called Al as in Alfred or Albert or Alister
- that I have AIDS (A.I. Derangement Syndrome)
Bluck
I feel your pain, both in that I find both AI and sans-serif fonts to be deranging. I had occasion a few months back to note that fonts where you can't tell the digit 1, an uppercase i, or a lowercase L apart should never happen. (Unless it's a 4x6 bitmapped font.)
Haven't run into that, thankfully, but yeah, that'd be annoying. In my own (incomplete) attempt at a password manager, I provided a 'human readable' option in which you could specify that a password could not have an uppercase i or o or lowercase L. (Actually, I should have left out the zero and one as well.)
In the worst case scenario, where you're limited to letters and numbers, those five omissions result in 57 possibilities per character instead of 62, or 5.83 bits of entropy per character instead of 5.95. If 'specials' are allowed, the loss per character is even less.
I've tried several of them, but none have free versions with all of 2fa, ldap, and syslog. I'll copy them into an editor with serif fonts in the cases where I actually have to type them because some incompetent web developer somewhere (T-Mobile's US payments provider for one) decided that you can paste in fields, but must actually type them for verification.
You edit the Source Code for the password manager to specify a font where the upper case I, lower case L and digit 1 are visually distinguible, recompile it and carry on.
(If you didn't have the Source Code for your password manager, you wouldn't be able to be sure it wasn't doing nasty things like sending plaintext copies of your passwords somewhere.)
Nice catch. You're right, it's entirely possible to make distinct number 1/lowercase L, and distinct number zero/uppercase o, in a 4x6 font. (And my vague recollection is that most fonts of that era were at least 5x7 anyway.)
Fascinating, as I've also been doing computer archeology in the last few weeks, tracking down and recovering Wren Executive system disks. Anybody remember that? Only 1000 or so were manufactured, so I was well pleased to find the disks, and doublepluspleased to find the data was recoverable.
Yep I remember the Wren; if the disks have been well-stored they should be fine. They dislike damp, and mould, as do we all.
My 1981 vintage 87.5K flippy 5.25s still work, in the chuggy 40ms-step 35T SA400 I bought second hand for my Video Genie, or via Paula or Greaseweasel. My slightly newer microdrive cartridges have defelted but the 40 year old data’s still there.
Beers for the finder, for recognising the value of what they found and for the retrieval team for the journey they are embarking on. In some cases, literally.
Note: joke alert for the title. Though, there might be a masochist out there, once the v4 source is published, who'll port it to Rust
This post has been deleted by its author
"they wouldn't recognise a magnetic tape if one fell on their head..."
I recall the ½" open reel tapes on a Pyramid 90x mini weren't lightweight by any stretch.
One of those falling on an unsuspecting youngster's would give them more than a gormless gen-z stare; more like serious concussion.
DLT and LTO cartridges might wake the blighters up but they wouldn't notice a torrent of DDS tapes bouncing off their noggins.
On the second part of my first job the Fairchild Sentry IC testers I maintained used 1/2" 9 channel mag tape to load the test programs onto a ~3 foot diameter hard disk, capacity unknown, that used a pneumatic actuator to lift the heads in case of emergency. I always wondered what would happen if one of the disks "got loose". So I've repaired more than a few tape drives in my time. Three of the four testers also used magnetic memory. Luckily for me my digital electronics courses (graduated from Jr. College with an Associates Degree in 1978) actually included magnetic memories which I also had to repair on more than one occasion. Now, get off my lawn!
those young enough that they wouldn't recognise a magnetic tape
For many in earlier generations magnetic tape was the only item of computer equipment they could recognise. Apart from blinkenlights, every film portraying a computer showed lots of the vertical tape units. With their vacuum tensioning system and the captivating stuttering motion they were the only photogenic bits of a computer.
> Though, there might be a masochist out there, once the v4 source is published, who'll port it to Rust
You jest -- I hope -- but there's something like haf a dozen of them...
4Y ago:
https://github.com/Ko-oK-OS/xv6-rust
2Y ago:
https://github.com/o8vm/octox
1Y ago:
https://github.com/LENSHOOD/xv6-rust
https://github.com/boranseckin/octopos
Just imagine... if they all cooperated, they might actually _get_ somewhere...
I think I'd enjoy the resultant video that Dave Lovett at Usagi Electric would produce if he had copies. He's got contacts with some good people and between them have done some amazing digital archaeology on old systems, some of which pre-date PDP-11s (like the Bendix G15).
Much as I enjoy Dave Plummer's videos and appreciate the insight into parts of MS history, I find them a little self aggrandizing sometimes. Hey, he wrote Task Manager! Great!
But he did manage to drag an interview out of Dave Cutler. That was worth it, if only for the RSX11 and VMS history.
Looking in my notes, V4 was a major review where lots of seperate exceptions were all gathered together into the general purpose signal() call, and group IDs were introduced. My notes also say: tell() - removed, never worked, and it took a long time for a working tell() call to appear, even seek() failed to return the correct offset for a long time, programs had to use their own file offset veneer if they wanted to read an open file's offset.
I was wondering whether 4th Ed Unix ran on a PDP-7 or on a PDP-11.
According to https://gunkies.org/wiki/UNIX_Fourth_Edition it *only* ran the PDP-11/45 model.
Probably more working 11/45s out there than microvaxes but in any case there are some fairly decent emulators.
Running 7th Ed Unix in an emulator some years ago was an interesting exercise — the absence of networking was the most noticeable difference from say Busybox + Linux kernel.
If you used Edition 7 for a little longer, you would notice things like "ls" only showed the owner, not the group (you had to use the -g flag to see the group in place of the owner), and if it were a real vanilla Edition 7 system, you would not have "vi", only "ed", no "more", "pg" or "less", and the shell would be the original Bourne shell. There was also no X11 (or even X10), the only graphics you got were either Tektronix 4010, 4014 or 4015 vector storage 'scopes or possibly GT40. You would also not recognise "init", which was just soooo simple.
At least the tty driver understood <XON>/<XOFF> flow control, unlike Edition 6 which was a real pain to use without any way of pausing file output, and which also meant that you ran the terminals at low speed (2400 or 4800 baud) to prevent dropped characters.
If the system that was under emulation was an 11/70, and it was loaded with the contents of a BSD tape, you might just have csh, vi and more, but these were add-ons written at Berkeley.
Oh, and unless you had the addendum tape, after a crash, you would be using icheck, dcheck and ncheck. fsck was an after thought, shipped on the aforementioned addendum tape, along with a more functional printer spooler.
One interesting fact. IIRC, ditroff (device independent troff) was introduced with UNIX Edition 7. The original troff, a development of nroff and roff was the photo-typesetter document preparation tool that was one of the very reasons for UNIX even existing (Dennis Richie and Ken Thompson justified the cost of the first PDP that they were given to produce a document preparation system for Bell Lab's patent department, and they piggybacked the rest of early UNIX development around this).
Ditroff was a development that allowed output devices other than a Graphic Systems CAT phototypesetter to be used for high quality print documents.
The interesting thing (at least as far as Tek storage terminals are concerned) is that there was a tek4014 (I think it was 4014, not the 4015 - although that provided a superset) device backend for ditroff that would draw a preview of the page on the storage scope. It was too small to read, of course, but it gave you an idea of how the document would look before printing it, and even worked with tbl, pic, eqn and grap preprocessors. As terminals became more sophisticated, they often included a Tektronix emulation, and you could use this to preview on your terminal if you had one of these multi-personality terminal (I liked the little known Falco 5220E, which I had on my desk).
There were other backends for troff, including one for the BLITs (I also had a 630 next to my desk - I was the terminal SME at this part of AT&T for a number of years). These were not WYSIWYG, but they were useful preview tools to see how a document would look. And of course, it became easy to put a Postscript backend in place when Postscript printers became more common.
Right up until SVR2, the dates for DST start and end were hard-coded into the C library (I can't remember the routine name, can't be arsed to look it up). Once a year, we would change it, recompile the .o file, replace it in the library, and schedule a system reboot.
It was a real relief when this was abstracted out to the TZ variable.
You know. I've just re-read the above, and I've concluded that it made no sense.
SVR2 binaries were statically linked (dynamic linking was being played around with internal releases of SVR3, and did not become mainstream until SVR4)! So changing the library would only make a difference for newly linked binaries.
The mists of time have dimmed my memory. I remember doing something, but I'm wondering whether it was a kernel routine, not the C library, and we ended up re-linking the kernel (internal AT&T shop, so we did sysgen kernels). I still have some crumbling paper documentation for this but it may be for R&D UNIX 5.2.6, not the earlier release.
The heroics that went into creating Unix can't be over-emphasized.
Look no further than the Unix Programmer's Manual V4 from 1973: almost 300 pages, written using "ed", formatted using "troff".
Ye gods! Do you have any idea how painful that must have been? I briefly used both when I was a lad. I still bear the scars.
Having used nroff, troff, runoff and later latex quite extensively in my early career, it really was not as bad as it would seem.
Separating the text entry away from the formatting meant that you could get the text right while not worrying too much about the exact formatting, and it is only when you are ready that you see what it looks like that you worry. And this was really helped by the simple pre-processors that would allow you to enter the text using a delimited text format with the necessary table header code in tbl, eqn, pic and grap (this was an AT&T internal simple diagramming preprocessor) for example. Having styles handled by the macro sets was also extremely helpful, in the same way that using templates is in later tools.
Because the actual section and paragraph formatting was handled by *roff, you did not really worry if the text in the raw file looked untidy. Often, if you were editing an already written paragraph, you would end up with both very long and very short lines as you hacked the text, sometimes down to one sentence a line, and allow the formatter to sort it out.
I remember back when WYSIWYG preparation tools were just being introduced seeing several academics article that analysed document preparation between groups of subjects using separate text editor and formatting tools, and a WYSIWYG tool, and they concluded that WYSIWYG took longer, and resulted in less readable documents than preparation with a basic text editor and a separate formatter.
I know that I struggled (and still do, quite often) when using Word or Libre Office to get the document looking right while I am writing it, to the detriment of the legibility of the document.
Back when ed was the only editor around, you actually got pretty proficient with your substitution commands. Ed is actually very capable once you know how to use it, but the initial learning curve was a real pain! But even though vi is also not very intuitive (compared to things like DEC's EDT and later editors), it was a leap forward when it came along, even if I still do ed style global substitutions inside of it. And knowing ed really helps when using sed.
Will they be baking the tape in order to recover the contents?
This was done successfully when Strand Games found an archive tape containing source code for most of Magnetic Scrolls' games.
The link to this fascinating story is here : https://strandgames.com/blog/magnetic-scrolls-games-source-code-recovered
I'm sure they will be very cautious with this kind of data recovery, as they will have only one chance to get it right.
It's fascinating, and sad, and exciting to hear about the digital and analog archeology being conducted at the moment.
Sad because of what we have already lost. But it's fantastic to hear of the preservation work being conducted by various groups. These old systems deserved to be preserved as icons and relics of our digital past. Hardware and software both.
In the analog world, the groups such as "Film is Fabulous", recovering and preserving media. Some of it thought to be lost. (I've given them a donation of my ill gotten gains to help the work).
Work being done now might be our last chance of recovering anything at any scale. Especially as the independent archivists die off. Many estates, not knowing what they have, simply send stuff to the tip. We also are losing the hardware to recover the media.
Very good podcasts out there which discuss the topics. They seem to be much more informative and thoughtful than anything on YouTube (exceptions apply).
A cold one to the people doing the good work. -->
>” Many estates, not knowing what they have, simply send stuff to the tip”
Back in the 1990s John Huntley (founder of Huntley Film Archives) ran a series of public shows of old transport films, these events serving two,purposes, firstly entertaining audiences with unseen transport films and secondly increasing awareness of the unique archive in people’s attics. Because at the time many people who shot amateur film (particularly 8mm) were coming to end of life and whilst their films might not be fit for cinema they often contained material of historical interest (eg. today your grandparents film of the Uxbridge road full of horse drawn carts is of interest).
Perhaps we need to do something similar with computing to make some of this stuff come to life and entertain and increase peoples awareness.
(eg. today your grandparents film of the Uxbridge road full of horse drawn carts is of interest)
Was that before or after George F. Train was arrested for "breaking and injuring the Uxbridge Road" in 1861 by laying horse tram tracks which protruded above the surface of the road, so people kept tripping on them and carts kept crashing etc?
As Devuan was set up primarily as a response to systemd, I presume that is what you are eluding to.
The init system is, and has been a problem for decades. One that could be worked around, but a problem none the less. Systemd is a solution. Not everyone thinks that systemd is the solution. (You can probably say the same for Wayland/Weston vs. Xorg).
I think that the initial idea behind systemd had merit. I didn't like it's early implementation, mainly because the documentation was so poor, and there was little initial emphasis on making it suitable for anything other that Lennart's laptop, certainly not for enterprise use.
If it had become just a usable init system (and just that) as it matured, I think there would be more acceptance. But instead of stabilising it and making it fit for purpose, it has suffered almost unlimited feature creep. This is mostly what the Devuan developers railed against. And before you say that systemd is modular, and you don't have to use all of the parts available, in reality, because of built-in dependencies, you do without significant work stubbing the bits of systemd in the latest tools for bits that are missing if systemd is not present.
We now have a near monoculture when it comes to the init system shipped with the main Linux distro's, as most are in some way or other downstream of either RH or Debian. The remaining distro's that are assembled from the basic components are numerous, but have not reached much penetration. Monocultures have in the past been very foreign to the Linux ecosystem.
The Devuan developers just want to keep the option of choice.
I am still struggling with why my Ubuntu laptop sometimes sits for minutes at a time after the GUI has gone when shutting down. The only thing I can see is that it appears to be waiting for a systemd component to reach some state or other, and going much further in the diagnosis looks like it will take some effort that I don't really want to have to worry about at the moment.
The first Unix in the UK was Bell Labs v4, at Queen Mary College, University of London (now restyled Queen Mary University of London, QMUL).
The late George Coulouris, who became Head of Computer Science, relates the story here: https://www.coulouris.net/cs_history/em_story/
In case we still have a copy of v4 hidden somewhere at QMUL or amongst the staff or alumni, I'm reaching out to former lecturers and colleagues. I'll report back if there's any success.
Incidentally, George's obituary (he died in January 2025), written by his colleague Richard Bornat, is here: https://www.theguardian.com/education/2025/jan/19/george-coulouris-obituary
Queen Mary College was responsible for the extensions to ed that became em, "Editor for Mortals". I believe that a copy made it across the pond where it had some influence with people there.
I used it for much of my time at Durham University in the late 70's and early 80's while I was a student there. The only problem with it was that "E" is next to "R" on a standard keyboard, and on more than one occasion, I deleted the file I was working on!
Canonically, that's "Never underestimate the bandwidth capability of a station wagon full of mag tape."
The quote is often attributed to Tanenbaum in 1996, but it was a common expression when I was at DEC long before that ... and I remember a similar comment from a student at Stanford in the early '80s when a professor expressed surprise at one of the vaxen already running the latest BSD build, released just a few hours before. Conversation went "How on earth did you get that code across the network that fast?" answer was "My motorcycle's latency might be sub-par, but it still has a much higher bandwidth capability than your network!".
It used to be a nice trick when asked about my "experience" to highlight my name in the Sperry UNIVAC MASM version of KERMIT held at Columbia dating back to 1986. Which given I have been asked that question by people born in 1990 should say something.
It helps that my name is very very rare (and my sons is unique on the planet). Yes *that* ----n L------- :)!
AL K is the #1 fellow and group doing digitizing now days.
Have to mention Chuck Guzis who was a goto source for such recoveries if AL couldn't do the job. He recently passed away, and I'm not sure there is anyone out there now who does the job in such a fashion. He also did any magnetic media he had hardware for.
Glad this has been found, and look forward to seeing what is recovered.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
