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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25066 invoked from network); 8 Sep 2022 17:59:57 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 8 Sep 2022 17:59:57 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 9CE874226A; Fri, 9 Sep 2022 03:59:35 +1000 (AEST) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by minnie.tuhs.org (Postfix) with ESMTPS id 8265342268 for ; Fri, 9 Sep 2022 03:59:29 +1000 (AEST) Received: by mail-lj1-f170.google.com with SMTP id by6so20840865ljb.11 for ; Thu, 08 Sep 2022 10:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=T5dPWCQkaQh8IG3SXgRNOVKUsfD7OKcqk7zOPSNjsm0=; b=UGCbqsYBEnPLpwwvRC8aS5HnlJqF0E+VNyRlQbEZ6ws8qOQ5Sk/BpBWpq4FOBJIxvF sj3xRwGHA9NmrXSLnEkcjft5r6Zd7J4LOSQn8CaSFkEoYiXAN7crooE73DK7LECOJeNQ XOVKlolln2Yud092h6J0uh51Sfx+mJnm/y5CT9Ohp46EHk/FHc047DhmuviSoKQYAeNv KqaD75RFdiq/ADTLrLccch3M0iiSBjjAmOpLCHQsYbotpiDic0M/Ed56Q23oWeEU7aka Gm4zQ0MDkuVFMGeMJQgSkkSruaEZ+bLrRE8X+J9paYzmkLfdIvI6bKXCgIiLRnHkfvbO 5GOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=T5dPWCQkaQh8IG3SXgRNOVKUsfD7OKcqk7zOPSNjsm0=; b=QFNfa9dnYtmoE9Eg6pUGsyJkPR+AYhQXVBq499cLT2iZdJaaCQKi/XUWWlb2Ucb1ku 06xfMPV9sPYERXHhdkKNQlgtCdbRXl9JOsrvYxRWlDRj1yerVGWQ0Z81RqefF6JYv9tP 6hf2MvGozpmSCtan1JUGAk7y5rKZUZ86d5Kb0VeFesVp5nm6E/bHkuwVHTqywV/Py2Du P9MVPZCYIPk1rq5FJgbZPLBCFjEdwe8tkzJc9kbap9GGevjKKYydx5vUmK3KSIuga0fh //zXFJnBlVPr6D/dfxWiixX+cHwllJkFc/ue1JzFmaFjmopMYDL+8JEwdt3Dqs4nrurZ 5NKg== X-Gm-Message-State: ACgBeo0xVI1gSt6kEZPh6r106f//mXxKz2FU3TTVjj3GJxFPWb6ZA4Ug 78RJ1JVg/YzOjYaMlDGkfTxxrM/R4Oyot5VWLw5hE7R5 X-Google-Smtp-Source: AA6agR7SA2pu6m4hHhxpTZJ2Elerzex0/AbfKqS9ZYXmMbE0zrrNzvd3Zzo2DklNPSKaNybVpmEtvszG0R3gQMa/N7k= X-Received: by 2002:a2e:be25:0:b0:268:9a78:8b9 with SMTP id z37-20020a2ebe25000000b002689a7808b9mr2924846ljq.196.1662659907571; Thu, 08 Sep 2022 10:58:27 -0700 (PDT) MIME-Version: 1.0 References: <20220907145631.GN31856@mcvoy.com> <8DDF5A51-AABF-41AF-993C-4D087903BDC9@canb.auug.org.au> In-Reply-To: From: ron minnich Date: Thu, 8 Sep 2022 10:58:16 -0700 Message-ID: To: segaloco Content-Type: multipart/alternative; boundary="0000000000002c56c505e82e2d9d" Message-ID-Hash: WORZHTCFKVJH4CYJCS7A3NKIX6U3JY7Y X-Message-ID-Hash: WORZHTCFKVJH4CYJCS7A3NKIX6U3JY7Y X-MailFrom: rminnich@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Steve Jenkin , TUHS X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Has this been discussed on-list? How Unix changed Software. List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000002c56c505e82e2d9d Content-Type: text/plain; charset="UTF-8" re hardware, in several cases in the 60s, when old hardware was connected to new hardware to verify the new hardware's floating point, the new hardware had a difference -- and the bug was in the old hardware. Gordon Bell mentioned this in "Computer Engineering", IIRC; I am also told some model of 360 and 370 also found bugs in ... the 360. And let's not forget what in the supercomputing biz was called "Cray Floating Point": e.g. X * Y did not always equal Y * X. But the answer came back fast :-) On Thu, Sep 8, 2022 at 9:50 AM segaloco wrote: > > In addition, when Dennis would talk about Coherent and his evaluation of > the source code, he said he used the known to him, but not widely known > bugs in Unix to try to catch copying. If there was copying, those would be > copied. If it was freshly implemented, there's a high likelihood that they > wouldn't. His conclusion was that someone had access to a lot of knowledge > about the Unix system given the fidelity of the implementation, but the > lack of bugs and novel ways of doing it suggested independent > implementation. > > Both Coherent and 4.4BSD have stuck out to me as examples of > not-quite-so-clean-room implementations that did well enough (more than > enough for BSD) and didn't die a fiery death in litigation (as much as USL > tried...). What I find interesting is that in this day and age, it seems > there is almost a requirement for true "clean-room" implementation if > something is going to be replicated, which I understand to mean the team > developing the new implementation can't be the same team that performed a > detailed analysis of the product being reimplemented, but the latter team > can produce a white paper/writeup/memorandum describing the results of > their analysis and the development team can then use that so long as it > doesn't contain any implementation details. > > I've always wondered how cleanly that sort of thing can actually be proven > and enforced, and I've always thought back to the Coherent situation as an > almost model example. Where proving copying outright can be difficult, > knowing one's own product well enough to know the bugs that are incredibly > obscure but also reliably consistent is a great way to peg a faithful > recreation vs. a flat out copy job. That said, my assumption with complete > UNIX re-implementations is that folks at least had access to the manuals, > perhaps had used UNIX before in some capacity. I would assume the current > definition of a clean-room implementation only requires that the > developers/implementors don't have access to the code of the parent product > (source or reverse engineered), but could read manuals, study behavior > in-situ, and use that level of "reverse engineering" to extract the design > from the implementation, so not knowing the gritty details, Coherent could > be a true clean-room. > > BSD is a different beast, as they were literally replacing the AT&T source > code before their eyes, so there isn't much argument that can be made for > 4.4BSD being a "clean-room" implementation of UNIX. Simply for > compatibility and upgrade-ability of existing systems, they had to be > incredibly accurate to the original design. Given that, that's one of the > more surprising things to me about 4.4BSD prevailing in the lawsuit, > because while Berkeley could easily prove that they had replaced most of > AT&T's code, there's still the fact that their team did have complete and > unfettered access to Bell UNIX code at least circa 32V. Not sure if the > licensing allowed for source-code cross-talk between USG/USL UNIX source > and Berkeley, but I remember reading somewhere that CSRG students and > faculty avoided commercial UNIX like the plague, going so far as to not > even look at the literature to see what changes occurred since 32V. > > Anywho just some thoughts, I find the realm of reverse engineering and > re-implementation fascinating, and am always interested in this sort of > discussion. > > - Matt G. > > P.S. Don't want to derail the thread with this, unless it's deemed worthy > addition, but feel free to email privately. Does anyone know if there was > a "formal" PDP-11 and/or VAX disassembler produced by Bell? I know there > was one floating around the "user maintained" utilities at some point, I > recall seeing a note in a manual saying something to the effect "Rumor has > it there is a PDP-11 disassembler" but I'm curious if such tools were ever > provided in any sort of official capacity. I've been doing some research > on what RE tools people had on hand at the time, think "objdump" from GNU > binutils. > --0000000000002c56c505e82e2d9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
re hardware, in several cases in the 60s, when old hardwar= e was connected to new hardware to verify the new hardware's floating p= oint, the new hardware had a difference -- and the bug was in the old hardw= are.=C2=A0

Gordon Bell mentioned this in "Computer = Engineering", IIRC; I am also told some model of 360 and 370 also foun= d bugs in ... the 360.

And let's not forget wh= at in the supercomputing biz was called "Cray Floating Point": e.= g. X * Y did not always=C2=A0equal Y * X. But the answer came back fast :-)=

On Thu, Sep 8, 2022 at 9:50 AM segaloco <segaloco@protonmail.com> wrote:
> In addition, when Dennis woul= d talk about Coherent and his evaluation of the source code, he said he use= d the known to him, but not widely known bugs in Unix to try to catch copyi= ng. If there was copying, those would be copied. If it was freshly implemen= ted, there's a high likelihood that they wouldn't. His conclusion w= as that someone had access to a lot of knowledge about the Unix system give= n the fidelity of the implementation, but the lack of bugs and novel ways o= f doing it suggested independent implementation.

Both Coherent and 4.4BSD have stuck out to me as examples of not-quite-so-c= lean-room implementations that did well enough (more than enough for BSD) a= nd didn't die a fiery death in litigation (as much as USL tried...).=C2= =A0 What I find interesting is that in this day and age, it seems there is = almost a requirement for true "clean-room" implementation if some= thing is going to be replicated, which I understand to mean the team develo= ping the new implementation can't be the same team that performed a det= ailed analysis of the product being reimplemented, but the latter team can = produce a white paper/writeup/memorandum describing the results of their an= alysis and the development team can then use that so long as it doesn't= contain any implementation details.

I've always wondered how cleanly that sort of thing can actually be pro= ven and enforced, and I've always thought back to the Coherent situatio= n as an almost model example.=C2=A0 Where proving copying outright can be d= ifficult, knowing one's own product well enough to know the bugs that a= re incredibly obscure but also reliably consistent is a great way to peg a = faithful recreation vs. a flat out copy job.=C2=A0 That said, my assumption= with complete UNIX re-implementations is that folks at least had access to= the manuals, perhaps had used UNIX before in some capacity.=C2=A0 I would = assume the current definition of a clean-room implementation only requires = that the developers/implementors don't have access to the code of the p= arent product (source or reverse engineered), but could read manuals, study= behavior in-situ, and use that level of "reverse engineering" to= extract the design from the implementation, so not knowing the gritty deta= ils, Coherent could be a true clean-room.

BSD is a different beast, as they were literally replacing the AT&T sou= rce code before their eyes, so there isn't much argument that can be ma= de for 4.4BSD being a "clean-room" implementation of UNIX.=C2=A0 = Simply for compatibility and upgrade-ability of existing systems, they had = to be incredibly accurate to the original design.=C2=A0 Given that, that= 9;s one of the more surprising things to me about 4.4BSD prevailing in the = lawsuit, because while Berkeley could easily prove that they had replaced m= ost of AT&T's code, there's still the fact that their team did = have complete and unfettered access to Bell UNIX code at least circa 32V.= =C2=A0 Not sure if the licensing allowed for source-code cross-talk between= USG/USL UNIX source and Berkeley, but I remember reading somewhere that CS= RG students and faculty avoided commercial UNIX like the plague, going so f= ar as to not even look at the literature to see what changes occurred since= 32V.

Anywho just some thoughts, I find the realm of reverse engineering and re-i= mplementation fascinating, and am always interested in this sort of discuss= ion.

- Matt G.

P.S. Don't want to derail the thread with this, unless it's deemed = worthy addition, but feel free to email privately.=C2=A0 Does anyone know i= f there was a "formal" PDP-11 and/or VAX disassembler produced by= Bell?=C2=A0 I know there was one floating around the "user maintained= " utilities at some point, I recall seeing a note in a manual saying s= omething to the effect "Rumor has it there is a PDP-11 disassembler&qu= ot; but I'm curious if such tools were ever provided in any sort of off= icial capacity.=C2=A0 I've been doing some research on what RE tools pe= ople had on hand at the time, think "objdump" from GNU binutils.<= br>
--0000000000002c56c505e82e2d9d--