From: George Michaelson <email@example.com> To: "Theodore Y. Ts'o" <firstname.lastname@example.org> Cc: Computer Old Farts Followers <email@example.com>, TUHS main list <firstname.lastname@example.org>, Douglas McIlroy <email@example.com> Subject: Re: [COFF] [TUHS] 386BSD released Date: Fri, 16 Jul 2021 12:14:43 +1000 [thread overview] Message-ID: <CAKr6gn1UOc5=K+Cghp3qUfjk6SBv1p3LVSF=TZ3=-a6tK6EVwQ@mail.gmail.com> (raw) In-Reply-To: <YPDn3XRqRQ4a2UKl@mit.edu> I was part of a discussion about a bug in the DECUS tape in Leeds uni, in '82-84 window. I was a very small part I might add, not the principal. I can't remember the package. It was probably trivia, like walking a specific SYS$SYSTEM value in a way which was dangerous or encoded assumptions about device:directory:user models in VMS. The feedback I got from this process was "thanks, we'll think about it" was closure, for those days. We'd been pretty specific about a fix. I got the sense the tape was an annual affair. And the likelihood of our "patch" being both accepted, and added to the next round of the tape was low-to-zero because everyone wanted "moar" and so people focussed on adding things, not fixing things. The exception here was compilers: people always want bugs fixed in a compiler. Or the NAG library, but both compilers (language spec) and NAG (strict maths formalisms about correctness) had policed mechanisms to accept user input, validate, run through a remorselessly tight compliance check, and emit, if it survived. A bug in the implementation of MUD for dec-10? ok, so the word "potato" is misspelled on one screen. Move on. On Fri, Jul 16, 2021 at 11:59 AM Theodore Y. Ts'o <firstname.lastname@example.org> wrote: > > On Thu, Jul 15, 2021 at 04:30:15PM -0400, Clem Cole wrote: > > > > Ted - that *is what* Doug pointed out!!! They did not create anything that > > was new. SHARED / DECUS / USENIX and the like were providing that exact > > same function starting in the late 1950s!!! Companies and Universities all > > pooled their resources to make things better and to get new and improved > > solutions. Sometimes they started with things that come from the > > original OEM. Also often they created their own technology and made it > > available to everyone. Sometime they combine both. And it was a > > 'bazaar where everyone had access and you chose to use it to not. Sounds > > pretty familiar, BTW. > > I remember looking at the DECUS program catalog for the PDP-8, and I > seem to recall that for the most part, individuals were sharing their > programs with others. In that way, it wasn't all that different from > say, CPM/UG, and HUG (Heathkit Users Group). But the thing is, for > the most part, it was a single author sharing individual programs, and > often changes were not accepted back. > > Consider the history of Bill Jolitz and 386BSD, and the collection of > patches that eventuallya became NetBSD and FreeBSD, which was formed > because they were frustrated that they couldn't get their patch sets > back into Jolitz's code base. Technology plays a part, in that it > enables the change. But it's not just about technology. There is > also a very strong social component. Even when you were richly > interconnected at the network level, this does not guarantee that will > be willing to be richly interconnected in terms of accepting patch > sets from people who you may not know across the Internet, into *your* > program, for which you are the author and high priest. > > I don't remember the exact date, but it would have been in the early > 90's, when at the time I was already contributing patches to Linux, > and where ftp and e-mail and applying patches via context diffs was > very much available. At that time, we were interested in getting > support for MIT Project Athena's Hesiod extenstions into the BIND > distributions (we had just been carrying patches against BIND for many > years). > > In order to get those patches integrated, Paul Vixie invited me to his > house in Redwood City, and so I flew from Boston to San Francisco, > carrying my Linux laptop with the BIND patches, and we got the patches > integrated into master BIND sources. Paul was a gracious host, and it > was lovely that I got to spend some time with him. But it was > interesting that my physical presence was needed, or at least highly > useful, in terms of getting those patches into BIND. Requiring > physical presence to get patches integrated.... doesn't scale. > > And so it wasn't a matter of technology, since the technology for > Linus, who didn't know me from Adam in 1991, to accept patches from me > implementing BSD Job Control, was certainly available when I was > working with Paul to get the Hesiod changes integrated into BIND. But > like with Jolitz and 386BSD, it's a mindset thing, not just technology. > > I also want to emphasize again, the question of business model is also > something which I think is different, and *important*. It's one thing > for Academics and Researchers to be willing to give changes away to > anyone who wants. It's quite another for a company to give away their > intellectual property in such a way that it can actually be used by > their competitors, either because that's the social convention, or > because it's enforced by the license. Was the practices we use today > for Linux built on the traditions of comp.sources.unix, and BSD, and > AT&T Research, and IBM making sources available for System/360, yadda, > yadda, yadda? Of course! I'm not denying that. > > But at the same time, to claim that nothing is new under the Sun, and > *all* of this had been done decades earlier, is also not the whole > story. And to call IBM releasing System/360, when they retained > control of the license, and wasn't accepting any changes back, and > *darned* well would have sued anyone trying to use that code on > non-IBM computers into a smoking crater, as "Open Source" can be > highly misleading, because that is not what most people associate with > the term "Open Source" today. > > And if we take a look at what AT&T Lawyers did with the Unix source > code, at some point, it most *defintely* was the antithesis of "Open > Source". Which would lead me to assert that Unix was never really > released under what today we would call, "Open Source". > > Cheers, > > - Ted _______________________________________________ COFF mailing list COFF@minnie.tuhs.org https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
next prev parent reply other threads:[~2021-07-18 6:33 UTC|newest] Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <email@example.com> [not found] ` <CAKH6PiVCjo3YnTZUVYOCDeffQ6POVwGAQA1QMR9UinkfGn+AmQ@mail.gmail.com> 2021-07-15 6:33 ` Michael Kjörling 2021-07-15 20:44 ` Derek Fawcus 2021-07-15 15:07 ` Clem Cole 2021-07-15 19:33 ` Theodore Y. Ts'o 2021-07-15 20:30 ` Clem Cole 2021-07-16 1:58 ` Theodore Y. Ts'o 2021-07-16 2:14 ` George Michaelson [this message] 2021-07-16 18:02 ` Grant Taylor via COFF 2021-07-17 4:09 ` Theodore Y. Ts'o 2021-07-17 6:30 ` [COFF] " Tom Ivar Helbekkmo via COFF 2021-07-17 12:37 ` Theodore Y. Ts'o 2021-07-17 13:30 ` Tom Ivar Helbekkmo via COFF 2021-07-18 3:29 ` [COFF] [TUHS] " Grant Taylor via COFF 2021-07-18 3:42 ` David Arnold 2021-07-18 4:01 ` Grant Taylor via COFF 2021-07-19 13:41 ` Theodore Y. Ts'o 2021-07-19 14:50 ` Clem Cole 2021-07-19 17:38 ` Theodore Y. Ts'o 2021-07-19 19:33 ` John P. Linderman 2021-07-19 20:21 ` Clem Cole 2021-07-20 1:05 ` Grant Taylor via COFF 2021-07-19 20:08 ` Clem Cole 2021-07-20 0:55 ` Theodore Y. Ts'o 2021-07-18 6:44 ` Andy Kosela 2021-07-16 16:11 ` Jonathan Corbet 2021-07-15 23:02 ` joe mcguckin [not found] <alpine.BSF.firstname.lastname@example.org> [not found] ` <213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost> [not found] ` <CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com> 2021-07-14 15:01 ` Clem Cole 2021-07-14 17:40 ` Theodore Y. Ts'o 2021-07-14 17:50 ` Larry McVoy 2021-07-14 18:28 ` Clem Cole 2021-07-14 20:03 ` John Cowan
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='CAKr6gn1UOc5=K+Cghp3qUfjk6SBv1p3LVSF=TZ3=-a6tK6EVwQ@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [COFF] [TUHS] 386BSD released' \ /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
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).