The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: ron minnich <>
To: segaloco <>
Cc: Steve Jenkin <>, TUHS <>
Subject: [TUHS] Re: Has this been discussed on-list? How Unix changed Software.
Date: Thu, 8 Sep 2022 10:58:16 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- 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 <> 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 --]

  reply	other threads:[~2022-09-08 17:59 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-06 15:07 Douglas McIlroy
2022-09-06 17:13 ` Larry McVoy
2022-09-07  1:40 ` steve jenkin
2022-09-07  2:33   ` segaloco via TUHS
2022-09-07  4:08     ` Steve Jenkin
2022-09-07 13:08   ` Steffen Nurpmeso
2022-09-07 14:56   ` Larry McVoy
2022-09-07 21:27     ` Steve Jenkin
2022-09-07 22:36       ` Larry McVoy
2022-09-08 14:42       ` Paul Winalski
2022-09-08 15:02         ` Larry McVoy
2022-09-08 15:04         ` ron minnich
2022-09-08 15:52           ` Warner Losh
2022-09-08 16:47             ` Paul Winalski
2022-09-08 16:50             ` segaloco via TUHS
2022-09-08 17:58               ` ron minnich [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-09-06 19:04 Douglas McIlroy
2022-09-05 23:48 [TUHS] " steve jenkin
2022-09-06 16:09 ` [TUHS] " Marc Donner
2022-09-07  4:00   ` steve jenkin
2022-09-07 14:58     ` John Cowan
2022-09-07 17:13     ` Paul Winalski
2022-09-08 14:12       ` Paul Winalski
2022-09-07  5:15   ` steve jenkin
2022-09-07 13:20     ` Dan Cross
2022-09-07 13:52       ` Steve Nickolas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).