The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Re: Re-implementations/Clean-Rooms et al.
@ 2022-09-08 21:50 Clem Cole
  2022-09-08 22:16 ` Larry McVoy
  2022-09-08 22:17 ` Warner Losh
  0 siblings, 2 replies; 12+ messages in thread
From: Clem Cole @ 2022-09-08 21:50 UTC (permalink / raw)
  To: segaloco, TUHS

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

On Thu, Sep 8, 2022 at 12:51 PM segaloco via TUHS <tuhs@tuhs.org> wrote:

> 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...).

Be careful with that statement both parts of it are not wholly on target.
In the first, AT&T chose not to litigate against Coherent fully.  As was
pointed out, Dennis and the team that examined the code base determined it
was 'clean enough.'     If I recall, his comment was something like "It was
clear they had seen and had access to the AT&T IP at some point, most
likely at University (IIRC many of the founders were ex-University
Waterloo), but they did not find evidence of direct copying of files."

BSDi/UCB *vs. *USL was a different kettle of fish altogether.   As has been
discussed here extensively (and needs not to be repeated), that suit was
about *Trade Secrets and >>ideas<< that make up what we call UNIX.*   The
real interesting thing about that case is that had USL/AT&T won, the
repercussions for the industry would have been way beyond just BSDi - *but
all of the UNIX clones* and many of us on this list who had been "mentally
contaminated" with AT&T's ideas (I still have my 'mental contamination'
button somewhere in my archives).

The good news is that the US courts had the good sense to realize that the
moment the US Gov put the consent decree down in 1956 and required that
AT&T make their IP available and then enabled AT&T had its people start to
write about their work in the open literature (in UNIX's case the original
CACM paper, but continuing with all the books, follow on papers, etc), plus
being such wonderfully active participants in the research community at
large, it could not be called a secret.



> 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.
>
It's not "day and age" it's from the original case law -- the term was
coined by the late Arthur Kahn, Esquire who was the lead attorney for
Franklin Computers, Inc in the Franklin *vs.* Apple Case - which he
originally won and ultimately lost on appeal [Good guy BTW, particularly
for a non-technically trained person - he 'got it'].   The concept is that
one group is in a dirty room and the other in a clean room.  Information is
unidirectional.   The dirty room can read published documentation, probe,
and test the device/implementation using standard programming techniques.
 And then write a new document that describes the functionality of the
device in question.  Then hand it to the folks in the clean room who can
reimplement a device to that new specification.

The point of contention in the case is if *the original documentation for
the device*, in this case, the Apple Assembler listing for Wos's Apple-II
ROMs were protected by copy once they had been transformed from their
printed form in Apple;'s red books into the binary and stored in the ROMS
themselves.

Franklin's 'dirty room' ultimately wrote a series of test programs that
demonstrated each of the externally available locations and entries in the
ROMs. This they documents and their new clean-room programmers wrote a new
set of ROM that duplicated the functionality.  IIRC the story is that
Franklin ROMs were a few bytes smaller in the end.  Compaq would later the
same scheme for the IBM PC.



>  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.
>
Be careful here. I used to work for a firm that did a lot of work for
different vendors that would build some of these clean-room sub-systems (in
fact for some of the folks --  at least one -- of the readers of this
list).   We were always careful for the clean-room people to be ones we
were fairly sure had not seen that customers product previously.   I was
almost always on the 'dirty' team in many of those projects because I was
so contaminated with the IP of so many of our customers' work.   Because we
worked for IBM, Sun, DEC, HP, DG, AT&T, *etc*. all at the same time had
their IP in-house we had very strict rules about how things were handled.
Even what sites and what sub-nets data could be on -- which system admins
had the passwords.  No one person had access to all of the passwords. We
had a locked safe for each customer with secure things like passwords
(really) and rooms with locks and videos, and access doors.   It was really
serious stuff.

Frankly, I think part of why we got some of the "work for hires" tasks was
because those firms trusted us to handle their IP properly.  No way did we
want to contaminate something accidentally.  Some projects like our big TNC
[Transparent Network Computing] system we were working on for all of IBM,
DEC, HP, and Intel simultaneously -- 4 different teams.  The architects
could talk to each other, and we talked about common issues, but it was a
different code.  I know we implemented things a couple of times - although
we got smarter.   For instance, the original RPC marshaling was done for
IBM with 'the awk script from hell' which later became an interface
generator that all four teams used.



>
> 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.

It was not a clean-room as Arthur defined it.   It was rewritten over time,
which replaced AT&T's implementation.  Which is all that was ever claimed.




>  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.

I expect this is because you don't quite understand what happened.



>  but I remember reading somewhere that CSRG students and faculty avoided
> commercial UNIX like the plague,

Hmmm, I read it on the Internet -- it must be true ;-)

CSRG had Ultrix/VAX, SunOS/3, and I believe HP-UX/PA sources. They shipped
several DEC-developed drivers in 4.1A/4.1B/4.1C -- Sam, Bill Shanon, and I
tested a couple of them on one of my machines in Cory Hall as DEC has
donated one of the 3 CAD machines [UCBCAD - a.k.a. 'coke' ], and it was the
only 'pure' DEC machine on campus - without any 3rd party HW in it.  After
I graduated, I suspect Sam continued the relationship with Tom Quarles, so
4.2BSD was likely tested on that system too.  But I know the RH-based TAPES
and DISKs were all straight from Shannon's SCCS Ultrix repo as he sent them
to me to try before I gave them to Sam.


>  Does anyone know if there was a "formal" PDP-11 and/or VAX disassembler
> produced by Bell?

Most of the compiler kits have disassemblers, as do many debuggers -- what
are you asking?



>  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.
>
In the mid/late-70s (*i.e.* V6/V7 time frame) there are a couple of them --
where to start -- V7 has one inside of adb, and if I recall later versions
of PCC2 has one.  But if you look in the USENIX tapes you can find a couple
of pretty well-adorned ones.   There was one that IIRC was done by ??Cooper
Union?? guys that spit out DEC MACRO-11 syntax for the Harvard assembler.
That should be on the TUHS archives.   Thinking about it,  Phil Karn had
one too that did some interesting label patch-up IIRC - which I think he
brought with him to CMU from somewhere -- but I may be miss remembering
that.

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [TUHS] Re: Re-implementations/Clean-Rooms et al.
  2022-09-08 21:50 [TUHS] Re: Re-implementations/Clean-Rooms et al Clem Cole
@ 2022-09-08 22:16 ` Larry McVoy
  2022-09-08 22:26   ` Warner Losh
  2022-09-08 23:34   ` Clem Cole
  2022-09-08 22:17 ` Warner Losh
  1 sibling, 2 replies; 12+ messages in thread
From: Larry McVoy @ 2022-09-08 22:16 UTC (permalink / raw)
  To: Clem Cole; +Cc: segaloco, TUHS

On Thu, Sep 08, 2022 at 05:50:37PM -0400, Clem Cole wrote:
> > 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.
> 
> It was not a clean-room as Arthur defined it.   It was rewritten over time,
> which replaced AT&T's implementation.  Which is all that was ever claimed.

And it's a false claim.  Go look at the Bell Labs bmap() and the BSD
bmap(), the last time I looked they were bit for bit identical.

I looked there because I split bmap() into bmap_read() and bmap_write()
because the read path is trivial and the write path is quite a bit more
difficult (this was all for the work srk imagined, and I did, to get
rid of the rotational delays).  So I was pretty familiar with that
code path and as of about 20 years ago, well past 4.4BSD, bmap() was
unchanged from either v7 or 32v.

The weird thing is it isn't that hard to write something that would
walk the code and find other examples.  Nobody seemed to care.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [TUHS] Re: Re-implementations/Clean-Rooms et al.
  2022-09-08 21:50 [TUHS] Re: Re-implementations/Clean-Rooms et al Clem Cole
  2022-09-08 22:16 ` Larry McVoy
@ 2022-09-08 22:17 ` Warner Losh
  1 sibling, 0 replies; 12+ messages in thread
From: Warner Losh @ 2022-09-08 22:17 UTC (permalink / raw)
  To: Clem Cole; +Cc: segaloco, TUHS

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

On Thu, Sep 8, 2022 at 3:52 PM Clem Cole <clemc@ccc.com> wrote:

> On Thu, Sep 8, 2022 at 12:51 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>
>> 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...).
>
> BSDi/UCB *vs. *USL was a different kettle of fish altogether.   As has
> been discussed here extensively (and needs not to be repeated), that suit
> was about *Trade Secrets and >>ideas<< that make up what we call UNIX.*
>  The real interesting thing about that case is that had USL/AT&T won, the
> repercussions for the industry would have been way beyond just BSDi - *but
> all of the UNIX clones* and many of us on this list who had been
> "mentally contaminated" with AT&T's ideas (I still have my 'mental
> contamination' button somewhere in my archives).
>

Yes. Indeed. It devolved to a copyright battle with the ultimate result
being a preliminary ruling that 32V (and V6 and V7 likely) had no copyright
protection because AT&T had distributed too many copies without the
required (at the time) copyright notices...  That preliminary ruling is
what forced the settlement of the suit, and is the reason that 4.4BSD-lite
had a bunch of files with AT&T copyrights on them with permission to
redistribute liberally...

These days, in open source cleanroom is rarely done except in extraordinary
cases. It's easier to read the code and reimplement because copyright
covers only the typing...

Warner

>

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [TUHS] Re: Re-implementations/Clean-Rooms et al.
  2022-09-08 22:16 ` Larry McVoy
@ 2022-09-08 22:26   ` Warner Losh
  2022-09-08 22:28     ` Warner Losh
  2022-09-08 23:30     ` Steve Nickolas
  2022-09-08 23:34   ` Clem Cole
  1 sibling, 2 replies; 12+ messages in thread
From: Warner Losh @ 2022-09-08 22:26 UTC (permalink / raw)
  To: Larry McVoy; +Cc: segaloco, TUHS

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

On Thu, Sep 8, 2022 at 4:16 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Thu, Sep 08, 2022 at 05:50:37PM -0400, Clem Cole wrote:
> > > 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.
> >
> > It was not a clean-room as Arthur defined it.   It was rewritten over
> time,
> > which replaced AT&T's implementation.  Which is all that was ever
> claimed.
>
> And it's a false claim.  Go look at the Bell Labs bmap() and the BSD
> bmap(), the last time I looked they were bit for bit identical.
>

Yea, this was part of the de minimis copying that was acknowledged...
It was mostly rewritten with most of AT&T's code gone. It's 110 lines of
code,
out of ~18,000 lines of kernel code. And the structure in 4.4BSD is somewhat
different with balloc() being completely different than the rest of V7's
subr.c.


> I looked there because I split bmap() into bmap_read() and bmap_write()
> because the read path is trivial and the write path is quite a bit more
> difficult (this was all for the work srk imagined, and I did, to get
> rid of the rotational delays).  So I was pretty familiar with that
> code path and as of about 20 years ago, well past 4.4BSD, bmap() was
> unchanged from either v7 or 32v.
>

But it likely didn't matter, since 32v likely lost its copyright protection
due
to AT&T distributing too many copies without the required copyright
markings.
At least that was the preliminary ruling that caused the suit to be
settled...
AT&T didn't want it finalized, though the cat was somewhat out of the bag
at this point...


> The weird thing is it isn't that hard to write something that would
> walk the code and find other examples.  Nobody seemed to care.
>

Yea, most of the rest of the code around it was rewritten, but not that.

Warner

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [TUHS] Re: Re-implementations/Clean-Rooms et al.
  2022-09-08 22:26   ` Warner Losh
@ 2022-09-08 22:28     ` Warner Losh
  2022-09-08 23:30     ` Steve Nickolas
  1 sibling, 0 replies; 12+ messages in thread
From: Warner Losh @ 2022-09-08 22:28 UTC (permalink / raw)
  To: Larry McVoy; +Cc: segaloco, TUHS

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

On Thu, Sep 8, 2022 at 4:26 PM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Thu, Sep 8, 2022 at 4:16 PM Larry McVoy <lm@mcvoy.com> wrote:
>
>> On Thu, Sep 08, 2022 at 05:50:37PM -0400, Clem Cole wrote:
>> > > 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.
>> >
>> > It was not a clean-room as Arthur defined it.   It was rewritten over
>> time,
>> > which replaced AT&T's implementation.  Which is all that was ever
>> claimed.
>>
>> And it's a false claim.  Go look at the Bell Labs bmap() and the BSD
>> bmap(), the last time I looked they were bit for bit identical.
>>
>
> Yea, this was part of the de minimis copying that was acknowledged...
> It was mostly rewritten with most of AT&T's code gone. It's 110 lines of
> code,
> out of ~18,000 lines of kernel code. And the structure in 4.4BSD is
> somewhat
> different with balloc() being completely different than the rest of V7's
> subr.c.
>

I should have added it was one of the 23 files in 4.4lite that was
acknowledged
as having some AT&T code that AT&T agreed to release...


> I looked there because I split bmap() into bmap_read() and bmap_write()
>> because the read path is trivial and the write path is quite a bit more
>> difficult (this was all for the work srk imagined, and I did, to get
>> rid of the rotational delays).  So I was pretty familiar with that
>> code path and as of about 20 years ago, well past 4.4BSD, bmap() was
>> unchanged from either v7 or 32v.
>>
>
> But it likely didn't matter, since 32v likely lost its copyright
> protection due
> to AT&T distributing too many copies without the required copyright
> markings.
> At least that was the preliminary ruling that caused the suit to be
> settled...
> AT&T didn't want it finalized, though the cat was somewhat out of the bag
> at this point...
>
>
>> The weird thing is it isn't that hard to write something that would
>> walk the code and find other examples.  Nobody seemed to care.
>>
>
> Yea, most of the rest of the code around it was rewritten, but not that.
>
> Warner
>

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [TUHS] Re: Re-implementations/Clean-Rooms et al.
  2022-09-08 22:26   ` Warner Losh
  2022-09-08 22:28     ` Warner Losh
@ 2022-09-08 23:30     ` Steve Nickolas
  2022-09-08 23:42       ` Warner Losh
  1 sibling, 1 reply; 12+ messages in thread
From: Steve Nickolas @ 2022-09-08 23:30 UTC (permalink / raw)
  To: TUHS

On Thu, 8 Sep 2022, Warner Losh wrote:

> But it likely didn't matter, since 32v likely lost its copyright 
> protection due to AT&T distributing too many copies without the required 
> copyright markings. At least that was the preliminary ruling that caused 
> the suit to be settled... AT&T didn't want it finalized, though the cat 
> was somewhat out of the bag at this point...

It would be nice if that were an absolute rather than a probably, because 
then the status for 32V wouldn't be clouded.

-uso.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [TUHS] Re: Re-implementations/Clean-Rooms et al.
  2022-09-08 22:16 ` Larry McVoy
  2022-09-08 22:26   ` Warner Losh
@ 2022-09-08 23:34   ` Clem Cole
  1 sibling, 0 replies; 12+ messages in thread
From: Clem Cole @ 2022-09-08 23:34 UTC (permalink / raw)
  To: Larry McVoy; +Cc: segaloco, TUHS

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

On Thu, Sep 8, 2022 at 6:16 PM Larry McVoy <lm@mcvoy.com> wrote:

> > It was rewritten over time,
> > which replaced AT&T's implementation.  Which is all that was ever
> claimed.
>
> And it's a false claim.
>
I believe you.  But BSD's rewrite was good enough.  The real key is the
BSDi/UCB *vs.* USL/AT&T case was *not about the code (or copyrights).* That
is the piece most hackers don't seem to understand. The case was about *trade
secrets (or not) *and thus the *ideas*.  BSDi/UCB released their system
which clearly had started with code that had originated with AT&T and thus
the *ideas* had to have originated there too.

I think too many hackers get caught up in FOSS, GPL,* et al,* and miss the
point.

The real debt which we can never repay Doug, Ken, Dennis, and friends was
their *ideas* and the way they broke down and solved problems.   The code
is a by-product, the existence proof that it was more than theory, but had
a practical use.
ᐧ

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [TUHS] Re: Re-implementations/Clean-Rooms et al.
  2022-09-08 23:30     ` Steve Nickolas
@ 2022-09-08 23:42       ` Warner Losh
  2022-09-09  0:05         ` Steve Nickolas
  0 siblings, 1 reply; 12+ messages in thread
From: Warner Losh @ 2022-09-08 23:42 UTC (permalink / raw)
  To: Steve Nickolas; +Cc: TUHS

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

On Thu, Sep 8, 2022 at 5:29 PM Steve Nickolas <usotsuki@buric.co> wrote:

> On Thu, 8 Sep 2022, Warner Losh wrote:
>
> > But it likely didn't matter, since 32v likely lost its copyright
> > protection due to AT&T distributing too many copies without the required
> > copyright markings. At least that was the preliminary ruling that caused
> > the suit to be settled... AT&T didn't want it finalized, though the cat
> > was somewhat out of the bag at this point...
>
> It would be nice if that were an absolute rather than a probably, because
> then the status for 32V wouldn't be clouded.
>

It would be nice. At this late date, one wonders what would happen if it
were
litigated again...  I suspect that nobody would bother given the small
possible
gain and the huge expense... But it would also reduce shareholder values
to explicitly say there's no copyright here or to clarify that the ancient
licenses
are valid. So we're in this state where it's basically free and clear,
treated like
it's free and clear, but really isn't free and clear.

Warner

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [TUHS] Re: Re-implementations/Clean-Rooms et al.
  2022-09-08 23:42       ` Warner Losh
@ 2022-09-09  0:05         ` Steve Nickolas
  2022-09-09  0:17           ` Larry McVoy
  0 siblings, 1 reply; 12+ messages in thread
From: Steve Nickolas @ 2022-09-09  0:05 UTC (permalink / raw)
  To: TUHS

On Thu, 8 Sep 2022, Warner Losh wrote:

> On Thu, Sep 8, 2022 at 5:29 PM Steve Nickolas <usotsuki@buric.co> wrote:
>
>> On Thu, 8 Sep 2022, Warner Losh wrote:
>>
>>> But it likely didn't matter, since 32v likely lost its copyright
>>> protection due to AT&T distributing too many copies without the required
>>> copyright markings. At least that was the preliminary ruling that caused
>>> the suit to be settled... AT&T didn't want it finalized, though the cat
>>> was somewhat out of the bag at this point...
>>
>> It would be nice if that were an absolute rather than a probably, because
>> then the status for 32V wouldn't be clouded.
>>
>
> It would be nice. At this late date, one wonders what would happen if it 
> were litigated again...  I suspect that nobody would bother given the 
> small possible gain and the huge expense... But it would also reduce 
> shareholder values to explicitly say there's no copyright here or to 
> clarify that the ancient licenses are valid. So we're in this state 
> where it's basically free and clear, treated like it's free and clear, 
> but really isn't free and clear.
>
> Warner

I'm probably the only one brazen enough to put it to the test.

For some years, I've wanted to create a free implementation of System V, 
and then move on from there.  (I know there's limited utility for such a 
thing, because of the BSDs.)

A few things actually hinge on this.  If it were considered a fact, and 
not a mere opinion, that 32V was PD, then I could be sure that certain 
things were safe to use, rather than having to rewrite (including some 
particularly tricky stuff the BSDs never fully reimplemented, like 
diff(1)).

I actually did write a replacement for the Caldera header. (I still hold 
that the Caldera license is void because it has a Caldera copyright claim, 
and it has been proven in court that they didn't have the copyright to 
give.)  It just says why I think it *should* be safe to use the code.

-uso.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [TUHS] Re: Re-implementations/Clean-Rooms et al.
  2022-09-09  0:05         ` Steve Nickolas
@ 2022-09-09  0:17           ` Larry McVoy
  2022-09-09  0:52             ` Steve Nickolas
  0 siblings, 1 reply; 12+ messages in thread
From: Larry McVoy @ 2022-09-09  0:17 UTC (permalink / raw)
  To: Steve Nickolas; +Cc: TUHS

On Thu, Sep 08, 2022 at 08:05:44PM -0400, Steve Nickolas wrote:
> On Thu, 8 Sep 2022, Warner Losh wrote:
> 
> >On Thu, Sep 8, 2022 at 5:29 PM Steve Nickolas <usotsuki@buric.co> wrote:
> >
> >>On Thu, 8 Sep 2022, Warner Losh wrote:
> >>
> >>>But it likely didn't matter, since 32v likely lost its copyright
> >>>protection due to AT&T distributing too many copies without the required
> >>>copyright markings. At least that was the preliminary ruling that caused
> >>>the suit to be settled... AT&T didn't want it finalized, though the cat
> >>>was somewhat out of the bag at this point...
> >>
> >>It would be nice if that were an absolute rather than a probably, because
> >>then the status for 32V wouldn't be clouded.
> >>
> >
> >It would be nice. At this late date, one wonders what would happen if it
> >were litigated again...  I suspect that nobody would bother given the
> >small possible gain and the huge expense... But it would also reduce
> >shareholder values to explicitly say there's no copyright here or to
> >clarify that the ancient licenses are valid. So we're in this state where
> >it's basically free and clear, treated like it's free and clear, but
> >really isn't free and clear.
> >
> >Warner
> 
> I'm probably the only one brazen enough to put it to the test.
> 
> For some years, I've wanted to create a free implementation of System V, and
> then move on from there.  (I know there's limited utility for such a thing,
> because of the BSDs.)

Why?  Have you booted 32V?  Run in it for a while?  No VM, no networking,
very basic system.  Other than historical, I don't understand the point.

> A few things actually hinge on this.  If it were considered a fact, and not
> a mere opinion, that 32V was PD, then I could be sure that certain things
> were safe to use, rather than having to rewrite (including some particularly
> tricky stuff the BSDs never fully reimplemented, like diff(1)).

I'm a source management guy, I've written a couple of systems.  I live and
breath diff and diff(1) is not in the slightest way hard.  I wrote my own
version of SCCS in a way that you could get as many different versions of
the history as you wanted in one pass.  That's a lot harder than diff(1).

But maybe I don't understand what you think is tricky about diff, you 
may have some insight I'm missing, care to share?

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [TUHS] Re: Re-implementations/Clean-Rooms et al.
  2022-09-09  0:17           ` Larry McVoy
@ 2022-09-09  0:52             ` Steve Nickolas
  2022-09-09  2:16               ` Larry McVoy
  0 siblings, 1 reply; 12+ messages in thread
From: Steve Nickolas @ 2022-09-09  0:52 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS

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

On Thu, 8 Sep 2022, Larry McVoy wrote:

> On Thu, Sep 08, 2022 at 08:05:44PM -0400, Steve Nickolas wrote:
>>
>> I'm probably the only one brazen enough to put it to the test.
>>
>> For some years, I've wanted to create a free implementation of System V, and
>> then move on from there.  (I know there's limited utility for such a thing,
>> because of the BSDs.)
>
> Why?  Have you booted 32V?  Run in it for a while?  No VM, no networking,
> very basic system.  Other than historical, I don't understand the point.

Wasn't so much about 32V itself, as 32V being potentially clear and the 
source for a lot of SysV, that having 32V would make rewriting SysV a lot 
easier. 🤪

I've used v7/386, which is probably a comparable system.

>> A few things actually hinge on this.  If it were considered a fact, and not
>> a mere opinion, that 32V was PD, then I could be sure that certain things
>> were safe to use, rather than having to rewrite (including some particularly
>> tricky stuff the BSDs never fully reimplemented, like diff(1)).
>
> I'm a source management guy, I've written a couple of systems.  I live and
> breath diff and diff(1) is not in the slightest way hard.  I wrote my own
> version of SCCS in a way that you could get as many different versions of
> the history as you wanted in one pass.  That's a lot harder than diff(1).
>
> But maybe I don't understand what you think is tricky about diff, you
> may have some insight I'm missing, care to share?

I'm not actually that good a programmer.  Step me through an algo, I can 
probably interpret that as C, BASIC, 6502 ASM or 8086 ASM - but whether I 
can implement it from just an explanation, that's hit or miss.

Frequently I come up with stupid ideas that I think are beyond me, and 
often I'm right.  Once in a while they're not, and I'm able to actually 
implement something.  😜

Stuff like diff or sccs might be easy for some people here - but I've 
spent months wracking my brain on things I think are simpler (6502 CPU 
core for example - which is why for 20 years I used others' cores) and 
been fruitless.

-uso.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [TUHS] Re: Re-implementations/Clean-Rooms et al.
  2022-09-09  0:52             ` Steve Nickolas
@ 2022-09-09  2:16               ` Larry McVoy
  0 siblings, 0 replies; 12+ messages in thread
From: Larry McVoy @ 2022-09-09  2:16 UTC (permalink / raw)
  To: Steve Nickolas; +Cc: TUHS

So there is this thing that us old people do that old people did to us.
Go do it, kid, you can do it.

It doesn't always work but it works way more than you might think.
I was one of those kids where it worked.

On Thu, Sep 08, 2022 at 08:52:57PM -0400, Steve Nickolas wrote:
> On Thu, 8 Sep 2022, Larry McVoy wrote:
> 
> >On Thu, Sep 08, 2022 at 08:05:44PM -0400, Steve Nickolas wrote:
> >>
> >>I'm probably the only one brazen enough to put it to the test.
> >>
> >>For some years, I've wanted to create a free implementation of System V, and
> >>then move on from there.  (I know there's limited utility for such a thing,
> >>because of the BSDs.)
> >
> >Why?  Have you booted 32V?  Run in it for a while?  No VM, no networking,
> >very basic system.  Other than historical, I don't understand the point.
> 
> Wasn't so much about 32V itself, as 32V being potentially clear and the
> source for a lot of SysV, that having 32V would make rewriting SysV a lot
> easier. ????
> 
> I've used v7/386, which is probably a comparable system.
> 
> >>A few things actually hinge on this.  If it were considered a fact, and not
> >>a mere opinion, that 32V was PD, then I could be sure that certain things
> >>were safe to use, rather than having to rewrite (including some particularly
> >>tricky stuff the BSDs never fully reimplemented, like diff(1)).
> >
> >I'm a source management guy, I've written a couple of systems.  I live and
> >breath diff and diff(1) is not in the slightest way hard.  I wrote my own
> >version of SCCS in a way that you could get as many different versions of
> >the history as you wanted in one pass.  That's a lot harder than diff(1).
> >
> >But maybe I don't understand what you think is tricky about diff, you
> >may have some insight I'm missing, care to share?
> 
> I'm not actually that good a programmer.  Step me through an algo, I can
> probably interpret that as C, BASIC, 6502 ASM or 8086 ASM - but whether I
> can implement it from just an explanation, that's hit or miss.
> 
> Frequently I come up with stupid ideas that I think are beyond me, and often
> I'm right.  Once in a while they're not, and I'm able to actually implement
> something.  ????
> 
> Stuff like diff or sccs might be easy for some people here - but I've spent
> months wracking my brain on things I think are simpler (6502 CPU core for
> example - which is why for 20 years I used others' cores) and been
> fruitless.
> 
> -uso.


-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2022-09-09  2:17 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-08 21:50 [TUHS] Re: Re-implementations/Clean-Rooms et al Clem Cole
2022-09-08 22:16 ` Larry McVoy
2022-09-08 22:26   ` Warner Losh
2022-09-08 22:28     ` Warner Losh
2022-09-08 23:30     ` Steve Nickolas
2022-09-08 23:42       ` Warner Losh
2022-09-09  0:05         ` Steve Nickolas
2022-09-09  0:17           ` Larry McVoy
2022-09-09  0:52             ` Steve Nickolas
2022-09-09  2:16               ` Larry McVoy
2022-09-08 23:34   ` Clem Cole
2022-09-08 22:17 ` Warner Losh

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).