The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: clemc@ccc.com (Clem Cole)
Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...]
Date: Wed, 22 Feb 2017 17:56:38 -0500	[thread overview]
Message-ID: <CAC20D2MCmmi3HrG65CN=vnmyPzkb0s6hCLkKZM8=NQC=Y=YyRA@mail.gmail.com> (raw)
In-Reply-To: <20170222213405.GJ9439@mcvoy.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3676 bytes --]

On Wed, Feb 22, 2017 at 4:34 PM, Larry McVoy <lm at mcvoy.com> wrote:

>
> How well is that "any reasonable programmer
> would have written it that way" going to play with with you?
>
​That is the key point of course.   I suspect it depends on a lot of
things.  I could see myself being pretty upset.



>
> I find it really really hard to swallow that any reasonable programmer
> would come up with the same code in a vacuum.
>
​And that is why there are courts.    I'm not going to say you are right or
wrong.  Low level routines like bit map, locks etc, I suspect are going to
look pretty similar.   For whatever it is worth we talk about this in a
committee I'm on at Intel.  The lawyers want to know how they can detect
that some one is infringing on a patent.  I'm usually the guy saying --
"wait a minute -- that's how we designed the instruction - that how its
supposed to be used, so that's reasonable."​

I'm not lawyer.... and I don't even try to play one.  But my experience is
that at least in the low level stuff, the lower stuff, it does get pretty
common.   That said, if you have a trick or two up, say using an
instruction sequence in an unusual manner - as you say -- experience --
that's where the differences start to show.

BTW: you pick on BFFS (aka UFS).   I was under the impression that pretty
much that was an entire rewrite.  The vax code brought over from 4.1 was
code Berkeley had written during the joy's speed up work (even things like
bmap).   I did not think that came from 32/V.   The key is the changes were
done a little a time.  Some in BSD, some more in BSD 2.0, more in 3.0 ....
by the time of 4.2 the feeling was most of the kernel was different from
what Ken and Dennis had originally written.


> I'd argue that what you'd get from any reasonable programmer is the
> naive initial version that works in theory but fails in practice.
>
​Fair enough... and you might be able to make a reasonable living as a
expert witness ;-)
​

>
> In my mind, the BSD guys cheated.

​I understand and I see your point, although here is where we disagree.​  I
lived it differently, since I was part of it.  I think it was like the wolf
that became the dog. A very slow process.  But at some point, there was a
change and the wolf stopped being a wolf and started being a new thing, a
dog.


Morally, in my mind, BSD was tainted.  Whether it was proven so in a
> court of law doesn't change my opinion.

​That's fair and I think you know, I very much respect your opinion and
thinking.  I don't expect to change it any more than I can expect you will
change mine own, but I'm trying to understand it.




> It was AT&T's code to release
> ​ ​
> ....
> Doing so is theft in my book.
>
​Fair enough.  To you its still a wolf and I can see that and if I did see
it as a wold, I suspect I might agree.  But I think having lived so much
working being done outside of AT&T that was not getting credit and that
"DNA" was being "stollen" by AT&T in my mind, it worked both ways.

​

>
> And for the record, I've seen the same behaviour in Linux.
>
​yep...​as bad or worse.   Names of have changed to protect the guilty ;-)

Many of the things the esr, rms et al have pontificated about frankly is
not different.   I see the same behaviors, just a change in who has the
gold now.



> Perhaps my ethics are a bit too rigid, but they are my ethics and
> aren't likely to change.
>
Amen, they work for you, and I as I said, I can (and do) respect that.​

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/c2f5bc64/attachment-0001.html>


  reply	other threads:[~2017-02-22 22:56 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-22  3:38 Clem Cole
2017-02-22  4:28 ` Dan Cross
2017-02-22 15:36   ` Clem Cole
2017-02-22 16:11     ` Larry McVoy
2017-02-22 17:00       ` Clem Cole
2017-02-22 17:06         ` Chet Ramey
2017-02-22 18:24         ` Larry McVoy
2017-02-22 19:35           ` Clem Cole
2017-02-22 20:18             ` arnold
2017-02-22 22:11               ` Clem Cole
2017-02-22 21:34             ` Larry McVoy
2017-02-22 22:56               ` Clem Cole [this message]
2017-02-22 23:13                 ` Larry McVoy
2017-02-22 23:51                   ` Clem Cole
2017-02-22 23:51           ` Paul Ruizendaal
2017-02-23 19:15             ` Clem Cole
2017-02-23 20:31               ` Random832
2017-02-23 22:48                 ` Joerg Schilling
2017-02-24  2:07                   ` Jason Stevens
2017-02-23 23:06                 ` Wesley Parish
2017-02-22 17:41       ` Arthur Krewat
2017-02-22 21:00     ` Michael Kerpan
2017-02-22 22:03       ` Arno Griffioen
2017-02-22 22:51         ` Larry McVoy
2017-02-22 23:29         ` Clem Cole
2017-02-23  4:53           ` Gregg Levine
2017-02-22 22:18       ` Clem Cole
2017-02-24  3:53     ` Dan Cross
2017-02-22  5:56 ` Steve Nickolas
2017-02-24  5:31   ` John Labovitz

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to='CAC20D2MCmmi3HrG65CN=vnmyPzkb0s6hCLkKZM8=NQC=Y=YyRA@mail.gmail.com' \
    --to=clemc@ccc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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