From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27903 invoked from network); 4 Aug 2020 17:09:15 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 4 Aug 2020 17:09:15 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id DF0939CA8B; Wed, 5 Aug 2020 03:09:11 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 872109CA7F; Wed, 5 Aug 2020 03:08:28 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=bsdimp-com.20150623.gappssmtp.com header.i=@bsdimp-com.20150623.gappssmtp.com header.b="jc9B5FjA"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id A75F19CA7F; Wed, 5 Aug 2020 03:08:24 +1000 (AEST) Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) by minnie.tuhs.org (Postfix) with ESMTPS id AF24F9CA7E for ; Wed, 5 Aug 2020 03:08:23 +1000 (AEST) Received: by mail-qv1-f51.google.com with SMTP id s15so14946081qvv.7 for ; Tue, 04 Aug 2020 10:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=SIiuPj2FPfBtzBqaMM+2CnJuw1teSzxTLWWd6LvYNPc=; b=jc9B5FjAmvVpjArpBhsipXLDSDWSmlKWFr6z1GY1zmGLGbWUdXTRJzjJPMD4MnEmTx PGVjUH+WZZ7w1uYVDBYKZ+U11YPRsiMffRJ8bcom0k8qH5+a403HD0dLM+YnyOLVzXI5 d+KZ9Tf4UFMKplYaIPNIaQC1fJiRlYSx5SVpzWoajE+SFIxK7cU9bUiZ5hkiSeO/D/2D 2TALXBCWzmpmOqWMaY8Es3M6LCKpINs3RtOOzPCN70ZBso/8dAluVdSOO8cm8pDtgBpa o84chRlpjk+L/u9AoGmSDjrjt76MTY+cLG2PYogrqBX37BnWyloIg5zhfH7A7Jy4wdbi nDIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SIiuPj2FPfBtzBqaMM+2CnJuw1teSzxTLWWd6LvYNPc=; b=Bvd5P605R1IbzrylUxXKi016MKVJ/al0iBR+UQJqbyN8l8ajK3xN6Pm6QBn5fjVQ+9 739UPwmRta6LqXqRFvUDPJ4NWCv1Oc6Kz6cHAfPYWJfitPbO4ANIb4t5AFOE6BkGQj+O X8k9NFH96IDGeYkQ957nAMcyaAPGKQ40J6C0gH2cUZM1eSWorFna6CMAx9l6X/4TpMka 5FamgVF2SaVe8iGYOvnkeUGLVT+u2n8PUKjvkAw7AjLXL9dXUMv2Qdcbs5qBCTGS/yd2 /2cBpKV7ib9NGfK6hr4iyClJoTY6IdvBDowNxMHgvHb3LIV/CrLrt4EB0p8BMns2FCqG S59A== X-Gm-Message-State: AOAM530qR/ukSGRsLn7vATO1nRwjKC24FtwGJi+9lsvW/cGafds2Orkr UYyPA+4aeTjL+0mc2jupKN4CdZ+PwZtm8FKTv4KTVBtmJvs= X-Google-Smtp-Source: ABdhPJz/Uuk7WlvKJEVek+KodksbR5IJbXMJmvpf7ReV0VUPJpkQ5DYDHE/BLjzvkVbHcFf8KWuhpMEIKk3Vy4HW/LE= X-Received: by 2002:a0c:b599:: with SMTP id g25mr23516752qve.118.1596560902106; Tue, 04 Aug 2020 10:08:22 -0700 (PDT) MIME-Version: 1.0 From: Warner Losh Date: Tue, 4 Aug 2020 11:08:08 -0600 Message-ID: To: TUHS main list Content-Type: multipart/alternative; boundary="0000000000006ecaf305ac104d0c" Subject: [TUHS] 2.11BSD Status Update X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000006ecaf305ac104d0c Content-Type: text/plain; charset="UTF-8" OK. I'm plowing through a lot of issues with the putative 2.11BSD reconstructions I've done to date. I keep finding things dated too new to be right. And it turns out that a few patches "snuck in" when the patch 80 catch up was done. I've outlined the ones I've found so far at https://bsdimp.blogspot.com/2020/08/missing-211bsd-patches.html but I'm sure there's at least one more. There was much ambiguity over /usr/new and /usr/local that lead to some of these, but others look like they were in the master tree, but never formally published that have all the hallmarks of legit bug fixes... I've also detailed the issues in going backwards. 2.11BSDpl195 had a different .o format than 2.11BSDpl0. And to make matters worse, its assembler couldn't assemble the assembler from the initial release, so I had to get creative (using apout, thanks to all who contributed to that!). I've also blogged about how to walk back a binary change when the old programs no longer build on the new system. I think I got lucky that it was possible at all :). https://bsdimp.blogspot.com/2020/08/bootstrapping-211bsd-no-patches-from.html has the blow by blow. There are a lot of steps to building even a normal system... Let alone walking through the minefield of errors that you need to do when stepping back... And neither of these even begin to get into the issues with the build system itself requiring workarounds for that... But anyway, I keep making "ur2.11BSD" tapes, installing them and fixing the issues I find... While much information was destroyed in the process, there's a surprising amount of redundancy that one can use to 'test' putative tapes. Warner P.S. ur2.11BSD is from urFOO in linguisting, meaning the original FOO that's been lost and which some amount of reconstruction / speculation is offered about it. Still looking for a good name for the reconstructed 2.11BSD release.... --0000000000006ecaf305ac104d0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK. I'm plowing through a lot of issues with the putat= ive 2.11BSD reconstructions I've done to date. I keep finding things da= ted too new to be right.

And it turns out that a few pat= ches "snuck in" when the patch 80 catch up was done. I've out= lined the ones I've found so far at=C2=A0https://bsdimp.blogspot.com/2= 020/08/missing-211bsd-patches.html but I'm sure there's at leas= t one more. There was much ambiguity over /usr/new and /usr/local that lead= to some of these, but others look like they were in the master tree, but n= ever formally published that have all the hallmarks of legit bug fixes...

I've also detailed the issues=C2=A0 in going ba= ckwards. 2.11BSDpl195 had a different=C2=A0.o format than 2.11BSDpl0. And t= o make matters worse, its assembler couldn't assemble the assembler fro= m the initial release, so I had to get creative (using apout, thanks to all= who contributed to that!). I've also blogged about how to walk back a = binary change when the old programs no longer build on the new system. I th= ink I got lucky that it was possible at all :).=C2=A0https:/= /bsdimp.blogspot.com/2020/08/bootstrapping-211bsd-no-patches-from.html = has the blow by blow. There are a lot of steps to building even a normal sy= stem... Let alone walking through the minefield of errors that you need to = do when stepping back...

And neither of these even= begin to get into the issues with the build system itself requiring workar= ounds for that...

But anyway, I keep making "= ur2.11BSD" tapes, installing them and fixing the issues I find... Whil= e much information was destroyed in the process, there's a surprising a= mount of redundancy that one can use to 'test' putative tapes.

Warner

P.S. ur2.11BSD is from= urFOO in linguisting, meaning the original FOO that's been lost and wh= ich some amount of reconstruction / speculation is offered about it. Still = looking for a good name for the reconstructed 2.11BSD release....
--0000000000006ecaf305ac104d0c--