
In search of 2.11BSD, as originally released - fanf2
https://bsdimp.blogspot.com/2020/07/211bsd-original-tapes-recreation.html
======
breput
2.11BSD is still getting patches[1] - mostly due to renewed interest from the
PiDP-11 project[2]. Recent changes[3] include the addition of the 'top'
utility.

Reverting to patch level zero is an interesting exercise but there are still
plenty of people who are interested in maintaining and updating the operating
system.

Edit: And I understand the pain - the "patches" are a eclectic mix of straight
diff output, shell archives, uuencoded compressed tar files, and all sorts of
manual steps. But the patch "readme" information is unusually verbose and the
update instructions are well written and informative.

[1]
[https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patch...](https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/)

[2]
[https://obsolescence.wixsite.com/obsolescence/pidp-11](https://obsolescence.wixsite.com/obsolescence/pidp-11)

[3] [https://github.com/chasecovello/211bsd-
pidp11](https://github.com/chasecovello/211bsd-pidp11)

~~~
microcolonel
Turn 'em into git commits.

I've done this with a lot of things which only have changelogs and tarballs,
it is convenient.

~~~
breput
To do that, you'd really need the entire 2.11BSD distribution in source
control. So the real problem would be that you'd need to start
with...patch...level...zero. :whoa:

Seriously, that would be a beautiful thing from a historic standpoint. But
there is no git client for 2.11BSD, so you'd also end up having to build a
git->something (probably shell archive and b64 compressed tar) that could
allow the 2.11BSD system to update itself (and we're talking a 16/22 bit
system here). There are also changes that require kernel recompiles and/or
reboots so it turns out to be an extremely difficult problem. Which is why
there are these human readable patches.

~~~
progman32
> To do that, you'd really need the entire 2.11BSD distribution in source
> control. So the real problem would be that you'd need to start
> with...patch...level...zero. :whoa:

I might be misunderstanding, but I don't think this is true. As long as
there's a complete snapshot to start from anywhere in the revision history,
it's possible to apply each patch in reverse (as far back as possible), even
if it doesn't get all the way to patch level 0. Then later, if earlier patches
are found, these can be applied in reverse and the branch rebased.

~~~
breput
The confusion might be around the term "patch". These can be _sometimes_ be
simple diff patches. Or they can be multi-step processes, including reboots,
all wrapped up into a single "patch".

For example:
[https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patch...](https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/467)

I recently updated from patch level 462 to 469 (the most recently patch
available) and even with excellent documentation, it was an involved process.
If you look all the way back to the first set of patches
([https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patch...](https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/001-009.tar.bz2))
there isn't even documentation for the most part. Some diffs, some random tar
files, and some "Remove everything above the #! /bin/sh line." patches.

~~~
progman32
Ah. I understand the difficulty now, thanks. Some patches might not even apply
in reverse!

~~~
bsdimp
It's hard to reverse apply 'rm /usr/src/bin/ld.c' in the instructions to patch
160, for example. You have to reconstruct ld.c from 2.10.1BSD, and then add
missing changes to get it to work...

~~~
qubex
Exactly: deletions is what came to my mind instantly and if you hadn’t raised
the issue then I would have.

------
irl_zebra
I love these great, though utterly useless, projects people do for the love of
things and for no other reason than it’s something interesting to them. I will
be following along.

~~~
bsdimp
It's my COVID-19 insomnia project...

~~~
TedDoesntTalk
What year/month was this version released? It’s not in the article.

~~~
jmartinpetersen
March 1991, it seems.

[https://www.krsaborio.net/bsd/research/1991/0314.htm](https://www.krsaborio.net/bsd/research/1991/0314.htm)

------
progman32
Reminds me of this recent video on recovering Luminary 69, Apollo 10's lunar
module code (the only known copy of which is somewhere in solar orbit) by
careful reconstruction of the development process:
[https://www.youtube.com/watch?v=-JTa1RQxU04](https://www.youtube.com/watch?v=-JTa1RQxU04)

This exploitation of side-channels is something to pay attention to. Data is
rarely fully lost!

~~~
taejo
In that case someone found a listing of the checksums of the code that
launched in the archives (!), that could be used to verify the reconstruction.
I wonder if there's anything like that for 2.11BSD

------
ChuckMcM
For some reason I thought this was on the PUPS disc?

~~~
bsdimp
No. 2.11BSDpl195 is the earliest one available. It's what was on the old PUPS
disk... PUPS became TUHS ([http://www.tuhs.org](http://www.tuhs.org)) and this
is the oldest one there and none of the old timers that ran 2BSD in PDP11 have
the original tapes.

------
chungy
This reminds me of a thing in the Doom community to restore a "lost" release
of DOSDOOM: [https://github.com/Doom-Utils/historic-
ports/commit/ce8bbd69...](https://github.com/Doom-Utils/historic-
ports/commit/ce8bbd699f29452edf7d02b912b49146a80144ed)

------
DNied
It could be an interesting website, but I really don't feel like scrolling
horizontally all the time to read the text.

~~~
fireattack
>scrolling horizontally

What do you mean? The text renders fine here on both desktop and mobile (no
need to scroll horizontally).

~~~
raldi
What if you make your browser window narrower?

~~~
DNied
Or zoom in a little...

