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

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

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

I’d lay a bet I know of some 2.11BSD boxes still running critical production code at a former employer.

Turn 'em into git commits.

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

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.

The whole reason I did this project was to get back to patch level 0 so I could create a github repo of all the 2.11BSD patches....

It is a tremendous project and I salute your efforts and hopefully you can find some volunteers with this post!

You might also want to mention it on the PiDP-11 Google Group (https://groups.google.com/forum/#!forum/pidp-11) where there are some original patchers and lots of other interested people.

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

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

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

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

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

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

You can do this but rebasing plays havoc on a lot of git integrations. Every time you insert a commit into an earlier spot, it changes the hash of every commit after it which has the potential to cause all kinds of problems for systems assuming git hashes are permanent.

For sure, this is very bad practice when using git for forward development. When working in reverse, a lot of things go out the window :)

The way I see it, git's main role here would simply be a way to standardize patch format, not its usual role as a distributed software development aid.

Git's role would be to record the system incrementally as each patch is applied. I've already worked all the way back to the unpatched system. I assume that if I got it right, then I'll be able to rebuild. I've mostly been able to, and I'm investigating the mostly. Plus, I'm making sure that it's 100% reproducible so anybody can down the TUHS artifacts, run my scripts and have release 0 tapes, and a git repo of all the changes. And historians will be able to see what's definitely original, and my reconstructions of missing changes to programs. Those we'll never know to a higher degree of 'consistent with everything else'

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.

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

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

March 1991, it seems.

https://www.krsaborio.net/bsd/research/1991/0314.htm

History is not useless

+1

It is great encouragement that time investment is never lost if it is something you love and enjoy, even when no one else has benefit of it.

I always find weird to read this kind of comment in a forum with "hacker" in the title.

Yes this!! Its normal to read comments like that in linkedIn but not on HN...same as why use 9front/*BSD/Haiku/Inferno? Just take a normal Linux Distribution.

It's surprising how often "utterly useless" project turn into huge companies. I for one will keep pursuing them :D

Far from useless. Often educational.

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

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

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

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

No. 2.11BSDpl195 is the earliest one available. It's what was on the old PUPS disk... PUPS became TUHS (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.

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

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

>scrolling horizontally

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

What if you make your browser window narrower?

Or zoom in a little...