I yesterday set chatgpt to a coding task. It utterly failed. Its error handling was extensive, but wrong. It didn't know file formats. It couldn't write the code when i told it the format. The structure of the code sucked. The style was worse. I've never had to work so hard for such garbage. I could have knocked it out from scratch faster with higher quality.
PWB Unix was the earliest sources I could find. FreeBSD lists history items for releases going back to the earliest unix release because BSD Unix is derived from AT&T Research Unix and FreeBSD is derived from 4.4BSD...
The tabs file does predate this, and I'll make a note of that (which is what this article is about).
You forgot the following steps:
Profile to see what's the slowest thing
Make a native version of that.
In FreeBSD package builder setup, we also have /bin/sh and a few other heavily used binaries that are native because it shaves hours or days off a package run (itself takes 10 days, even optimized like this).
I know the qemu-bsd-user fork has some hacks for the bsd-user stuff that looks at the binary to be exec'd and does different things based on the target since there's some optimizations you can get out of this if you don't rely on the kernel 100%... Bits of them may even be in my latest patch-set :)
FreeBSD has used this same trick for half a dozen years or so to build arm, mips and riscv binaries using fast Intel servers. The FreeBSD build system can build itself to produce binaries for the target (so the compilers run natively) and qemu handles the rest with user-mode emulation via bsd-user (which I happen to be in the process of upstreaming).
It absolutely shared history with Larry Wall's patch.... It took the 2.0 sources and started improving them. I ran across a blurb about this somewhere. Also, the code structure is clearly derivative: variable names, function names, wording of messages.
The question too is whether UNIX is copyrighted due to the pre-berne convention distribution of the system w/o copyright notices... And there's also a question of latches as well should this ever be litigated (I suspect it won't, but I never anticipated the SCO suit, so there you go).
Binary format changes are never fun to go through forwards... This blog entry explains how the 2.11BSD restoration project did it backwards as a step towards creating the boot tapes for the original system...
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'
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.
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...
Nobody!
There were no copyright notices, and this is a work made before the US adopted the BERN convention. Prior copyright law required copyright notices.
We learned from the ATT vs Regents case that a judge ruled there was a large likelihood that AT&T couldn't establish it had a valid copyright on V32 because they never marked it properly.