From: segaloco via TUHS <firstname.lastname@example.org>
To: Warner Losh <email@example.com>
Cc: Steve Jenkin <firstname.lastname@example.org>, TUHS <email@example.com>
Subject: [TUHS] Re: Has this been discussed on-list? How Unix changed Software.
Date: Thu, 08 Sep 2022 16:50:43 +0000 [thread overview]
Message-ID: <ORjZtVTUT1kw0xw7mL_9MunCpEwGcw2HF6I5m02pMLiNQy6mav_fGo0oz4gGrzPnW8eOX8mqZZMYntXg1MIwLsX0cL111wbhuIW4pXw_Ptofirstname.lastname@example.org> (raw)
> 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.
next prev parent reply other threads:[~2022-09-08 16:51 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 [this message]
2022-09-08 17:58 ` ron minnich
-- 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
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 \
* 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).