From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11972 invoked from network); 6 Jun 2022 01:02:55 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 6 Jun 2022 01:02:55 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id B6E36421FF; Mon, 6 Jun 2022 11:02:50 +1000 (AEST) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) by minnie.tuhs.org (Postfix) with ESMTPS id 020C9421FC for ; Mon, 6 Jun 2022 11:02:46 +1000 (AEST) Received: by mail-vs1-xe2e.google.com with SMTP id q14so12436464vsr.12 for ; Sun, 05 Jun 2022 18:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XH/enoTTpRtoMmjqP/fWUFdW+CgP0ahiBv2HNL0cyr4=; b=TE21B82t5kmV7Fn8yKZAvoUy/QqDl1BaLPYXs0kXrBzoNv4Q0VAvTJKCzv5clL3JOG Z2Ac/sCXkokrKSOqkF3vsvFVxXBqvo3a/AP66kPLEVERWrnz//jWdUzxDHsjhq5QuRLC cU4jRf8mA7nT3R/in2ELuuOmrSI/YbL9a2iGRvLrOKIjstqgprT0M4cjzlINobw8U6ux RU0aQloqFzTODaQaGAxmzF7KaPTJb80AbSMdPhTY/KVWde8Hs8Uwv3Id4KRDZikf4hbD 8AOwsA63KAF10cEuhVTy/w0vgipbo8icummhdx2WYkUhuKheD0Coq48X3TWZagXkjjya tbrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XH/enoTTpRtoMmjqP/fWUFdW+CgP0ahiBv2HNL0cyr4=; b=DoGRGnedztfXER8q6wbfp2mphZpkgWyagSvzapURgyZ4LpKZkfii5B9hs8qKKYWSTg MKpbjNIKSYC6hKYyO07AD9oxyeW0rFIpnMkAqskCMbVVmSbMBmAwlafDYrUgirQCbG20 4SHZqf2zEFfvdkx6bDpGYZ3I0CpAWGW3q6MXgYgh4bRG13s9rBinb2Boi7uZb6mcaFWJ JcJrRuoMYvewYqEUd7X0CyzhD8V3XzlkJDbkjjMERtu+JujjCONUNng7+mAQVxK679yH Q1/jJ3zxpZ9wUAeyVzaZIPy1hYbpdpX6NS0/qNSL/iQ6FdEsBJRPSw7Mb+BT75gMOWvw xC4Q== X-Gm-Message-State: AOAM533TjGSJT5hrHq+DxGE+4PWSlN62qi/nh7VVV4r0JIVue7uHhcC7 m4TQX4KKDax9KtNp088ya4unicY7uzqrNb0q7b87ZEi6o+A= X-Google-Smtp-Source: ABdhPJylbtI7DVK99AvFlyCX1AFjrFs1XhkzMXmZ/miI+hNh3Yhj3OQ9kal4XTwcEJJvjEBQOEJyX+wgGUwFaQsr7io= X-Received: by 2002:a05:6102:440c:b0:34b:c5d6:174 with SMTP id df12-20020a056102440c00b0034bc5d60174mr318314vsb.45.1654477364736; Sun, 05 Jun 2022 18:02:44 -0700 (PDT) MIME-Version: 1.0 References: <20220603213215.GO10240@mcvoy.com> <20220603214032.GQ10240@mcvoy.com> <20220603223014.GS10240@mcvoy.com> <20220603234822.GV10240@mcvoy.com> <20220604010543.GZ10240@mcvoy.com> In-Reply-To: From: Warner Losh Date: Sun, 5 Jun 2022 19:02:33 -0600 Message-ID: To: "Theodore Ts'o" Content-Type: multipart/alternative; boundary="0000000000009d496705e0bd077a" Message-ID-Hash: 33M6PGCGJC6LQ3OOS7P443PIMH2TEM3A X-Message-ID-Hash: 33M6PGCGJC6LQ3OOS7P443PIMH2TEM3A X-MailFrom: wlosh@bsdimp.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000009d496705e0bd077a Content-Type: text/plain; charset="UTF-8" On Sun, Jun 5, 2022 at 6:32 PM Theodore Ts'o wrote: > On Fri, Jun 03, 2022 at 06:05:43PM -0700, Larry McVoy wrote: > > > > So in all of this, the thing that keeps getting missed is Linux won. > > And it didn't win because of the lawsuit, it didn't get crushed by the > > GPL that all the BSD people hate so much, it won on merits. And it > > won because there was one Linux kernel. You could, and I have many, > > many times, just clone the latest kernel and compile and install on > > any distribution. It worked. The same was never true for all the BSD > > variants. Tell me about the times you cloned the OpenBSD kernel and > > it worked on FreeBSD. I'm maybe sure there was maybe one point in time > > where that worked but then for all the other points in time it didn't. > > So in essence what you're saying is that OpenBSD and FreeBSD weren't > ABI compatible, and that's your definition of when two OS's are > different. And so when Warner says that there are hundreds of forks > of the Linux kernel, to the extent that the ABI's are compatible, they > really aren't "different". > Yes. The forks might not have been bad, and there's always some logical fallacy presented to say they are somehow the "same" because of some artificial criteria. And I'm not convinced all the forks are bad, per se. Just that the narrative that says there's only one is false and misleading in some ways because there always was a diversity of 'add in' patches for different distributions, both commercial and hobbyist... Much, but by no means all, of that wound up upstream, though not always the best and the reasons for rejection could be arbitrary at times, or just made too hard to bother trying to upstream at others. There was something in the diversity, though, that I'll readily admit was beneficial. > Part of this comes from the the fact that the Linux kernel, C library, > and core utilities are all shipped separately. The BSDs have often > criticized this, claiming that shipping all of the OS in a single > source control system makes it easier to rollout new features. There > is no doubt upsides from having a single source tree; but one of the > advantages of keeping things separate is that definition of the kernel > <-> userspace interface is much more explicit. > > That being said, I will note that this always hasn't been true. There > was a brief period where an early Red Hat Enterprise Linux version > suffered from the "legacy Unix value-add disease", where Red Hat had > added some kernel changes that impacted kernel interfaces, which > didn't make it upstream, or made it upstream with a changed interface, > such that when users wanted to use a newer upstream kernel, which had > newer features, and newer device driver support, it wouldn't work with > that version RHEL. Red Hat has criticized *heavily* for that, both by > the upstream development community and by its users, and since then it > has stuck to a "usptream first" policy, especially where new system > calls, or some other kernel interface is concerned. > I suffered through MontaVista Linux which definitely wasn't ABI compatible. And all of their board support packages were based on different versions of Linux, making it a nightmare to support lots of architectures... > One of the reasons why that early RHEL experience kept Red Hat in line > was because none of the other Linux distributions had that property > --- and because the core development in upstream hadn't slacked off, > so there was a strong desire to upgrade to newer kernels on RHEL, and > when that didn't worked, not only did that make customers and > developers upset, but it also made life difficult for Red Hat > engineers, since they now need to figure out how to forward port their > "value add" changes onto the latest and greatest kernel release. > > > An interesting question is if CSRG had been actively pushing the state > of the art foreward, would that have provided sufficient centripetal > force to keep the HP/UX, SunOS, DG/UX, etc., from spintering? After > all, it's natural to want to get a competitive advantage over your > competition by adding new features --- this is what I call the "Legacy > Unix value-add disease". But if you can't keep up with the upstream > developments, that provides a strong disincentive from making > permanent forks. For that matter, why was it that successive new > releases of AT&T System V wasn't able to play a similar role? Was it > because the rate of change was too slow? Was it because applications > weren't compatible anyway due to ISA differences? I don't know.... > CSRG's funding dried up when the DARPA work was over. And even before it was over, CSRG was more an academic group than one who had a desire to impose its will on commercial groups that it had no leverage over. And AT&T had become all about monetization of unix, which meant it imposed new terms that were unfavorable, making it harder for old-time licensees to justify pulling in the new code that would have kept the world from Balkanizing as badly as it did. So there were complex issues at play here as well. > One other dynamic might be the whole worse is better is worse debate. > As an example of this, Linux had PCMCIA support at least a year or two > before NetBSD did, and in particular Linux had hot-add support where > you could insert an ethernet PCMCIA into your laptop after the OS had > booted, and the ethernet card would work. However, if you ejected the > ethernet card, there was a roughly 1 in 4 chance that your system > would crash. NetBSD took a lot longer to get PCMCIA support --- but > when it did, it had hot-add and hot-remove working perfectly, while > Linux took a year or two more after that point before hot-remove was > solidly reliable. > Except FreeBSD's PAO project had PCMCIA support about two years before NetBSD did, and hot plug worked on it too.. So that's a bit of an apples to oranges comparison. To be fair, the main FreeBSD project was slow to take up changes from PAO and that set back PC Card and CardBus support a number of years. > So from a computer science point of view, one could argue that NetBSD > was "better", and that Linux had a whole bunch of hacks, and some > might even argue was written by a bunch of hacks. :-) However, from > the user's perspective, who Just Wanted Their Laptop To Work, the fact > that Linux had some kind of rough PCMCIA support first mattered a lot > more than a "we will ship no code before its time" attitude. And > some of those users would become developers, which would cause a > positive feedback loop. > At the time, though, FreeBSD ran on the busiest FTP server on the internet could handle quite a bit more load than an equivalent Linux box at the time. And NetBSD was much more in the "no code before its time" camp than FreeBSD, which tried to get things out faster and often did a good job at that. Though it did well with networking, it didn't do so well with PC Card, so it's rather a mixed bag. The only reason I keep replying to this thread is that the simple narratives that people keep repeating often times aren't so simple and the factors going into things tend to be much more complex and nuanced. Warner --0000000000009d496705e0bd077a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jun 5, 2022 at 6:32 PM Theodo= re Ts'o <tytso@mit.edu> wrot= e:
On Fri, Jun 0= 3, 2022 at 06:05:43PM -0700, Larry McVoy wrote:
>
> So in all of this, the thing that keeps getting missed is Linux won. > And it didn't win because of the lawsuit, it didn't get crushe= d by the
> GPL that all the BSD people hate so much, it won on merits.=C2=A0 And = it
> won because there was one Linux kernel.=C2=A0 You could, and I have ma= ny,
> many times, just clone the latest kernel and compile and install on > any distribution.=C2=A0 It worked.=C2=A0 The same was never true for a= ll the BSD
> variants.=C2=A0 Tell me about the times you cloned the OpenBSD kernel = and
> it worked on FreeBSD.=C2=A0 I'm maybe sure there was maybe one poi= nt in time
> where that worked but then for all the other points in time it didn= 9;t.

So in essence what you're saying is that OpenBSD and FreeBSD weren'= t
ABI compatible, and that's your definition of when two OS's are
different.=C2=A0 And so when Warner says that there are hundreds of forks of the Linux kernel, to the extent that the ABI's are compatible, they<= br> really aren't "different".

Yes. The forks might not have been bad, and there's always some
=
logical fallacy=C2=A0presented to say they are somehow the "same&= quot; because
of some artificial criteria.

And I'm not convinced all the forks are bad, per se. Just that the n= arrative
that says there's only one is false and misleading i= n some ways because
there always was a diversity of 'add in&#= 39; patches for different distributions,
both commercial=C2=A0and= hobbyist... Much, but by no means all, of that wound
up upstream= , though not always the best and the reasons for rejection
could = be arbitrary=C2=A0at times, or just made too hard to bother trying to upstr= eam
at others. There was something in the diversity, though, that= I'll readily
admit was beneficial.
=C2=A0
Part of this comes from the the fact that the Linux kernel, C library,
and core utilities are all shipped separately.=C2=A0 The BSDs have often criticized this, claiming that shipping all of the OS in a single
source control system makes it easier to rollout new features.=C2=A0 There<= br> is no doubt upsides from having a single source tree; but one of the
advantages of keeping things separate is that definition of the kernel
<-> userspace interface is much more explicit.

That being said, I will note that this always hasn't been true.=C2=A0 T= here
was a brief period where an early Red Hat Enterprise Linux version
suffered from the "legacy Unix value-add disease", where Red Hat = had
added some kernel changes that impacted kernel interfaces, which
didn't make it upstream, or made it upstream with a changed interface,<= br> such that when users wanted to use a newer upstream kernel, which had
newer features, and newer device driver support, it wouldn't work with<= br> that version RHEL.=C2=A0 Red Hat has criticized *heavily* for that, both by=
the upstream development community and by its users, and since then it
has stuck to a "usptream first" policy, especially where new syst= em
calls, or some other kernel interface is concerned.
I suffered through MontaVista Linux which definitely wasn'= t ABI compatible.
And all of their board support packages were ba= sed on different versions
of Linux, making it a nightmare to supp= ort lots of architectures...
=C2=A0
One of the reasons why that early RHEL experience kept Red Hat in line
was because none of the other Linux distributions had that property
--- and because the core development in upstream hadn't slacked off, so there was a strong desire to upgrade to newer kernels on RHEL, and
when that didn't worked, not only did that make customers and
developers upset, but it also made life difficult for Red Hat
engineers, since they now need to figure out how to forward port their
"value add" changes onto the latest and greatest kernel release.<= br>

An interesting question is if CSRG had been actively pushing the state
of the art foreward, would that have provided sufficient centripetal
force to keep the HP/UX, SunOS, DG/UX, etc., from spintering?=C2=A0 After all, it's natural to want to get a competitive advantage over your
competition by adding new features --- this is what I call the "Legacy=
Unix value-add disease".=C2=A0 But if you can't keep up with the u= pstream
developments, that provides a strong disincentive from making
permanent forks.=C2=A0 For that matter, why was it that successive new
releases of AT&T System V wasn't able to play a similar role?=C2=A0= Was it
because the rate of change was too slow?=C2=A0 Was it because applications<= br> weren't compatible anyway due to ISA differences?=C2=A0 I don't kno= w....

CSRG's funding dried up when = the DARPA work was over. And even before
it was over, CSRG was mo= re an academic=C2=A0group than one who had a desire
to impose its= will on commercial groups that it had no leverage over.

And AT&T had become all about monetization=C2=A0of unix, which m= eant it imposed
new terms that were unfavorable, making it harder= for old-time licensees to
justify pulling in the new code that w= ould have kept the world from Balkanizing
as badly as it did. So = there were complex issues at play here as well.
=C2=A0
One other dynamic might be the whole worse is better is worse debate.
As an example of this, Linux had PCMCIA support at least a year or two
before NetBSD did, and in particular Linux had hot-add support where
you could insert an ethernet PCMCIA into your laptop after the OS had
booted, and the ethernet card would work.=C2=A0 However, if you ejected the=
ethernet card, there was a roughly 1 in 4 chance that your system
would crash.=C2=A0 NetBSD took a lot longer to get PCMCIA support --- but when it did, it had hot-add and hot-remove working perfectly, while
Linux took a year or two more after that point before hot-remove was
solidly reliable.

Except FreeBSD's = PAO project had PCMCIA support about two years
before NetBSD did,= and hot plug worked on it too.. So that's a bit of an
apples= to oranges comparison. To be fair, the main FreeBSD project
was = slow to take up changes from PAO and that set back PC Card
and Ca= rdBus support a number of years.
=C2=A0
So from a computer science point of view, one could argue that NetBSD
was "better", and that Linux had a whole bunch of hacks, and some=
might even argue was written by a bunch of hacks.=C2=A0 :-)=C2=A0 However, = from
the user's perspective, who Just Wanted Their Laptop To Work, the fact<= br> that Linux had some kind of rough PCMCIA support first mattered a lot
more than a "we will ship no code before its time" attitude.=C2= =A0 And
some of those users would become developers, which would cause a
positive feedback loop.

At the time, th= ough, FreeBSD ran on the busiest FTP server on the
internet could= handle quite a bit more load than an equivalent Linux
box at the= time. And NetBSD was much more in the "no code before
its t= ime" camp than FreeBSD, which tried to get things out faster
and often did a good job at that. Though it did well with networking,
it didn't do so well with PC Card, so it's rather a mixed bag= .

The only reason I keep replying to this thread i= s that the simple
narratives that people keep repeating often tim= es aren't so simple
and the factors going into things tend to= be much more complex
and nuanced.

Warne= r
--0000000000009d496705e0bd077a--