[TUHS] Re: Has this been discussed on-list? How Unix changed Software.

[ron minnich <rminnich@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4667 bytes --]

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 <segaloco@protonmail.com> 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.
>

[-- Attachment #2: Type: text/html, Size: 5127 bytes --]