The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* Re: [TUHS] 386BSD released
@ 2021-07-15  2:21 Douglas McIlroy
  2021-07-15  2:41 ` Adam Thornton
  2021-07-15 15:07 ` Clem Cole
  0 siblings, 2 replies; 44+ messages in thread
From: Douglas McIlroy @ 2021-07-15  2:21 UTC (permalink / raw)
  To: TUHS main list

> Arguably ancient PDP-10 operating systems like ITS, WAITS, TENEX were
> somewhat "open" and "free", but it's not a clear cut case.

The open source movement was a revival of the old days of SHARE and other
user groups.

SAP, the SHARE assembly program for the IBM 704, was freely available--with
source code--to all members of the SHARE user group. I am not aware of any
restrictions on redistribution.

Other more specialized programs were also freely available through SHARE. In
particular, Fortran formatted IO was adopted directly from a SHARE program
written by Roy Nutt (who also wrote SAP and helped write Fortran I).

Bell Labs freely distributed the BESYS operating system for the IBM 704.
At the time (1958) no operating system was available from IBM.

IBM provided source code for the Fortran II compiler. In the
fashion of the time, I spent a memorable all-night session with
that code at hand, finding and fixing a bizarre bug (a computed GOTO
bombed if the number of branches was 74 mod 75) with a bizarre cause
(the code changed the index-register field in certain instructions on the
fly--inconsistently). And there was no operating system to help, because
BESYS swapped itself out to make room for the compiler.

Doug

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

* Re: [TUHS] 386BSD released
  2021-07-15  2:21 [TUHS] 386BSD released Douglas McIlroy
@ 2021-07-15  2:41 ` Adam Thornton
  2021-07-15 15:07 ` Clem Cole
  1 sibling, 0 replies; 44+ messages in thread
From: Adam Thornton @ 2021-07-15  2:41 UTC (permalink / raw)
  To: Douglas McIlroy, The Eunuchs Hysterical Society

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

"SHARE.  It's not an acronym.  It's what we do."

*Still* a bad-ass slogan after all these years.

Adam

On Wed, Jul 14, 2021 at 7:22 PM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

> > Arguably ancient PDP-10 operating systems like ITS, WAITS, TENEX were
> > somewhat "open" and "free", but it's not a clear cut case.
>
> The open source movement was a revival of the old days of SHARE and other
> user groups.
>
> SAP, the SHARE assembly program for the IBM 704, was freely available--with
> source code--to all members of the SHARE user group. I am not aware of any
> restrictions on redistribution.
>
> Other more specialized programs were also freely available through SHARE.
> In
> particular, Fortran formatted IO was adopted directly from a SHARE program
> written by Roy Nutt (who also wrote SAP and helped write Fortran I).
>
> Bell Labs freely distributed the BESYS operating system for the IBM 704.
> At the time (1958) no operating system was available from IBM.
>
> IBM provided source code for the Fortran II compiler. In the
> fashion of the time, I spent a memorable all-night session with
> that code at hand, finding and fixing a bizarre bug (a computed GOTO
> bombed if the number of branches was 74 mod 75) with a bizarre cause
> (the code changed the index-register field in certain instructions on the
> fly--inconsistently). And there was no operating system to help, because
> BESYS swapped itself out to make room for the compiler.
>
> Doug
>

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

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

* Re: [TUHS] 386BSD released
  2021-07-15  2:21 [TUHS] 386BSD released Douglas McIlroy
  2021-07-15  2:41 ` Adam Thornton
@ 2021-07-15 15:07 ` Clem Cole
  2021-07-15 19:33   ` [TUHS] [COFF] " Theodore Y. Ts'o
  1 sibling, 1 reply; 44+ messages in thread
From: Clem Cole @ 2021-07-15 15:07 UTC (permalink / raw)
  To: Douglas McIlroy; +Cc: Computer Old Farts Followers, TUHS main list

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

Thank you, Doug.

On Wed, Jul 14, 2021 at 10:22 PM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

> The open source movement was a revival of the old days of SHARE and other
> user groups.
>
Amen, my basic point, although I was also trying to pointing at that these
user groups got started b*ecause the vendors gave the sources to their
products out.*  We SHARED patches and features. DECUS started out the same
way.   For instance, many/most PDP-10 OS's used the DEC compilers and often
even found a way to run TOPS-10 binaries by emulating the UUOs.  The
IBM/360 world worked pretty much the same way.  My own experience was that
the compilers (e.g WATFIV-FTNG-ALGOLW-PL/1) and language interpreters
(APL-Snolbol) for the TSS and MTS had been 'ported' from the IBM-supplied
OS [my own first job was doing just that].

The same story was true for the PDP-8 with DOS-8/TSS-8 and the like. By the
time of the PDP-11, while some of the DEC source code was available (such
as the Fortran-IV for RT-11/RSX), since it took at PDP-10/BLISS to support
it, DEC had it its protection - so moving it/stealing it - would have been
harder.  By the time of the VAX, DEC was charging a lot of money of SW and
it was actually a revenue stream, so they keep a lot more locked up and
had started to do the same with PDP-10 world.

So, the available/unavailable source issue came when things started to get
closed up, which really started with the rise of the SW industry and making
revenue with the use of your SW.   OEMs and IVSs started to be a lot less
willing to reveal what they thought was their 'special sauce.'    Some/many
end-users started to balk.   RMS just took it to a new level - just look at
how he reacted to Symbolics being closed source :-)

The question that used to come up (and still does not an extent) is how are
the engineers and teams of people that developed the SW going to be
paid/renumerated for their work?   The RMS/GNU answer had been service
revenue [and living like a student in a rent-controlled APT in
Central Sq].  What has happened for most of the biggest FOSS projects, the
salaries are paid for firms like my own that pay developers to work on the
SW and most FOSS projects die when the developer/maintainer is unable to
continue (if not just gets bored).

In fact, [I can not say I personally know this - but have read internal
memos that make the claim], Intel pays for more Linux developers and now
LLVM developers than any firm.  What's interesting is that Intel does not
really directly sell its HW product to end-users.  We sell to others than
use our chips to make their products.   We have finally moved to the
support model for the compilers (I've personally been fighting that battle
for 15 years).

So back to my basic point ... while giving the *behavior* a name, the *idea
*of "Open Source" is really not anything new.  While it may be new in their
lifetime/experience, it is frankly at minimum a sad, if not outright
disingenuous, statement for the people to try to imply otherwise because
they are unwilling to look back into history and understand, much less
accept it as a fact.  Trying to rewrite history is just not pretty to
witness.  And I am pleased to see that a few folks (like Larry) that have
lived a little both times have tried to pass the torch with more complete
history.

Clem.


ᐧ

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

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

* Re: [TUHS] [COFF]  386BSD released
  2021-07-15 15:07 ` Clem Cole
@ 2021-07-15 19:33   ` Theodore Y. Ts'o
  2021-07-15 19:49     ` Adam Thornton
                       ` (2 more replies)
  0 siblings, 3 replies; 44+ messages in thread
From: Theodore Y. Ts'o @ 2021-07-15 19:33 UTC (permalink / raw)
  To: Clem Cole; +Cc: Computer Old Farts Followers, TUHS main list, Douglas McIlroy

On Thu, Jul 15, 2021 at 11:07:10AM -0400, Clem Cole wrote:
> In fact, [I can not say I personally know this - but have read internal
> memos that make the claim], Intel pays for more Linux developers and now
> LLVM developers than any firm.  What's interesting is that Intel does not
> really directly sell its HW product to end-users.  We sell to others than
> use our chips to make their products.   We have finally moved to the
> support model for the compilers (I've personally been fighting that battle
> for 15 years).

That claim is probably from the data collected from the Linux
Foundation, which publishes these stats every year or two.  The most
recent one is here:

https://www.linuxfoundation.org/wp-content/uploads/2020_kernel_history_report_082720.pdf

The top ten organizations responsible for commits from 2007 -- 2019:

(None)		11.95%
Intel		10.01%
Red Hat		 8.90%
(Unknown)	 4.09%
IBM		 3.79%
SuSE		 3.49%
Linaro		 3.17%
(Consultant)	 2.96%
Google		 2.79%
Samsung		 2.58%

"None" means no organizational affiliation (e.g., hobbyists, students,
etc.)  "Unknown" means the organization affiliation couldn't be
determined.

For more recent data, if you look at the commits for the 5.10 release
(end of 2020), the top ten list by organizations looks like this:

Huawei	     8.9%
Intel	     8.0%
(Unknown)    6.6%
(None)	     4.9%
Red Hat	     5.7%
Google	     5.2%
AMD	     4.3%
Linaro	     4.1%
Samsung	     3.5%
IBM	     3.2%

For the full list and more stats, see: https://lwn.net/Articles/839772/

> So back to my basic point ... while giving the *behavior* a name, the *idea
> *of "Open Source" is really not anything new.

I do think there is something which is radically new --- which is that
it's not a single company publishing all of the source code for a
particular OS, whether it's System/360 or the PDP-8 Disk Operating
System, or whatever.

In other words, it's the shared nature of the collaboration, which
partially solves the question of "who pays" --- the answer is, "lots
of companies, and they do so when it makes business sense for them to
do so".  Intel may have had the largest number of contributions to
Linux historically --- but that was still 10%, and it was eclipsed by
people with no organizational affliation, and in the 5.10 kernel
Huawei slightly edged out Intel with 8.9% vs 8.0% contributions.

I completely agree with you that one of the key questions is the
business case issue.  Not only who pays, but how do they justify the
software investment to the bean counters?  Of course, the "Stone Soup"
story predates computers, so this certainly isn't a new business
model.  And arguably the X Window Systems and the Open Software
Foundation also had a similar model where multiple companies
contributed to a common codebase, with perhaps mixed levels of
success.

The thing which Linux has managed to achieve, however, is the fact
that there is a large and diverse base of corporate contributions.
That to me is what makes the Linux model so interesting, and has been
a reason for its long-term sustainability.

Other companies may have been making their source code availble, but
the underlying business model behind their "source available" practices
was quite different.

Cheers,

					- Ted

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

* Re: [TUHS] [COFF] 386BSD released
  2021-07-15 19:33   ` [TUHS] [COFF] " Theodore Y. Ts'o
@ 2021-07-15 19:49     ` Adam Thornton
  2021-07-15 20:29       ` Andy Kosela
  2021-07-16  2:22       ` Theodore Y. Ts'o
  2021-07-15 20:30     ` Clem Cole
  2021-07-15 23:02     ` joe mcguckin
  2 siblings, 2 replies; 44+ messages in thread
From: Adam Thornton @ 2021-07-15 19:49 UTC (permalink / raw)
  To: Theodore Y. Ts'o, The Eunuchs Hysterical Society

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

The thing which Linux has managed to achieve, however, is the fact
> that there is a large and diverse base of corporate contributions.
> That to me is what makes the Linux model so interesting, and has been
> a reason for its long-term sustainability.
>
>
Although from a somewhat different perspective, it's also why the Linux
kernel syscall interface is so unruly, right?

You've got your...some number in the small dozens of common syscalls, which
are already present for the most part in v6 or v7.  These are the ones I,
at least, think of when I think of the Unix manual, section 2.

And then you've got all the other calls added in by (usually) this database
vendor or that storage vendor or the other display adapter vendor to make
their stuff work more efficiently.

And obviously there's a tradeoff there.  Elegance departs, and you've
probably introduced some security risk because these syscalls are not
nearly as well-exercised as the common ones, but on the other hand you have
these large companies paying to work on the kernel, and you have them
supporting their product on Linux systems because the system can be bent
into accommodating them more easily, and it will run better there than on
OSes where they don't get to introduce features that benefit their
products, which further drives adoption.

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

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

* Re: [TUHS] [COFF] 386BSD released
  2021-07-15 19:49     ` Adam Thornton
@ 2021-07-15 20:29       ` Andy Kosela
  2021-07-16  2:22       ` Theodore Y. Ts'o
  1 sibling, 0 replies; 44+ messages in thread
From: Andy Kosela @ 2021-07-15 20:29 UTC (permalink / raw)
  To: Adam Thornton; +Cc: The Eunuchs Hysterical Society

On 7/15/21, Adam Thornton <athornton@gmail.com> wrote:
> The thing which Linux has managed to achieve, however, is the fact
>> that there is a large and diverse base of corporate contributions.
>> That to me is what makes the Linux model so interesting, and has been
>> a reason for its long-term sustainability.
>>
>>
> Although from a somewhat different perspective, it's also why the Linux
> kernel syscall interface is so unruly, right?
>
> You've got your...some number in the small dozens of common syscalls, which
> are already present for the most part in v6 or v7.  These are the ones I,
> at least, think of when I think of the Unix manual, section 2.
>
> And then you've got all the other calls added in by (usually) this database
> vendor or that storage vendor or the other display adapter vendor to make
> their stuff work more efficiently.
>
> And obviously there's a tradeoff there.  Elegance departs, and you've
> probably introduced some security risk because these syscalls are not
> nearly as well-exercised as the common ones, but on the other hand you have
> these large companies paying to work on the kernel, and you have them
> supporting their product on Linux systems because the system can be bent
> into accommodating them more easily, and it will run better there than on
> OSes where they don't get to introduce features that benefit their
> products, which further drives adoption.

The last time I looked it was actually FreeBSD that had the most
system calls (more than 500).  Linux had more or less around the same
number as OpenBSD (more than 300).

UNIX V7 had around 50 -- this is still the golden standard, but
obviously a lot has changed since then...

--Andy

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

* Re: [TUHS] [COFF]  386BSD released
  2021-07-15 19:33   ` [TUHS] [COFF] " Theodore Y. Ts'o
  2021-07-15 19:49     ` Adam Thornton
@ 2021-07-15 20:30     ` Clem Cole
  2021-07-16  1:58       ` Theodore Y. Ts'o
  2021-07-15 23:02     ` joe mcguckin
  2 siblings, 1 reply; 44+ messages in thread
From: Clem Cole @ 2021-07-15 20:30 UTC (permalink / raw)
  To: Theodore Y. Ts'o
  Cc: Computer Old Farts Followers, TUHS main list, Douglas McIlroy

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

On Thu, Jul 15, 2021 at 3:33 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:

> > So back to my basic point ... while giving the *behavior* a name, the
> *idea
> > *of "Open Source" is really not anything new.
>
> I do think there is something which is radically new --- which is that
> it's not a single company publishing all of the source code for a
> particular OS, whether it's System/360 or the PDP-8 Disk Operating
> System, or whatever.


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.

What >>has<< changed (dramatically) was the *method* and *ability* to
*distribute* your work and/or the manner you *obtained* someone else's
efforts.  Today we download via the Web (much less ftp from a public area),
which is much more convenient than becoming a member of an organization and
having to obtain (typically for a small $50-$100 trape copying fee) a
9-track distribution tape.  But even the concept of 'free' is really not
new as I said.   Things like UCB's ILO used that model for a long time.
 MIT, CMU, Stanford, Univerity of Waterloo, Cambridge, et al, just made
their work to any interested parties.

But due to the new way of being *interconnected *and a *much better
distribution scheme* that indeed is a huge feature.  But please understand
'open source and collective sharing/working together is not a new thing
that just appeared with the Gnu project and was accelerated and taken to a
new level with the Linux work.

I personally blame esr's book for that beginning of the rewriting of
history/kicking the previous generations in the shins, as readers of it, or
worse readers of summations of it, miss the big picture instead of the
reality of standing on other shoulders.

I do want to give create for the cool and important things that have come.
I just want to make sure we don't forget the success of the modern world is
100% dependent on two important things: moore's law to make things more
economic and the hard work of a lot of people that came before (now and
before me for that matter).
ᐧ

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

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

* Re: [TUHS] [COFF]  386BSD released
  2021-07-15 19:33   ` [TUHS] [COFF] " Theodore Y. Ts'o
  2021-07-15 19:49     ` Adam Thornton
  2021-07-15 20:30     ` Clem Cole
@ 2021-07-15 23:02     ` joe mcguckin
  2 siblings, 0 replies; 44+ messages in thread
From: joe mcguckin @ 2021-07-15 23:02 UTC (permalink / raw)
  To: Theodore Y. Ts'o
  Cc: Computer Old Farts Followers, TUHS main list, Douglas McIlroy

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

I remember going to one of those cattle-call hiring events. I wanted to speak with the Intel compiler guy and when I got up to him, all he said 
was “Ganapathi”.

I actually knew who/what hw was talking about.

So, has Intel killed their own compiler toolset?

Joe McGuckin
ViaNet Communications

joe@via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



> On Jul 15, 2021, at 12:33 PM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
> 
> On Thu, Jul 15, 2021 at 11:07:10AM -0400, Clem Cole wrote:
>> In fact, [I can not say I personally know this - but have read internal
>> memos that make the claim], Intel pays for more Linux developers and now
>> LLVM developers than any firm.  What's interesting is that Intel does not
>> really directly sell its HW product to end-users.  We sell to others than
>> use our chips to make their products.   We have finally moved to the
>> support model for the compilers (I've personally been fighting that battle
>> for 15 years).
> 
> That claim is probably from the data collected from the Linux
> Foundation, which publishes these stats every year or two.  The most
> recent one is here:
> 
> https://www.linuxfoundation.org/wp-content/uploads/2020_kernel_history_report_082720.pdf
> 
> The top ten organizations responsible for commits from 2007 -- 2019:
> 
> (None)		11.95%
> Intel		10.01%
> Red Hat		 8.90%
> (Unknown)	 4.09%
> IBM		 3.79%
> SuSE		 3.49%
> Linaro		 3.17%
> (Consultant)	 2.96%
> Google		 2.79%
> Samsung		 2.58%
> 
> "None" means no organizational affiliation (e.g., hobbyists, students,
> etc.)  "Unknown" means the organization affiliation couldn't be
> determined.
> 
> For more recent data, if you look at the commits for the 5.10 release
> (end of 2020), the top ten list by organizations looks like this:
> 
> Huawei	     8.9%
> Intel	     8.0%
> (Unknown)    6.6%
> (None)	     4.9%
> Red Hat	     5.7%
> Google	     5.2%
> AMD	     4.3%
> Linaro	     4.1%
> Samsung	     3.5%
> IBM	     3.2%
> 
> For the full list and more stats, see: https://lwn.net/Articles/839772/
> 
>> So back to my basic point ... while giving the *behavior* a name, the *idea
>> *of "Open Source" is really not anything new.
> 
> I do think there is something which is radically new --- which is that
> it's not a single company publishing all of the source code for a
> particular OS, whether it's System/360 or the PDP-8 Disk Operating
> System, or whatever.
> 
> In other words, it's the shared nature of the collaboration, which
> partially solves the question of "who pays" --- the answer is, "lots
> of companies, and they do so when it makes business sense for them to
> do so".  Intel may have had the largest number of contributions to
> Linux historically --- but that was still 10%, and it was eclipsed by
> people with no organizational affliation, and in the 5.10 kernel
> Huawei slightly edged out Intel with 8.9% vs 8.0% contributions.
> 
> I completely agree with you that one of the key questions is the
> business case issue.  Not only who pays, but how do they justify the
> software investment to the bean counters?  Of course, the "Stone Soup"
> story predates computers, so this certainly isn't a new business
> model.  And arguably the X Window Systems and the Open Software
> Foundation also had a similar model where multiple companies
> contributed to a common codebase, with perhaps mixed levels of
> success.
> 
> The thing which Linux has managed to achieve, however, is the fact
> that there is a large and diverse base of corporate contributions.
> That to me is what makes the Linux model so interesting, and has been
> a reason for its long-term sustainability.
> 
> Other companies may have been making their source code availble, but
> the underlying business model behind their "source available" practices
> was quite different.
> 
> Cheers,
> 
> 					- Ted


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

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

* Re: [TUHS] [COFF]  386BSD released
  2021-07-15 20:30     ` Clem Cole
@ 2021-07-16  1:58       ` Theodore Y. Ts'o
  2021-07-16  2:14         ` George Michaelson
  0 siblings, 1 reply; 44+ messages in thread
From: Theodore Y. Ts'o @ 2021-07-16  1:58 UTC (permalink / raw)
  To: Clem Cole; +Cc: Computer Old Farts Followers, TUHS main list, Douglas McIlroy

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

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

* Re: [TUHS] [COFF] 386BSD released
  2021-07-16  1:58       ` Theodore Y. Ts'o
@ 2021-07-16  2:14         ` George Michaelson
  0 siblings, 0 replies; 44+ messages in thread
From: George Michaelson @ 2021-07-16  2:14 UTC (permalink / raw)
  To: Theodore Y. Ts'o
  Cc: Computer Old Farts Followers, TUHS main list, Douglas McIlroy

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 <tytso@mit.edu> 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

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

* Re: [TUHS] [COFF] 386BSD released
  2021-07-15 19:49     ` Adam Thornton
  2021-07-15 20:29       ` Andy Kosela
@ 2021-07-16  2:22       ` Theodore Y. Ts'o
  1 sibling, 0 replies; 44+ messages in thread
From: Theodore Y. Ts'o @ 2021-07-16  2:22 UTC (permalink / raw)
  To: Adam Thornton; +Cc: The Eunuchs Hysterical Society

On Thu, Jul 15, 2021 at 12:49:07PM -0700, Adam Thornton wrote:
> Although from a somewhat different perspective, it's also why the Linux
> kernel syscall interface is so unruly, right?
> 
> You've got your...some number in the small dozens of common syscalls, which
> are already present for the most part in v6 or v7.  These are the ones I,
> at least, think of when I think of the Unix manual, section 2.

Actually, a more reason why we have so many system calls is that there
is a strong belief that backwards compatibility is important.  So much
so that a Linux, or even Minix binary, from the early 1990's, will
still run on a modern Linux kernel today.  So that means we have
separate system calls for wait, wait3, wait4, etc.  Support for
openat(2), linkat(2), etc., which got added to Posix by way of
Solaris, need to be implemented as a separate system calls, since we
need to keep the original open(2) system calls.  Etc.

> And obviously there's a tradeoff there.  Elegance departs, and you've
> probably introduced some security risk because these syscalls are not
> nearly as well-exercised as the common ones, but on the other hand you have
> these large companies paying to work on the kernel, and you have them
> supporting their product on Linux systems because the system can be bent
> into accommodating them more easily, and it will run better there than on
> OSes where they don't get to introduce features that benefit their
> products, which further drives adoption.

In many cases, inside the kernel, system calls like wait(2) and
wait3(2) will be implemeanted in terms of wait4(2), the implementation
of open(2) and openat(2) share a common codepath, and so on.  So
although the *number* of system calls may look big, in many cases
there are shared code paths.  This is especially true for the system
calls that implement 64-bit support, where the old legacy 32-bit
system calls are just wrappers that call the 64-bit implementations of
those system calls.

There are also some architectures such as Alpha, where some of Linux's
system calls used the Ultrix system call numbering scheme, and other
Ultrix system calls were emulated, so that the Netscape browser, which
was provided in binary form only for Ultrix on Alpha, would run on
Linux Alpha.  Being able to run a subset of Ultrix binaries on Linux
Alpha was certainly a hack, but the ability to run a web browser
(there were no open source web browsers at that time) certainly drove
adoption for at least some users.

Was there perhaps some security risk in doing that?  Probably,
although people cared a lot less about that in the early 90's.  And
these days Linux support for architectures such as Alpha and HP's
PA-RISC are done only by folks who do for fun.  :-)

	    	      	       	      - Ted

P.S.  At one point Linux x86 could also run SCO Unix binaries.  Which
led to an amusing situation where MIT had purchased a site license for
a proprietary spreadsheet program that ran on SCO Unix, for use by
students who would be running Linux.  I worked with someone at that
company (who eventually became one of the founders of Red Hat) and he
gave me a custom application binary that checked for MIT's IP network
address prefix, which was how the site license enforcement was
implemented.

Turns out his development environment was Linux, cross-compiling to
create a SCO Unix binary, because the Linux development environment
was more developer friendly than SCO's.  And so here he was, building
a SCO Unix application on a Linux development machine, and then
handing it to me so that our students could run that SCO Unix
application on Linux systems at MIT.  The joys of syscall/OS
emulation.  :-)

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

* Re: [TUHS] 386BSD released
  2021-07-18 13:13                     ` arnold
@ 2021-07-18 13:23                       ` Richard Salz
  0 siblings, 0 replies; 44+ messages in thread
From: Richard Salz @ 2021-07-18 13:23 UTC (permalink / raw)
  To: arnold; +Cc: The Eunuchs Hysterical Society, Bakul Shah

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

> I think it was "my dog Biff..."  Wasn't that Heidi Stetner's dog or
> something? Apparently he used to bark whenever the mailman showed up,
> inspiring the BSD biff(1) command.
>

Yes, that's the dog's name, and that I also now remember hearing that
story!

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

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

* Re: [TUHS] 386BSD released
  2021-07-16 20:24                   ` Richard Salz
@ 2021-07-18 13:13                     ` arnold
  2021-07-18 13:23                       ` Richard Salz
  0 siblings, 1 reply; 44+ messages in thread
From: arnold @ 2021-07-18 13:13 UTC (permalink / raw)
  To: rich.salz, clemc; +Cc: tuhs, bakul

Richard Salz <rich.salz@gmail.com> wrote:

> Anyone remember the old mtXinu calendar with fake ads?I only remember one
> page, "oh no Spot(?) spilled the mbufs, Dad's favorite cereal."

I think it was "my dog Biff..."  Wasn't that Heidi Stetner's dog or
something? Apparently he used to bark whenever the mailman showed up,
inspiring the BSD biff(1) command.

I had that calendar, and kept it for many years. There was a lovely
picture of a shepherd boy trying to herd cats. I don't remember the
rest, other than that they were amusing.  I think I finally tossed
it though.

Arnold

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

* Re: [TUHS] 386BSD released
  2021-07-13 22:28 Dave Horsfall
  2021-07-14  7:54 ` Michael Kjörling
  2021-07-14 21:37 ` Bakul Shah
@ 2021-07-16 21:22 ` Dave Horsfall
  2 siblings, 0 replies; 44+ messages in thread
From: Dave Horsfall @ 2021-07-16 21:22 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Wed, 14 Jul 2021, Dave Horsfall wrote:

> In 1992, 386BSD is released by Lynne and William Jolitz, starting the 
> open source operating system movement (Linux didn't come along under 
> later).

Seems to have caused a "discussion", so...

     https://www.onthisday.com/day/july/14

``1992 386BSD is released by Lynne Jolitz and William Jolitz,
   starting the open source operating system revolution. Linus Torvalds
   release "Linux" soon afterwards''

If anything thinks this is incorrect then feel free to submit a correction;
I have more important things to do right now.

-- Dave

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

* Re: [TUHS] 386BSD released
  2021-07-16 20:17                 ` Clem Cole
@ 2021-07-16 20:24                   ` Richard Salz
  2021-07-18 13:13                     ` arnold
  0 siblings, 1 reply; 44+ messages in thread
From: Richard Salz @ 2021-07-16 20:24 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society, Bakul Shah

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

Anyone remember the old mtXinu calendar with fake ads?I only remember one
page, "oh no Spot(?) spilled the mbufs, Dad's favorite cereal."

On Fri, Jul 16, 2021, 4:19 PM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Fri, Jul 16, 2021 at 3:08 PM Kevin Bowling <kevin.bowling@kev009.com>
> wrote:
>
>> Yup was just going to say this is standard in the modern BSD network
>> drivers, looks like Clem says it's older.
>
> Absolutely -- I believe it was Rob's undergrad project at Brown that he
> brought to BBN.
>
> The first use, if I saw, was the 'portable IP/TCP' stack  BBN did for
> HP/3000 and a couple of other systems.  That code seems to have been lost.
> I have asked about it on the Internet history mailing list.  I had a copy
> of it one time, but sadly I don't think I still do.  IIRC The original
> PDP-11 IP implementation which ran on a couple of dedicated systems,
> whose names/function I frankly do not remember) was also based on a version
> of this code.  I think it ran something like RT-11 or DOS-11 and then
> started the IP code -- basically RTR style today.   Later it morphed into
> Rob's Vax BSD  4.1 specific stack,  which we ran at UCB on a couple of the
> systems using 3M Xerox board.  This latest until 4.1A and Joy's rewrite and
> I want to say we switched in Interlan 10M boards then.  We have a couple of
> the 3Com boards, but because of the lack of buffering, they were a bear to
> use and stopped as soon as we got the Interlan one.
>
>
> Anyway, all of these IP/TCP stacks used Rob's mbuf code.  Which was a
> blessing and a curse.  By writing his own, he avoids huge
> changes/integration into the memory system, but it also helped to make BSD
> such a mess under the covers because there were so many private memory
> managers between the network, the I/O systems etc...  As discussed
> previously on the TUHS list, the one thing Risner really did well had a
> uniform memory design.   Later BSD's moved to Mach and tried to clean this
> up a little, but the network code was by then so screwed into Rob's mbuf
> scheme, it stayed around a long time.  Werner -- what is the state of this
> these days in FreeBSD is it still there?
>
>
>
>
>> There are recent optimizations to help the CPU with prefetch, and some
>> ideas around vectors of mbufs.  What's remarkable is the mbuf design
>> scales to
>> 200gbps in practice, it must feel great to design something like that so
>> long ago :)
>>
> Well, ask Rob :-)  I've lost track of him since Stellar, and I think he I
> heard he left high tech but frankly don't know.
>
> Clem
> ᐧ
>

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

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

* Re: [TUHS] 386BSD released
  2021-07-16 19:07               ` Kevin Bowling
@ 2021-07-16 20:17                 ` Clem Cole
  2021-07-16 20:24                   ` Richard Salz
  0 siblings, 1 reply; 44+ messages in thread
From: Clem Cole @ 2021-07-16 20:17 UTC (permalink / raw)
  To: Kevin Bowling; +Cc: The Eunuchs Hysterical Society, Bakul Shah

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

On Fri, Jul 16, 2021 at 3:08 PM Kevin Bowling <kevin.bowling@kev009.com>
wrote:

> Yup was just going to say this is standard in the modern BSD network
> drivers, looks like Clem says it's older.

Absolutely -- I believe it was Rob's undergrad project at Brown that he
brought to BBN.

The first use, if I saw, was the 'portable IP/TCP' stack  BBN did for
HP/3000 and a couple of other systems.  That code seems to have been lost.
I have asked about it on the Internet history mailing list.  I had a copy
of it one time, but sadly I don't think I still do.  IIRC The original
PDP-11 IP implementation which ran on a couple of dedicated systems,
whose names/function I frankly do not remember) was also based on a version
of this code.  I think it ran something like RT-11 or DOS-11 and then
started the IP code -- basically RTR style today.   Later it morphed into
Rob's Vax BSD  4.1 specific stack,  which we ran at UCB on a couple of the
systems using 3M Xerox board.  This latest until 4.1A and Joy's rewrite and
I want to say we switched in Interlan 10M boards then.  We have a couple of
the 3Com boards, but because of the lack of buffering, they were a bear to
use and stopped as soon as we got the Interlan one.


Anyway, all of these IP/TCP stacks used Rob's mbuf code.  Which was a
blessing and a curse.  By writing his own, he avoids huge
changes/integration into the memory system, but it also helped to make BSD
such a mess under the covers because there were so many private memory
managers between the network, the I/O systems etc...  As discussed
previously on the TUHS list, the one thing Risner really did well had a
uniform memory design.   Later BSD's moved to Mach and tried to clean this
up a little, but the network code was by then so screwed into Rob's mbuf
scheme, it stayed around a long time.  Werner -- what is the state of this
these days in FreeBSD is it still there?




> There are recent optimizations to help the CPU with prefetch, and some
> ideas around vectors of mbufs.  What's remarkable is the mbuf design
> scales to
> 200gbps in practice, it must feel great to design something like that so
> long ago :)
>
Well, ask Rob :-)  I've lost track of him since Stellar, and I think he I
heard he left high tech but frankly don't know.

Clem
ᐧ

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

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

* Re: [TUHS] 386BSD released
  2021-07-16 13:56             ` Larry McVoy
  2021-07-16 14:40               ` Clem Cole
  2021-07-16 16:11               ` Bakul Shah
@ 2021-07-16 19:07               ` Kevin Bowling
  2021-07-16 20:17                 ` Clem Cole
  2 siblings, 1 reply; 44+ messages in thread
From: Kevin Bowling @ 2021-07-16 19:07 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society, Bakul Shah

On Fri, Jul 16, 2021 at 6:57 AM Larry McVoy <lm@mcvoy.com> wrote:
>
> On Fri, Jul 16, 2021 at 09:00:58AM -0400, Theodore Y. Ts'o wrote:
> > The trick that I used was two have two "flip buffers" which were
> > dedicated for each serial port.  One buffer would be filled by the
> > interrupt handler, while the other would be buffer would be processed
> > by the bottom half (read: software interrupt) handler.  When the
> > bottom half handler had emptied one buffer, it would check to see if
> > there were any characters in the other buffer, and if so, flip the two
> > and process the characters in that buffer.
>
> I'm pretty sure SGI used a similar approach for networking packets.

Yup was just going to say this is standard in the modern BSD network
drivers, looks like Clem says it's older.  There are recent
optimizations to help the CPU with prefetch, and some ideas around
vectors of mbufs.  What's remarkable is the mbuf design scales to
200gbps in practice, it must feel great to design something like that
so long ago :)

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

* Re: [TUHS] 386BSD released
@ 2021-07-16 17:30 Nelson H. F. Beebe
  0 siblings, 0 replies; 44+ messages in thread
From: Nelson H. F. Beebe @ 2021-07-16 17:30 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

List members under this subject line have contributed reminders of
older efforts in the sharing of software, predating Linux, the Free
Software Foundation, the GNU Project, and the BSD Unix family.

Starting at the string "begin historical remarks" in the preamble
comments of

	http://www.math.utah.edu/pub/tex/bib/gnu.bib
	http://www.math.utah.edu/pub/tex/bib/gnu.html

I record things that I've encountered over decades in computing, going
back to Charles Babbage in 1830 and Joseph Henry in 1849, jumping to
IBM SHARE in 1955, and onward.

As usual in our bibliography archives, *.html files look similar on
screen to *.bib files, but have live hyperlinks.

Comments, corrections, improvements, etc. on that history are welcome.

Babbage's own works are covered at

	http://www.math.utah.edu/pub/bibnet/authors/b/babbage-charles.bib
	http://www.math.utah.edu/pub/bibnet/authors/b/babbage-charles.html

and those of his collaborator at

	http://www.math.utah.edu/pub/bibnet/authors/l/lovelace-ada-augusta.bib
	http://www.math.utah.edu/pub/bibnet/authors/l/lovelace-ada-augusta.html

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

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

* Re: [TUHS] 386BSD released
  2021-07-16 13:56             ` Larry McVoy
  2021-07-16 14:40               ` Clem Cole
@ 2021-07-16 16:11               ` Bakul Shah
  2021-07-16 19:07               ` Kevin Bowling
  2 siblings, 0 replies; 44+ messages in thread
From: Bakul Shah @ 2021-07-16 16:11 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

On Jul 16, 2021, at 6:56 AM, Larry McVoy <lm@mcvoy.com> wrote:
> 
> On Fri, Jul 16, 2021 at 09:00:58AM -0400, Theodore Y. Ts'o wrote:
>> The trick that I used was two have two "flip buffers" which were
>> dedicated for each serial port.  One buffer would be filled by the
>> interrupt handler, while the other would be buffer would be processed
>> by the bottom half (read: software interrupt) handler.  When the
>> bottom half handler had emptied one buffer, it would check to see if
>> there were any characters in the other buffer, and if so, flip the two
>> and process the characters in that buffer.  
> 
> I'm pretty sure SGI used a similar approach for networking packets.

This is somewhat h/w dependent. Ideally you want the h/w to
do some buffering for streaming at full speed so that you
don't need to take a per char or per packet interrupt. Hence
NS16550 which used a 16 char FIFO. AMD LANCE used a ring of
2^N buffer descriptors. Intel 82586 used a linked list -
don't recall if you had to make it a circular buffer. The
early 3COM controller didn't buffer more than a packet and
you had to copy it. As a contractor I did a couple of network
drivers for 3rd party hardware for SGI in late '80s & early
'90s.  I don't recall any details now but in both cases the
h/w did buffer up a bunch. Once things are handed to s/w, you
have a lot more flexibility. Though I never liked the idea of
splitting a packet up in multiple mbufs!

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

* Re: [TUHS] 386BSD released
  2021-07-16 14:40               ` Clem Cole
@ 2021-07-16 15:44                 ` Theodore Y. Ts'o
  0 siblings, 0 replies; 44+ messages in thread
From: Theodore Y. Ts'o @ 2021-07-16 15:44 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society, Bakul Shah

On Fri, Jul 16, 2021 at 10:40:56AM -0400, Clem Cole wrote:
> 
> A huge difference, as Ted I'm sure knows, is that you tended to have many
> more serial lines than network interfaces.  I suspect Rob's scheme
> would have sucked trying to support traditional single-byte serial
> interfaces or really just use too much memory to be practical.

Network interfaces tend to be much faster than serial lines; at least
an order of magnitude.  And with network interfaces you care about the
packet boundaries, and you want to process each packet separately.  So
that makes things a lot harder than with serial interfaces.

With serial ports, 8k per serial port is plenty (2 x 2k flip buffers,
plus a 4k tty buffer between the mid-layer and userspace) for the
receive path.  On the PDP-11, memory was much more constrained, so the
clist with each cblock storing 6 characters at a time in a linked list
was probably necessary.  But even in the early days of the 386, you
could afford to make a different memory/performance tradeoff.

							- Ted

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

* Re: [TUHS] 386BSD released
  2021-07-16 13:56             ` Larry McVoy
@ 2021-07-16 14:40               ` Clem Cole
  2021-07-16 15:44                 ` Theodore Y. Ts'o
  2021-07-16 16:11               ` Bakul Shah
  2021-07-16 19:07               ` Kevin Bowling
  2 siblings, 1 reply; 44+ messages in thread
From: Clem Cole @ 2021-07-16 14:40 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society, Bakul Shah

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

On Fri, Jul 16, 2021 at 9:57 AM Larry McVoy <lm@mcvoy.com> wrote:

> I'm pretty sure SGI used a similar approach for networking packets.
>

Yeah, it was pretty standard for networking interfaces.  I think I first
saw it I'm the MIT Chaos driver maybe?  In many ways,  Gurwitz's whole mbuf
memory scheme for the ethernet controllers and the whole IP stack that
lives on in BSD is based on the idea.  Rob used a number of different size
buffers, not just the two, but the idea is the same, never copy anything if
we can avoid it.   Play pointer games in the top, bottom, and middle parts
of the driver/stack.

A huge difference, as Ted I'm sure knows, is that you tended to have many
more serial lines than network interfaces.  I suspect Rob's scheme
would have sucked trying to support traditional single-byte serial
interfaces or really just use too much memory to be practical.
ᐧ

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

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

* Re: [TUHS] 386BSD released
  2021-07-16 13:00           ` Theodore Y. Ts'o
@ 2021-07-16 13:56             ` Larry McVoy
  2021-07-16 14:40               ` Clem Cole
                                 ` (2 more replies)
  0 siblings, 3 replies; 44+ messages in thread
From: Larry McVoy @ 2021-07-16 13:56 UTC (permalink / raw)
  To: Theodore Y. Ts'o; +Cc: The Eunuchs Hysterical Society, Bakul Shah

On Fri, Jul 16, 2021 at 09:00:58AM -0400, Theodore Y. Ts'o wrote:
> The trick that I used was two have two "flip buffers" which were
> dedicated for each serial port.  One buffer would be filled by the
> interrupt handler, while the other would be buffer would be processed
> by the bottom half (read: software interrupt) handler.  When the
> bottom half handler had emptied one buffer, it would check to see if
> there were any characters in the other buffer, and if so, flip the two
> and process the characters in that buffer.  

I'm pretty sure SGI used a similar approach for networking packets.

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

* Re: [TUHS] 386BSD released
  2021-07-16  5:51         ` Bakul Shah
@ 2021-07-16 13:00           ` Theodore Y. Ts'o
  2021-07-16 13:56             ` Larry McVoy
  0 siblings, 1 reply; 44+ messages in thread
From: Theodore Y. Ts'o @ 2021-07-16 13:00 UTC (permalink / raw)
  To: Bakul Shah; +Cc: The Eunuchs Hysterical Society

On Thu, Jul 15, 2021 at 10:51:11PM -0700, Bakul Shah wrote:
> 
> Dave Yost wrote the serial driver for our 4 port serial card @ Fortune
> (1981-82).  Later chips like NS16550 had 16 char on chip buffers but we
> back then we used a Moto SIO chip that had only one char buffer.  IIRC,
> he used two tricks. One was "partially evaluated" xmit/recv handlers so
> that each port got its own xmit/recv functions, with hand-crafted
> instructions (in hex, no less!) just right for a given port and all the
> interry t handler . The  do was transfer a char from/to the buffer it
> (lready knew about. The other was he increased the cblock size from 8 to 128
> (what a clist points to). He says he described this design to dmr who said
> why not?!  With this design Yost's code was able to handle 4 full-duplex
> 9600 baud streams at full-speed. Not bad for a 5.6Mhz clock machine!

The trick that I used was two have two "flip buffers" which were
dedicated for each serial port.  One buffer would be filled by the
interrupt handler, while the other would be buffer would be processed
by the bottom half (read: software interrupt) handler.  When the
bottom half handler had emptied one buffer, it would check to see if
there were any characters in the other buffer, and if so, flip the two
and process the characters in that buffer.  Exclusion was handled by a
combination of disabling serial interrupts and using a spinlock (which
was held just long enough to flip the pointers to the two flip
buffers).

With this scheme I could handle multiple pairs of 115200 baud streams
at full rates before the 40 MHz CPU was saturated.  No memory
allocation is required on the hot paths, and the amount of processing
that is done in the hardware interrupt context is the absolute
minimum.

I also added a bit test against 32-byte bitarray to determine whether
a character could be handled via the fast path or require special
handling (in case it was a ^C, ^U, ^S, etc.) but that was important
only for cooked mode; it wasn't needed for raw mode.  I suspect this
hack would become less or even not helpful as Intel processors became
more Spectre- and Meltdown-susceptible, but for the 386, it was a win.  :-)

     	      	  			    	- Ted

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

* Re: [TUHS] 386BSD released
  2021-07-16  4:25       ` Theodore Y. Ts'o
@ 2021-07-16  5:51         ` Bakul Shah
  2021-07-16 13:00           ` Theodore Y. Ts'o
  0 siblings, 1 reply; 44+ messages in thread
From: Bakul Shah @ 2021-07-16  5:51 UTC (permalink / raw)
  To: Theodore Y. Ts'o; +Cc: The Eunuchs Hysterical Society

On Jul 15, 2021, at 9:25 PM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
> 
> I remember a friendly rivalry that I had with Bruce D. Evans in
> Australia, who was working on the serial driver for FreeBSD, where we
> would exchange tips and techniques for making the serial driver on our
> respective OS's more CPU efficient.  (The metric was to see who could
> most reduce the system overhead of the serial interrupt and tty layers
> when running a C-Kermit file transfer over a pair of RS-232 ports
> connected via a loopback cable.)  It was a lot of fun, and we both
> gained a lot from the exchange of ideas, but finally, I came up with
> an idea (flip buffers) that really reduced Linux's serial/tty
> overhead, but which Bruce couldn't match in FreeBSD, because the
> FreeBSD core team thought that clists were handed down from Mount
> Olympus by the Gods of BSD, and making that kind of change in the tty
> layer was tantamount to heresy.  Heh.

Dave Yost wrote the serial driver for our 4 port serial card @ Fortune
(1981-82).  Later chips like NS16550 had 16 char on chip buffers but we
back then we used a Moto SIO chip that had only one char buffer.  IIRC,
he used two tricks. One was "partially evaluated" xmit/recv handlers so
that each port got its own xmit/recv functions, with hand-crafted
instructions (in hex, no less!) just right for a given port and all the
interry t handler . The  do was transfer a char from/to the buffer it
(lready knew about. The other was he increased the cblock size from 8 to 128
(what a clist points to). He says he described this design to dmr who said
why not?!  With this design Yost's code was able to handle 4 full-duplex
9600 baud streams at full-speed. Not bad for a 5.6Mhz clock machine!


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

* Re: [TUHS] 386BSD released
  2021-07-16  2:33     ` risner
@ 2021-07-16  4:25       ` Theodore Y. Ts'o
  2021-07-16  5:51         ` Bakul Shah
  0 siblings, 1 reply; 44+ messages in thread
From: Theodore Y. Ts'o @ 2021-07-16  4:25 UTC (permalink / raw)
  To: risner; +Cc: The Eunuchs Hysterical Society

On Thu, Jul 15, 2021 at 10:33:52PM -0400, risner@stdio.com wrote:
> 
> I have repetively seen discussion suggesting Linux was available first, but
> having directly worked for a university at the time installing SunOS, AT&T
> SVR3, and other old OS’s, we welcomed the concept of switching from AT&T
> SVR3 on 386 machines to 386BSD. We’d probably have welcomed Linux if anyone
> in the department knew about it.

To be fair, Linux in 1991 was a very primitive affair; no TCP/IP, no X
Windows.  We had C-Kermit, and we had emacs, and we had basic shell
utilities and a compiler.  But not much else.  So I doubt it would
have been a good replacement for SVR3.

The big difference was that Linus accepted patches, and turned around
new releases *quickly* while Jolitz apparently sat on patches until
the NetBSD and FreeBSD people finally lost patience and released a
fork with their patch sets in 1993.  So while Linux in 1992 was
probably behind 386BSD from a feature perspective, its development
velocity was much faster.

I remember a friendly rivalry that I had with Bruce D. Evans in
Australia, who was working on the serial driver for FreeBSD, where we
would exchange tips and techniques for making the serial driver on our
respective OS's more CPU efficient.  (The metric was to see who could
most reduce the system overhead of the serial interrupt and tty layers
when running a C-Kermit file transfer over a pair of RS-232 ports
connected via a loopback cable.)  It was a lot of fun, and we both
gained a lot from the exchange of ideas, but finally, I came up with
an idea (flip buffers) that really reduced Linux's serial/tty
overhead, but which Bruce couldn't match in FreeBSD, because the
FreeBSD core team thought that clists were handed down from Mount
Olympus by the Gods of BSD, and making that kind of change in the tty
layer was tantamount to heresy.  Heh.

						- Ted

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

* Re: [TUHS] 386BSD released
  2021-07-16  1:35   ` Dave Horsfall
@ 2021-07-16  2:33     ` risner
  2021-07-16  4:25       ` Theodore Y. Ts'o
  0 siblings, 1 reply; 44+ messages in thread
From: risner @ 2021-07-16  2:33 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

I was running 386BSD 0.0 on a 386 40 mhz machine in April 1992 with 32 
mb of ram.
There was much instability in the OS with more than 8 gb of ram and I 
mailed 32 mb of extra to the Jolitz late summer to the fall.
I never heard about Linux until much later in 1993.

There used to be a post on usenet news annoucing the relase with the 
FTP, but the best I could google was this FAQ confirming release in 
1992.
https://groups.google.com/g/comp.os.386bsd.announce/c/PGltboD6rq4

I have repetively seen discussion suggesting Linux was available first, 
but having directly worked for a university at the time installing 
SunOS, AT&T SVR3, and other old OS’s, we welcomed the concept of 
switching from AT&T SVR3 on 386 machines to 386BSD. We’d probably have 
welcomed Linux if anyone in the department knew about it.

James Risner

On 15 Jul 2021, at 21:35, Dave Horsfall wrote:

> On Wed, 14 Jul 2021, Michael Kjörling wrote:
>
>>> In 1992, 386BSD is released by Lynne and William Jolitz, starting 
>>> the open source operating system movement (Linux didn't come along 
>>> under later).
>>
>> Are you sure? Wikipedia claims that it happened the other way around; 
>> that the Linux kernel initial release was 0.02 on 5 Oct 1991, while 
>> the 386BSD initial release was 0.0 on 12 March 1992.
>
> Could be; I got that news from one of those daily history sites (I 
> don't always trust Wikipedia).
>
>> It seems that work on 386BSD began earlier than work on Linux, but 
>> that the initial release of Linux was earlier than the initial 
>> release of 386BSD.
>
> That could be the source of the confusion.
>
> -- Dave

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

* Re: [TUHS] 386BSD released
  2021-07-14  7:54 ` Michael Kjörling
  2021-07-14  8:19   ` Angus Robinson
  2021-07-14 11:49   ` Andy Kosela
@ 2021-07-16  1:35   ` Dave Horsfall
  2021-07-16  2:33     ` risner
  2 siblings, 1 reply; 44+ messages in thread
From: Dave Horsfall @ 2021-07-16  1:35 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

On Wed, 14 Jul 2021, Michael Kjörling wrote:

>> In 1992, 386BSD is released by Lynne and William Jolitz, starting the 
>> open source operating system movement (Linux didn't come along under 
>> later).
>
> Are you sure? Wikipedia claims that it happened the other way around; 
> that the Linux kernel initial release was 0.02 on 5 Oct 1991, while the 
> 386BSD initial release was 0.0 on 12 March 1992.

Could be; I got that news from one of those daily history sites (I don't 
always trust Wikipedia).

> It seems that work on 386BSD began earlier than work on Linux, but that 
> the initial release of Linux was earlier than the initial release of 
> 386BSD.

That could be the source of the confusion.

-- Dave

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

* Re: [TUHS] 386BSD released
  2021-07-13 22:28 Dave Horsfall
  2021-07-14  7:54 ` Michael Kjörling
@ 2021-07-14 21:37 ` Bakul Shah
  2021-07-16 21:22 ` Dave Horsfall
  2 siblings, 0 replies; 44+ messages in thread
From: Bakul Shah @ 2021-07-14 21:37 UTC (permalink / raw)
  To: tuhs

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

I believe the following can count as an open source operating system (though this won’t satisfy the latter day purists). From Per Brinch-Hansen’s “Monitors and Concurrent Pascal: a Personal History” (1993):
    “At Caltech we prepared a distribution tape with the source text and portable code of the Solo system, including the Concurrent and Sequential Pascal compilers. The system reports were supplemented by implementation notes (Brinch Hansen 1976b).
    By the spring of 1976 we had distributed the system to 75 companies and 100 universities in 21 countries: Australia, Austria, Belgium, Canada, Denmark, Finland, France, Germany, Great Britain, Holland, India, Ireland, Italy, Japan, Norway, South Africa, the Soviet Union, Spain, Sweden, Switzerland, and the United States.”

This retrospective paper is worth reading in this age where the quest of higher and higher performance has produced super fast but very complicated and insecure machines where even synchronization has become a tricky affair (see for example the recent three articles by Russ Cox on his research.swtch.com site).

Can’t resist quoting Charles Hayden’s (Solocomment from the paper:
    “What was remarkable about [Concurrent Pascal] is that one could write experimental operating systems on a virtual machine without having to resort to machine registers, assembly language, etc. The development environment provided a way to do operating systems in a controlled way, on the “bare hardware” of a much nicer machine than any real computer. . .
    I think the significance of the system was . . . that one could provide a protected environment for concurrent programming—a high-level language environment which could maintain the illusion that there was no “machine” level. It was remarkable that through compile time restrictions and virtual machine error checking, that you could understand the program behavior by looking at the Pascal, not at the machine’s registers and memory. It was remarkable that the machine could retain its integrity while programs were being developed, without hardware memory protection.”

Nowadays writing an os kernel is considered quite a major effort. IMHO there has been nothing new in this area from a programming perspective since the ‘70s and no guidance for h/w design which has become increasingly more complex and “magic” (as per Artur C Clarke’s definition).

http://brinch-hansen.net/papers/1993a.pdf

> On Jul 13, 2021, at 3:35 PM, Dave Horsfall <dave@horsfall.org> wrote:
> 
> In 1992, 386BSD is released by Lynne and William Jolitz, starting the open source operating system movement (Linux didn't come along under later).
> 
> -- Dave

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

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

* Re: [TUHS] 386BSD released
  2021-07-14 17:21         ` Lyndon Nerenberg (VE7TFX/VE6BBM)
@ 2021-07-14 17:32           ` Richard Salz
  0 siblings, 0 replies; 44+ messages in thread
From: Richard Salz @ 2021-07-14 17:32 UTC (permalink / raw)
  To: Lyndon Nerenberg (VE7TFX/VE6BBM); +Cc: The Eunuchs Hysterical Society

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

> IBM was (inadvertantly) giving away the source to a few of its System/360
> OSes in the 1960s ...
>

It was not inadvertent.  It was common practice to give access to the
source since the money was in the hardware.  Gates showed otherwise.

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

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

* Re: [TUHS] 386BSD released
  2021-07-14 10:09       ` Tom Ivar Helbekkmo via TUHS
  2021-07-14 10:39         ` arnold
@ 2021-07-14 17:21         ` Lyndon Nerenberg (VE7TFX/VE6BBM)
  2021-07-14 17:32           ` Richard Salz
  1 sibling, 1 reply; 44+ messages in thread
From: Lyndon Nerenberg (VE7TFX/VE6BBM) @ 2021-07-14 17:21 UTC (permalink / raw)
  To: Tom Ivar Helbekkmo; +Cc: TUHS

> Ditto MINIX, of course, which was released, along with the book, in 1987.

IBM was (inadvertantly) giving away the source to a few of its System/360
OSes in the 1960s ...

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

* Re: [TUHS] 386BSD released
  2021-07-14 11:49   ` Andy Kosela
@ 2021-07-14 15:48     ` Theodore Y. Ts'o
  0 siblings, 0 replies; 44+ messages in thread
From: Theodore Y. Ts'o @ 2021-07-14 15:48 UTC (permalink / raw)
  To: Andy Kosela; +Cc: tuhs

On Wed, Jul 14, 2021 at 01:49:06PM +0200, Andy Kosela wrote:
> 
> I consider the birth of Linux to be August 25th 1991, when Linus
> announced it on comp.os.minix.  If he had access to 386BSD in 1991
> then probably he would never have started the Linux project -- that's
> his words.

I personally got started with Linux in September 1992, with one my
first projects being setting up the first US-based ftp site for Linux
--- tsx-11.mit.edu, which was a Decstation 3100 in my office ---
because at the time Finland was behind a super-slow trans-atlantic
link.  One of my other first initial was implementing BSD Job Control
from the POSIX spec, and improving the performance of the serial
driver, since at the time my 40 MHz 386 with 16 megs of memory was at
home, and the connection to the outside world was via modem.  (Or
hauling around dozens of 1.44M floppy disks from work.  :-)

I have heard stories that 386BSD was being demo'ed at various Usenix
conferences in 1990 and early 1991, but as far as I know it was never
publically released until 1992.  The Dr. Dobbs articles documenting
the porting process started in January 1991, so certainly Jolitz was
working on it by then.  However, 386BSD was largely developed behind
closed doors, whereas Linus was accepting patches and turning around
new releases every few weeks (and sometimes sooner).

Cheers,

						- Ted

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

* Re: [TUHS] 386BSD released
  2021-07-14 14:54           ` Warner Losh
  2021-07-14 15:06             ` Richard Salz
@ 2021-07-14 15:37             ` Steve Nickolas
  1 sibling, 0 replies; 44+ messages in thread
From: Steve Nickolas @ 2021-07-14 15:37 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

On Wed, 14 Jul 2021, Warner Losh wrote:

> The X10R3 license sure looks like a standard MIT license. The other license
> statements that were included also read very much like open source, or
> at least a strong intention of being open source, absent any drafting flaws.
>
> Copyright 1985 by the Massachusetts Institute of Technology
>
> Permission to use, copy, modify, and distribute this
> software and its documentation for any purpose and without
> fee is hereby granted, provided that the above copyright
> notice appear in all copies and that both that copyright
> notice and this permission notice appear in supporting
> documentation, and that the name of M.I.T. not be used in
> advertising or publicity pertaining to distribution of the
> software without specific, written prior permission.
> M.I.T. makes no representations about the suitability of
> this software for any purpose.  It is provided "as is"
> without express or implied warranty.
>
> This software is not subject to any license of the American
> Telephone and Telegraph Company or of the Regents of the
> University of California.

Ironically...that's closer to a "3-clause BSD" license.

-uso.

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

* Re: [TUHS] 386BSD released
  2021-07-14 14:54           ` Warner Losh
@ 2021-07-14 15:06             ` Richard Salz
  2021-07-14 15:37             ` Steve Nickolas
  1 sibling, 0 replies; 44+ messages in thread
From: Richard Salz @ 2021-07-14 15:06 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

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

History of the MIT license first used for PC/IP in 1984 and then for X
Windows (read the link, fascinating "influence" was so important and the
benefits MIT got from that):
https://web.mit.edu/Saltzer/www/publications/MITLicense.pdf

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

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

* Re: [TUHS] 386BSD released
  2021-07-14  8:19   ` Angus Robinson
  2021-07-14  8:32     ` Michael Kjörling
@ 2021-07-14 15:01     ` Clem Cole
  1 sibling, 0 replies; 44+ messages in thread
From: Clem Cole @ 2021-07-14 15:01 UTC (permalink / raw)
  To: Computer Old Farts Followers; +Cc: The Eunuchs Hysterical Society

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

Sigh ... Warren I am going to ask for your indulgence once here on TUHS as
I try to get any *new* discussion moved to COFF, but I guess it's time to
renew this history as enough people have joined the list since the last
time this was all discussed ...  I'll do this once -- please take any other
discussion off this list.  It has been argued too many times.   Many of the
actors in this drama are part of the list.  Sadly we have lost a few,
sometimes because of the silliness of the argument/trying to give people
credit or not/person preferences, etc.

If you want to comment, please go back and read both the TUHS and COFF
archives and I suspect your point may have already been made.   *If you
really do have something new, please move to COFF.*

On Wed, Jul 14, 2021 at 4:21 AM Angus Robinson <angus@fairhaven.za.net>
wrote:

> Looking at a few online sources, Linus actually said when "386BSD came
> out, Linux was already in a usable state, that I never really thought about
> switching. If 386BSD had been available when I started on Linux, Linux
> would probably never had happened".
>
A number of us, such as Larry and I have discussed this a bunch both online
and in person.   What would become 386BSD was actually available as early
as 1988, but you needed to know the public FTP address of where to get it
at UCB (which the UCB licensees had access to that FTP server).  Bostic was
still working on what would become the 'NET' release, but this tarball
offered a bootable system and did have things in it that later AT&T would
require UCB to remove.  In fact, this system would have X10 ported to it
and was a reasonably complete 'distro' in today's terms.

By formal definition, the tarball and the rest of UNIX from Research is and
always has been, '*Open Source*' in the sources were available.  *But they
were licensed*.  This was fairly typical of much early software BTW.  The
binary nature only came about with the minicomputers.

The tarball in question was fairly easy to find in the wild but to use the
sources as a system, you technically needed an AT&T license.  An
practically you needed access to a BSD box to rebuild them, which took a
license - although by then SunOS was probably close enough - although I do
not know anyone that tried it.

The sources in the tarball were not '*Free and Open Source*' -- which
becomes the crux of the issue.  [Sadly the OSS folks have confused this
over the years and that important detail is lost].   Many people, such as
myself, when the AT&T suite began got worried and started hacking on  Linux
at that point as the not nearly as mature but sort of works version without
networking or graphics had appeared [386BSD had both and a real installer -
more in a minute]

FWIW: Linus could have had access to the BSD for a 386 tarball if we had
asked in the right place. But as he has said later in time, he wanted to
write his own OS and did not both ask the right folks at his University, or
try to get permission.   Although he has said he access to Sun3 and has
said that was his impetus for his work.   This is an important point that
Larry reminds us of, many institutions kept the sources locked away like
his U of Wis.   Other places were like liberal about access.  IIRC Larry
sometimes refers to it as the "UNIX Club."

In my own case, I was running what would become 386BSD on my Wyse 32:16 box
at home and on an NCR 386 based system in Clemson as I was consulting for
them at the time.  I also helped Bill with the PC/AT disk driver[WD1003 and
later WD7000/SCSI controllers], as I had access to the docs from WD which
Bill did not.  I think I still have a photocopy of them.

What basically happened is as BSDi forked and that begets a number of
things, from hurt feelings to a famous law suite.   A number of us, thought
the latter was about copyright (we were wrong it was about trade secret).
We were worried that the AT&T copyright would cause UNIX for an inexpensive
processor to disappear.   We >>thought<< (incorrectly) that the copyright
that Linux was using, the GPL, would save us.  Turns out >>legally<< it
would not have, if AT&T had won, at least in the USA and most NATO Allies -
the trade secret applied to all implementations of Ken, Dennis, and the
rest of the BTL folk's ideas.  All of the Unix-like systems were in
violation at this point.  BSDi/UCB was where AT&T started.  The problem is
that while the court found that AT&T did create and own the >>ideas<< (note
ideas are not the source code implementation of the ideas), they could not
call the UNIX 'IP', trade secrets since the AT&T people published them all
both academically in books like Maury Bach's, much less they had been
forced by the 1956 consent decree to make the license available, they had
taught an industry.  BTW:  It's not just software, the transistor 'gets
out' of AT&T under the same type of rules.

In reality, like PGP, since there was lots of UNIX-based IP in other
places, it hard to see in practice how AT&T could have enforced the trade
secret.  But again -- remember Charlie Brown (AT&T CEO) wants to go after
IBM, thinking the big money in computers in the mainframe.  So they did
believe that they could exert pressure on UNIX-like systems for the higher
end, and they might have been able to enforce that.

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

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

* Re: [TUHS] 386BSD released
  2021-07-14 14:09         ` Larry McVoy
@ 2021-07-14 14:54           ` Warner Losh
  2021-07-14 15:06             ` Richard Salz
  2021-07-14 15:37             ` Steve Nickolas
  0 siblings, 2 replies; 44+ messages in thread
From: Warner Losh @ 2021-07-14 14:54 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

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

On Wed, Jul 14, 2021 at 8:10 AM Larry McVoy <lm@mcvoy.com> wrote:

> On Wed, Jul 14, 2021 at 09:07:19AM +0000, Lars Brinkhoff wrote:
> > Michael Kj??rling wrote:
> > > And all this, of course, ignoring the other issue of what might be
> > > considered a "start to the open source operating system movement",
> > > given that even development of GNU was well underway by the time the
> > > Linux kernel got started (having been worked on since early 1984)
> >
> > GNU planned to adopt TRIX which was developed at MIT in the mid 1980s.
> > I don't know its exact distribution terms, but Wipikedia says "open
> > source" so it was possibly in that general vicinity.
> >
> > Arguably ancient PDP-10 operating systems like ITS, WAITS, TENEX were
> > somewhat "open" and "free", but it's not a clear cut case.
>
> X10 and X11 predate all of this and at least X11 is open source.
>

The X10R3 license sure looks like a standard MIT license. The other license
statements that were included also read very much like open source, or
at least a strong intention of being open source, absent any drafting flaws.

Copyright 1985 by the Massachusetts Institute of Technology

Permission to use, copy, modify, and distribute this
software and its documentation for any purpose and without
fee is hereby granted, provided that the above copyright
notice appear in all copies and that both that copyright
notice and this permission notice appear in supporting
documentation, and that the name of M.I.T. not be used in
advertising or publicity pertaining to distribution of the
software without specific, written prior permission.
M.I.T. makes no representations about the suitability of
this software for any purpose.  It is provided "as is"
without express or implied warranty.

This software is not subject to any license of the American
Telephone and Telegraph Company or of the Regents of the
University of California.

Although uwm did have the somewhat longer:

/************************************************************************
 *                                                                      *
 *                      Copyright (c) 1986 by                           *
 *              Digital Equipment Corporation, Maynard, MA              *
 *                       All Rights Reserved.                           *
 *                                                                      *
 *      Permission to use, copy, modify, and distribute this software   *
 *      and its documentation is hereby granted only to licensees of    *
 *      The Regents of the University of California pursuant to their   *
 *      license agreement for the Berkeley Software Distribution        *
 *      provided that the following appears on all copies.              *
 *                                                                      *
 *            "LICENSED FROM DIGITAL EQUIPMENT CORPORATION              *
 *                      COPYRIGHT (C) 1986                              *
 *                 DIGITAL EQUIPMENT CORPORATION                        *
 *                         MAYNARD, MA                                  *
 *                     ALL RIGHTS RESERVED.                             *
 *                                                                      *
 *      THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT   *
 *      NOTICE AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL   *
 *      EQUIPMENT CORPORATION.  DIGITAL MAKES NO REPRESENTATIONS        *
 *      ABOUT SUITABILITY OF THIS SOFTWARE FOR ANY PURPOSE. IT IS       *
 *      SUPPLIED "AS IS" WITHOUT EXPRESS OR IMPLIED WARRANTY.           *
 *                                                                      *
 *      IF THE UNIVERSITY OF CALIFORNIA OR ITS LICENSEES MODIFY         *
 *      THE SOFTWARE IN A MANNER CREATING DERIVATIVE COPYRIGHT          *
 *      RIGHTS APPROPRIATE COPYRIGHT LEGENDS MAY BE PLACED ON THE       *
 *      DERIVATIVE WORK IN ADDITION TO THAT SET FORTH ABOVE."           *
 *                                                                      *
 ************************************************************************/

This is the earliest copy of X10 I could find, pegging the date at around
1985, which
predates Linux by half a dozen years.

Warner

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

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

* Re: [TUHS] 386BSD released
  2021-07-14  9:07       ` Lars Brinkhoff
@ 2021-07-14 14:09         ` Larry McVoy
  2021-07-14 14:54           ` Warner Losh
  0 siblings, 1 reply; 44+ messages in thread
From: Larry McVoy @ 2021-07-14 14:09 UTC (permalink / raw)
  To: Lars Brinkhoff; +Cc: tuhs

On Wed, Jul 14, 2021 at 09:07:19AM +0000, Lars Brinkhoff wrote:
> Michael Kj??rling wrote:
> > And all this, of course, ignoring the other issue of what might be
> > considered a "start to the open source operating system movement",
> > given that even development of GNU was well underway by the time the
> > Linux kernel got started (having been worked on since early 1984)
> 
> GNU planned to adopt TRIX which was developed at MIT in the mid 1980s.
> I don't know its exact distribution terms, but Wipikedia says "open
> source" so it was possibly in that general vicinity.
> 
> Arguably ancient PDP-10 operating systems like ITS, WAITS, TENEX were
> somewhat "open" and "free", but it's not a clear cut case.

X10 and X11 predate all of this and at least X11 is open source.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

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

* Re: [TUHS] 386BSD released
  2021-07-14  7:54 ` Michael Kjörling
  2021-07-14  8:19   ` Angus Robinson
@ 2021-07-14 11:49   ` Andy Kosela
  2021-07-14 15:48     ` Theodore Y. Ts'o
  2021-07-16  1:35   ` Dave Horsfall
  2 siblings, 1 reply; 44+ messages in thread
From: Andy Kosela @ 2021-07-14 11:49 UTC (permalink / raw)
  To: Michael Kjörling; +Cc: tuhs

On 7/14/21, Michael Kjörling <michael@kjorling.se> wrote:
> On 14 Jul 2021 08:28 +1000, from dave@horsfall.org (Dave Horsfall):
>> In 1992, 386BSD is released by Lynne and William Jolitz, starting the
>> open
>> source operating system movement (Linux didn't come along under later).
>
> Are you sure? Wikipedia claims that it happened the other way around;
> that the Linux kernel initial release was 0.02 on 5 Oct 1991, while
> the 386BSD initial release was 0.0 on 12 March 1992.
>
> It seems that work on 386BSD began earlier than work on Linux, but
> that the initial release of Linux was earlier than the initial release
> of 386BSD.
>

I consider the birth of Linux to be August 25th 1991, when Linus
announced it on comp.os.minix.  If he had access to 386BSD in 1991
then probably he would never have started the Linux project -- that's
his words.

He was exposed to UNIX at uni in late 1990, and purchased 386DX33 on
January 5th, 1991 -- a turning point in his life.  After messing
around with MS-DOS and games like Prince of Persia (still one of the
best computers games ever!) for a few months, he started exploring
programming tools for MS-DOS and wanted to write a UNIX clone for his
home computer.  The rest is literally the history...

--Andy

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

* Re: [TUHS] 386BSD released
  2021-07-14 10:09       ` Tom Ivar Helbekkmo via TUHS
@ 2021-07-14 10:39         ` arnold
  2021-07-14 17:21         ` Lyndon Nerenberg (VE7TFX/VE6BBM)
  1 sibling, 0 replies; 44+ messages in thread
From: arnold @ 2021-07-14 10:39 UTC (permalink / raw)
  To: tih, michael; +Cc: TUHS

Tom Ivar Helbekkmo via TUHS <tuhs@minnie.tuhs.org> wrote:

> Michael Kjörling <michael@kjorling.se> writes:
>
> > [...] one might even be able to argue that the early UNIX systems were
> > also, in a sense, open source.
>
> Ditto MINIX, of course, which was released, along with the book, in 1987.

The original Minix wasn't so open source. It was certainly not GPL'ed
or BSD/MIT licensed.  Also, Tannenbaum had no interest in coordinating
distributed development of Minix into a production-worthy system.

I don't want to rehash all of that here, but I certainly would not
have listed the original Minix as Free Software / Open Source.

My two cents,

Arnold

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

* Re: [TUHS] 386BSD released
  2021-07-14  8:32     ` Michael Kjörling
  2021-07-14  9:07       ` Lars Brinkhoff
@ 2021-07-14 10:09       ` Tom Ivar Helbekkmo via TUHS
  2021-07-14 10:39         ` arnold
  2021-07-14 17:21         ` Lyndon Nerenberg (VE7TFX/VE6BBM)
  1 sibling, 2 replies; 44+ messages in thread
From: Tom Ivar Helbekkmo via TUHS @ 2021-07-14 10:09 UTC (permalink / raw)
  To: Michael Kjörling; +Cc: TUHS

Michael Kjörling <michael@kjorling.se> writes:

> [...] one might even be able to argue that the early UNIX systems were
> also, in a sense, open source.

Ditto MINIX, of course, which was released, along with the book, in 1987.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

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

* Re: [TUHS] 386BSD released
  2021-07-14  8:32     ` Michael Kjörling
@ 2021-07-14  9:07       ` Lars Brinkhoff
  2021-07-14 14:09         ` Larry McVoy
  2021-07-14 10:09       ` Tom Ivar Helbekkmo via TUHS
  1 sibling, 1 reply; 44+ messages in thread
From: Lars Brinkhoff @ 2021-07-14  9:07 UTC (permalink / raw)
  To: Michael Kjörling; +Cc: tuhs

Michael Kjörling wrote:
> And all this, of course, ignoring the other issue of what might be
> considered a "start to the open source operating system movement",
> given that even development of GNU was well underway by the time the
> Linux kernel got started (having been worked on since early 1984)

GNU planned to adopt TRIX which was developed at MIT in the mid 1980s.
I don't know its exact distribution terms, but Wipikedia says "open
source" so it was possibly in that general vicinity.

Arguably ancient PDP-10 operating systems like ITS, WAITS, TENEX were
somewhat "open" and "free", but it's not a clear cut case.

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

* Re: [TUHS] 386BSD released
  2021-07-14  8:19   ` Angus Robinson
@ 2021-07-14  8:32     ` Michael Kjörling
  2021-07-14  9:07       ` Lars Brinkhoff
  2021-07-14 10:09       ` Tom Ivar Helbekkmo via TUHS
  2021-07-14 15:01     ` Clem Cole
  1 sibling, 2 replies; 44+ messages in thread
From: Michael Kjörling @ 2021-07-14  8:32 UTC (permalink / raw)
  To: tuhs

On 14 Jul 2021 10:19 +0200, from angus@fairhaven.za.net (Angus Robinson):
> Looking at a few online sources, Linus actually said when "386BSD came out,
> Linux was already in a usable state, that I never really thought about
> switching. If 386BSD had been available when I started on Linux, Linux
> would probably never had happened".

And all this, of course, ignoring the other issue of what might be
considered a "start to the open source operating system movement",
given that even development of GNU was well underway by the time the
Linux kernel got started (having been worked on since early 1984), and
one might even be able to argue that the early UNIX systems were also,
in a sense, open source.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”


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

* Re: [TUHS] 386BSD released
  2021-07-14  7:54 ` Michael Kjörling
@ 2021-07-14  8:19   ` Angus Robinson
  2021-07-14  8:32     ` Michael Kjörling
  2021-07-14 15:01     ` Clem Cole
  2021-07-14 11:49   ` Andy Kosela
  2021-07-16  1:35   ` Dave Horsfall
  2 siblings, 2 replies; 44+ messages in thread
From: Angus Robinson @ 2021-07-14  8:19 UTC (permalink / raw)
  To: Michael Kjörling; +Cc: The Eunuchs Hysterical Society

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

Looking at a few online sources, Linus actually said when "386BSD came out,
Linux was already in a usable state, that I never really thought about
switching. If 386BSD had been available when I started on Linux, Linux
would probably never had happened".

Although the dates differ, it seems Linux was released in 1991


Kind Regards,
Angus Robinson


On Wed, Jul 14, 2021 at 10:04 AM Michael Kjörling <michael@kjorling.se>
wrote:

> On 14 Jul 2021 08:28 +1000, from dave@horsfall.org (Dave Horsfall):
> > In 1992, 386BSD is released by Lynne and William Jolitz, starting the
> open
> > source operating system movement (Linux didn't come along under later).
>
> Are you sure? Wikipedia claims that it happened the other way around;
> that the Linux kernel initial release was 0.02 on 5 Oct 1991, while
> the 386BSD initial release was 0.0 on 12 March 1992.
>
> It seems that work on 386BSD began earlier than work on Linux, but
> that the initial release of Linux was earlier than the initial release
> of 386BSD.
>
> --
> Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
>  “Remember when, on the Internet, nobody cared that you were a dog?”
>
>

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

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

* Re: [TUHS] 386BSD released
  2021-07-13 22:28 Dave Horsfall
@ 2021-07-14  7:54 ` Michael Kjörling
  2021-07-14  8:19   ` Angus Robinson
                     ` (2 more replies)
  2021-07-14 21:37 ` Bakul Shah
  2021-07-16 21:22 ` Dave Horsfall
  2 siblings, 3 replies; 44+ messages in thread
From: Michael Kjörling @ 2021-07-14  7:54 UTC (permalink / raw)
  To: tuhs

On 14 Jul 2021 08:28 +1000, from dave@horsfall.org (Dave Horsfall):
> In 1992, 386BSD is released by Lynne and William Jolitz, starting the open
> source operating system movement (Linux didn't come along under later).

Are you sure? Wikipedia claims that it happened the other way around;
that the Linux kernel initial release was 0.02 on 5 Oct 1991, while
the 386BSD initial release was 0.0 on 12 March 1992.

It seems that work on 386BSD began earlier than work on Linux, but
that the initial release of Linux was earlier than the initial release
of 386BSD.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”


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

* [TUHS] 386BSD released
@ 2021-07-13 22:28 Dave Horsfall
  2021-07-14  7:54 ` Michael Kjörling
                   ` (2 more replies)
  0 siblings, 3 replies; 44+ messages in thread
From: Dave Horsfall @ 2021-07-13 22:28 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

In 1992, 386BSD is released by Lynne and William Jolitz, starting the open 
source operating system movement (Linux didn't come along under later).

-- Dave

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

end of thread, other threads:[~2021-07-18 13:23 UTC | newest]

Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-15  2:21 [TUHS] 386BSD released Douglas McIlroy
2021-07-15  2:41 ` Adam Thornton
2021-07-15 15:07 ` Clem Cole
2021-07-15 19:33   ` [TUHS] [COFF] " Theodore Y. Ts'o
2021-07-15 19:49     ` Adam Thornton
2021-07-15 20:29       ` Andy Kosela
2021-07-16  2:22       ` 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
2021-07-15 23:02     ` joe mcguckin
  -- strict thread matches above, loose matches on Subject: below --
2021-07-16 17:30 [TUHS] " Nelson H. F. Beebe
2021-07-13 22:28 Dave Horsfall
2021-07-14  7:54 ` Michael Kjörling
2021-07-14  8:19   ` Angus Robinson
2021-07-14  8:32     ` Michael Kjörling
2021-07-14  9:07       ` Lars Brinkhoff
2021-07-14 14:09         ` Larry McVoy
2021-07-14 14:54           ` Warner Losh
2021-07-14 15:06             ` Richard Salz
2021-07-14 15:37             ` Steve Nickolas
2021-07-14 10:09       ` Tom Ivar Helbekkmo via TUHS
2021-07-14 10:39         ` arnold
2021-07-14 17:21         ` Lyndon Nerenberg (VE7TFX/VE6BBM)
2021-07-14 17:32           ` Richard Salz
2021-07-14 15:01     ` Clem Cole
2021-07-14 11:49   ` Andy Kosela
2021-07-14 15:48     ` Theodore Y. Ts'o
2021-07-16  1:35   ` Dave Horsfall
2021-07-16  2:33     ` risner
2021-07-16  4:25       ` Theodore Y. Ts'o
2021-07-16  5:51         ` Bakul Shah
2021-07-16 13:00           ` Theodore Y. Ts'o
2021-07-16 13:56             ` Larry McVoy
2021-07-16 14:40               ` Clem Cole
2021-07-16 15:44                 ` Theodore Y. Ts'o
2021-07-16 16:11               ` Bakul Shah
2021-07-16 19:07               ` Kevin Bowling
2021-07-16 20:17                 ` Clem Cole
2021-07-16 20:24                   ` Richard Salz
2021-07-18 13:13                     ` arnold
2021-07-18 13:23                       ` Richard Salz
2021-07-14 21:37 ` Bakul Shah
2021-07-16 21:22 ` Dave Horsfall

The Unix Heritage Society mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/tuhs

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 tuhs tuhs/ http://inbox.vuxu.org/tuhs \
		tuhs@minnie.tuhs.org
	public-inbox-index tuhs

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git