[TUHS] 3 essays on the ujnix legacy

[Warner Losh via TUHS]

On Sat, Nov 1, 2025, 8:13 PM Theodore Tso via TUHS <tuhs at tuhs.org> wrote:

> On Sat, Nov 01, 2025 at 12:45:14PM -0400, Clem Cole via TUHS wrote:
> > Hrrmph. IMO: This is trying to fit the data over the graph you want.
> >
> > I never agreed with ESR's model.  Linux was (and continues to be) a
> > Cathedral.  It just has different master builders than BSD, SunOS, SVR4,
> > VMS, and NT did.
>
> Speaking as someone who was working on Linux from the beginning (I was
> the first North American Linux kernel hacker, and the first US FTP
> redistribution site for Linux was my desktop workstation at MIT (a
> Vaxstation 3100 M38 running Ultrix), I never agreed with ESR's model
> either, and I agree that Mr. Garcia's graph is also... not reflective
> of reality.
>
> First of all, ESR never spoke for the Linux community; certainly not
> all of it.  And the whole "with enough eyeballs, all bugs are shallow"
> might be true for some bugs, but it is *most* definitely not true for
> all; especially in the kernel or multi-threaded programs.  More
> generally, ESR's thesis was only really applicable or interesting for
> projects in a relatively narrow band of complexity.  Projects which
> are too small/simple aren't inteersting enough to have sufficient
> gravitational pull to create a viable development community.  And
> that's why there are a huge number of abandoned trivial projects in
> github or sourceforge.  The plausibility of ESR's Cathedral and Bazaar
> essay relies on survivorship bias.
>
> The Cathedral model also falls apart for projects that grow beyond
> that a certain complexity, when it requires a non-trivial of engineers
> working full-time, or at least a significant percentage of their time
> on the prjoect.  At that point, it's not just about a devloper wanting
> to scratch their personal itch, but what their employer is willing to
> fund --- since unless the developer is independently wealthy, most
> developers do prefer to have food with their meals.
>
> At that point, what gets attention is very strongly affected by what
> one or more companies have a business case to fund.  An especially
> talented project leader with Product Management team, can sometimes
> stich together develop programs where different engineers working for
> different companies can work together on different features that
> benefit all of their employers.  But not everyone has that particular
> combination of technical, social, and business skills.
>
> Most people who try to create their models how "the open source
> community" tend to forget both needs of the companies who fund
> projects, and passion and commitments of the engineers in those
> projects, many of whome sacrifice a certain amount of career or
> financial prospects because they care about the commuity of which they
> have become a part.  Many of these engineers have worked for more than
> one company, and have known colleagues who have worked at multiple
> company.  So these engineers tend to have a group loyalty which is not
> precisely mapped to their employer; but at the same time, they know
> that they need to add enough value to their employer so that (a) their
> company stays in business, and (b) the company is willing to continue
> to pay their salary.
>
> It's complicated(tm).
>
> On Sat, Nov 01, 2025 at 10:05:47AM -0700, Alan Coopersmith via TUHS wrote:
> > On 11/1/25 07:42, A. P. Garcia via TUHS wrote:
> > > Linux took the opposite path. Its ecosystem is messy, distributed, and
> > > loud, a bazaar where competing ideas coexist until one wins by
> survival,
> > > not decree. It doesn’t import technologies wholesale. It reinvents them
> > > from first principles.
> > >
> > > That’s why instead of adopting DTrace, Linux built eBPF, a programmable
> > > virtual machine for tracing, networking, and observability. It’s more
> > > complex, less elegant, but more adaptable.
> >
> > Except of course, Linux built eBPF on top of BPF, a technology imported
> > wholesale from BSD.  The difference between how Linux looked at Dtrace &
> > BPF is one of license terms, not philosophy - they were willing to accept
> > BSD-licensed imports, but not CDDL-licensed ones.
>

Also, in large part eBPF and BPF share only three letters of their name.
Extending it meant completely redoing it in the end, with a lot of learning
by fire as the exploits came out.  But you can't deny that it's easier to
use than dtrace and has gone well beyond Dtrace could easily be used for
(it could in theory, but practicalities made it hard to be a firewall much
less a portable one).

Absolutely.  Linux is quite willing to take ideas and code from
> everywhere, so long as (a) it's good, and (b) the copyright license is
> compatible.  For example, Read-Copy-Update (RCU) was a technique that
> was created and patented by Sequent, and after IBM purchased Sequent,
> IBM donated the patent to Linux, and had former Sequent engineers
> (working for IBM's Linux Technology Center) implement RCU for Linux.
>
> We'll take code and ideas from whereever we can get them.
>

Indeed. At times, though, part of what it takes to get good code into the
tree has an element of politics about it. It's another aspect of open
source ESR's model fails to capture.

If Oracle hadn't outbid IBM to purchase Sun Microsystems (and some of
> us believe that some executives at Sun leaked details of the
> negotiation to the Wall Street Journal to draw competitors such as
> Oracle to bid on Sun; certainly IBM had no incentive to leak what came
> out in the press), it is very likely that I would have been on the
> teams sent to Sun, and we would have tried to relicense DTrace and ZFS
> from the CDDL to the GPL or some GPL-compatible license.
>

FreeBSD would have loved a BSD or MIT license for both of these. :).

At one point an engineer/manager at Oracle announced at a conference that
ZFS would be relicensed as GPL. He was fired a few days later. Oracle
really doesn't want to relicense.

It's interesting to consider what the alternate history might have
> been if we could have merged the best of the Solaris technology into
> Linux, and if we could have welcomed some of the Solaris team into the
> Linux community.  I certainly had nothing but respect for them, and I
> always thought that they had been badly let down by their management
> and sales teams.   They deserved better.
>

Indeed. I tried to get some of them interested in working on FreeBSD after
all that, but the damage was done... while they had jobs with Oracle, they
were happy to make Solaris better and did a damn fine job at it. Once it
fell apart, though, everyone was too burned out...

My personal belief is that Oracle's acquisition of Sun Microsystems,
> while it may have represented a better deal for Sun's shareholders,
> was ultimately a tragedy for the industry as a whole.
>

Agreed. Sun had cool technology and moved a lot into open source. It was an
interesting experiment that may have had a hand in their fall from
profitability... though that whole path was rather complicated.

Warner


Cheers,
>
>                                         - Ted
>