The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Fwd: [simh] Announcing the Open SIMH project
       [not found]   ` <CAC20D2OK9muQm=gCSeRzarV_HQF6vZ9VNuYRas4uCbMyxYKjJA@mail.gmail.com>
@ 2022-06-03 20:00     ` Clem Cole
  2022-06-03 20:12       ` [TUHS] " Blake McBride
                         ` (2 more replies)
  0 siblings, 3 replies; 57+ messages in thread
From: Clem Cole @ 2022-06-03 20:00 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

Announcing the Open SIMH project

SIMH is a framework and family of computer simulators, initiated by Bob
Supnik and continued with contributions (large and small) from many others,
with the primary goal of enabling the preservation of knowledge contained
in, and providing the ability to execute/experience, old/historic software
via simulation of the hardware on which it ran. This goal has been
successfully achieved and has for these years created a diverse community
of users and developers.

This has mapped to some core operational principles:

First, preserve the ability to run old/historically significant software.
This means functionally accurate, sometimes bug-compatible, but not
cycle-accurate, simulation.

Second, make it reasonably easy to add new simulators for other hardware
while leveraging common functions between the simulators.

Third, exploit the software nature of simulation and make SIMH convenient
for debugging a simulated system, by adding non-historical features to the
environment.

Fourth, make it convenient for users to explore old system environments,
with as close to historical interfaces, by mapping them to new features
that modern host operating systems provide.

Fifth, be inclusive of people and new technology. It's serious work, but it
should be fun.

Previously, we unfortunately never spent the time to codify how we would
deliver on these concepts. Rather, we have relied on an informal use of
traditional free and open-source principles.

Recently a situation has arisen that compromises some of these principles
and thus the entire status of the project, creating consternation among
many users and contributors.

For this reason, a number of us have stepped up to create a new
organizational structure, which we call "The Open SIMH Project", to be the
keeper and provide formal governance for the SIMH ecosystem going forward.
While details of the structure and how it operates are likely to be refined
over time, what will not change is our commitment to maintaining SIMH as a
free and open-source project, licensed under an MIT-style license as shown
on the "simh" repository page.

It is our desire that all of the past users and contributors will come to
recognize that the new organizational structure is in the best interests of
the community at large and that they will join us in it. However, this
iproject as defined, is where we intend to contribute our expertise and
time going forward.  At this point, we have in place the following,
although we foresee other resources being added in the future as we
identify the need and execute against them:

A Github "organization" for the project at https://github.com/open-simh

A Git repository for the simulators themselves at
https://github.com/open-simh/simh

The license for the SIMH simulator code base, found in LICENSE.txt in the
top level of the "simh" repository.

The "SIMH related tools" in https://github.com/open-simh/simtools. This is
also licensed under MIT style or BSD style open source licenses (which are
comparable apart from some minor wording differences).

A "SIMH Steering Group" -- project maintainers and guides.

The conventional git style process is used for code contributions, via pull
request to the project repository. The Steering Group members have approval
authority; this list is likely to change and grow over time.

By formalizing the underlying structure, our operational principles and
guidance can best benefit the community. These are being developed and
formalized, with a plan to publish them soon.

We have used our best judgment in setting up this structure but are open to
discussion and consideration of other ideas, and to making improvements.
Many of us have been part of different projects and understand that past
mistakes are real. We have tried to learn from these experiences and apply
the collected wisdom appropriately. We desire to hear from the community as
we update and refine the operating structure for the Open SIMH project.

We hope for your patience and look forward to your support as we work to
refine the organization and be able to provide this wonderful resource for
anyone to use as we continue to evolve the technology provided by the SIMH
system.

     The SIMH Steering Group
        Clem Cole
        Richard Cornwell
        Paul Koning
        Timothe Litt
        Seth Morabito
        Bob Supnik


ᐧ
ᐧ
ᐧ

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 20:00     ` [TUHS] Fwd: [simh] Announcing the Open SIMH project Clem Cole
@ 2022-06-03 20:12       ` Blake McBride
  2022-06-03 20:23       ` G. Branden Robinson
  2022-06-03 20:52       ` Will Senn
  2 siblings, 0 replies; 57+ messages in thread
From: Blake McBride @ 2022-06-03 20:12 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

This is all very interesting.  However, there is one important point that I
am unclear about.  Is this a fork in SIMH development or a restructuring of
the original SIMH?  In other words, is this a continuation of the existing
SIMH effort or a fork?

Thank you.

Blake McBride

On Fri, Jun 3, 2022 at 3:00 PM Clem Cole <clemc@ccc.com> wrote:

> Announcing the Open SIMH project
>
> SIMH is a framework and family of computer simulators, initiated by Bob
> Supnik and continued with contributions (large and small) from many others,
> with the primary goal of enabling the preservation of knowledge contained
> in, and providing the ability to execute/experience, old/historic software
> via simulation of the hardware on which it ran. This goal has been
> successfully achieved and has for these years created a diverse community
> of users and developers.
>
> This has mapped to some core operational principles:
>
> First, preserve the ability to run old/historically significant software.
> This means functionally accurate, sometimes bug-compatible, but not
> cycle-accurate, simulation.
>
> Second, make it reasonably easy to add new simulators for other hardware
> while leveraging common functions between the simulators.
>
> Third, exploit the software nature of simulation and make SIMH convenient
> for debugging a simulated system, by adding non-historical features to the
> environment.
>
> Fourth, make it convenient for users to explore old system environments,
> with as close to historical interfaces, by mapping them to new features
> that modern host operating systems provide.
>
> Fifth, be inclusive of people and new technology. It's serious work, but
> it should be fun.
>
> Previously, we unfortunately never spent the time to codify how we would
> deliver on these concepts. Rather, we have relied on an informal use of
> traditional free and open-source principles.
>
> Recently a situation has arisen that compromises some of these principles
> and thus the entire status of the project, creating consternation among
> many users and contributors.
>
> For this reason, a number of us have stepped up to create a new
> organizational structure, which we call "The Open SIMH Project", to be the
> keeper and provide formal governance for the SIMH ecosystem going forward.
> While details of the structure and how it operates are likely to be refined
> over time, what will not change is our commitment to maintaining SIMH as a
> free and open-source project, licensed under an MIT-style license as shown
> on the "simh" repository page.
>
> It is our desire that all of the past users and contributors will come to
> recognize that the new organizational structure is in the best interests of
> the community at large and that they will join us in it. However, this
> iproject as defined, is where we intend to contribute our expertise and
> time going forward.  At this point, we have in place the following,
> although we foresee other resources being added in the future as we
> identify the need and execute against them:
>
> A Github "organization" for the project at https://github.com/open-simh
>
> A Git repository for the simulators themselves at
> https://github.com/open-simh/simh
>
> The license for the SIMH simulator code base, found in LICENSE.txt in the
> top level of the "simh" repository.
>
> The "SIMH related tools" in https://github.com/open-simh/simtools. This
> is also licensed under MIT style or BSD style open source licenses (which
> are comparable apart from some minor wording differences).
>
> A "SIMH Steering Group" -- project maintainers and guides.
>
> The conventional git style process is used for code contributions, via
> pull request to the project repository. The Steering Group members have
> approval authority; this list is likely to change and grow over time.
>
> By formalizing the underlying structure, our operational principles and
> guidance can best benefit the community. These are being developed and
> formalized, with a plan to publish them soon.
>
> We have used our best judgment in setting up this structure but are open
> to discussion and consideration of other ideas, and to making improvements.
> Many of us have been part of different projects and understand that past
> mistakes are real. We have tried to learn from these experiences and apply
> the collected wisdom appropriately. We desire to hear from the community as
> we update and refine the operating structure for the Open SIMH project.
>
> We hope for your patience and look forward to your support as we work to
> refine the organization and be able to provide this wonderful resource for
> anyone to use as we continue to evolve the technology provided by the SIMH
> system.
>
>      The SIMH Steering Group
>         Clem Cole
>         Richard Cornwell
>         Paul Koning
>         Timothe Litt
>         Seth Morabito
>         Bob Supnik
>
>
> ᐧ
> ᐧ
> ᐧ
>

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 20:00     ` [TUHS] Fwd: [simh] Announcing the Open SIMH project Clem Cole
  2022-06-03 20:12       ` [TUHS] " Blake McBride
@ 2022-06-03 20:23       ` G. Branden Robinson
  2022-06-03 21:06         ` Clem Cole
  2022-06-03 21:35         ` Ben Walton
  2022-06-03 20:52       ` Will Senn
  2 siblings, 2 replies; 57+ messages in thread
From: G. Branden Robinson @ 2022-06-03 20:23 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

At 2022-06-03T16:00:15-0400, Clem Cole wrote:
> Recently a situation has arisen that compromises some of these principles
> and thus the entire status of the project, creating consternation among
> many users and contributors.

I wonder if that issue would be the one referred to here.

https://twitter.com/the_aiju/status/1526921795139514368

(I understand if Clem doesn't want to directly answer that.)

It's probably impolitic to reference that matter, and if I'm right
that's no doubt why reference to same was omitted from the announcement
email.  It is traditional for such statements to be high-minded even if
they wouldn't be necessary but for the rather low conduct that compels
their issue in response.

The above situation seems similar to others we've seen before.  It's
probably even more impolitic to note that in the Debian Project, this
sort of licensing shenangians would be referred to as "pulling a Jörg
Schilling"[1].

I expect that time will soon tell whether an even better term would be
"committing an XFree86".

On a positive note, I'd like to express my thanks to the SIMH
contributors past and present for making it straightforward to verify
the behavior Unix V7 troff in my development work on groff.

If Open SIMH remains dedicated to software freedom in the GNU and DFSG
senses I expect it will enjoy overwhelming support.

Cheers,
Branden

[1] https://lwn.net/Articles/195167/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 20:00     ` [TUHS] Fwd: [simh] Announcing the Open SIMH project Clem Cole
  2022-06-03 20:12       ` [TUHS] " Blake McBride
  2022-06-03 20:23       ` G. Branden Robinson
@ 2022-06-03 20:52       ` Will Senn
  2022-06-03 21:06         ` [TUHS] " Adam Thornton
  2 siblings, 1 reply; 57+ messages in thread
From: Will Senn @ 2022-06-03 20:52 UTC (permalink / raw)
  To: Clem Cole, The Eunuchs Hysterical Society

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

Hear! Hear! I'd say it's about time, but that might be impolitic. This 
is fantastic news and bodes well for my favorite sim's future.

Thanks for the heads up,

Will

On 6/3/22 3:00 PM, Clem Cole wrote:
> Announcing the Open SIMH project
>
> SIMH is a framework and family of computer simulators, initiated by 
> Bob Supnik and continued with contributions (large and small) from 
> many others, with the primary goal of enabling the preservation of 
> knowledge contained in, and providing the ability to 
> execute/experience, old/historic software via simulation of the 
> hardware on which it ran. This goal has been successfully achieved and 
> has for these years created a diverse community of users and developers.
>
> This has mapped to some core operational principles:
>
> First, preserve the ability to run old/historically significant 
> software. This means functionally accurate, sometimes bug-compatible, 
> but not cycle-accurate, simulation.
>
> Second, make it reasonably easy to add new simulators for other 
> hardware while leveraging common functions between the simulators.
>
> Third, exploit the software nature of simulation and make SIMH 
> convenient for debugging a simulated system, by adding non-historical 
> features to the environment.
>
> Fourth, make it convenient for users to explore old system 
> environments, with as close to historical interfaces, by mapping them 
> to new features that modern host operating systems provide.
>
> Fifth, be inclusive of people and new technology. It's serious work, 
> but it should be fun.
>
> Previously, we unfortunately never spent the time to codify how we 
> would deliver on these concepts. Rather, we have relied on an informal 
> use of traditional free and open-source principles.
>
> Recently a situation has arisen that compromises some of these 
> principles and thus the entire status of the project, creating 
> consternation among many users and contributors.
>
> For this reason, a number of us have stepped up to create a new 
> organizational structure, which we call "The Open SIMH Project", to be 
> the keeper and provide formal governance for the SIMH ecosystem going 
> forward.  While details of the structure and how it operates are 
> likely to be refined over time, what will not change is our commitment 
> to maintaining SIMH as a free and open-source project, licensed under 
> an MIT-style license as shown on the "simh" repository page.
>
> It is our desire that all of the past users and contributors will come 
> to recognize that the new organizational structure is in the best 
> interests of the community at large and that they will join us in it. 
> However, this iproject as defined, is where we intend to contribute 
> our expertise and time going forward.  At this point, we have in place 
> the following, although we foresee other resources being added in the 
> future as we identify the need and execute against them:
>
> A Github "organization" for the project at https://github.com/open-simh
>
> A Git repository for the simulators themselves at 
> https://github.com/open-simh/simh
>
> The license for the SIMH simulator code base, found in LICENSE.txt in 
> the top level of the "simh" repository.
>
> The "SIMH related tools" in https://github.com/open-simh/simtools. 
> This is also licensed under MIT style or BSD style open source 
> licenses (which are comparable apart from some minor wording differences).
>
> A "SIMH Steering Group" -- project maintainers and guides.
>
> The conventional git style process is used for code contributions, via 
> pull request to the project repository. The Steering Group members 
> have approval authority; this list is likely to change and grow over time.
>
> By formalizing the underlying structure, our operational principles 
> and guidance can best benefit the community. These are being developed 
> and formalized, with a plan to publish them soon.
>
> We have used our best judgment in setting up this structure but are 
> open to discussion and consideration of other ideas, and to making 
> improvements. Many of us have been part of different projects and 
> understand that past mistakes are real. We have tried to learn from 
> these experiences and apply the collected wisdom appropriately. We 
> desire to hear from the community as we update and refine the 
> operating structure for the Open SIMH project.
>
> We hope for your patience and look forward to your support as we work 
> to refine the organization and be able to provide this wonderful 
> resource for anyone to use as we continue to evolve the technology 
> provided by the SIMH system.
>
>      The SIMH Steering Group
>         Clem Cole
>         Richard Cornwell
>         Paul Koning
>         Timothe Litt
>         Seth Morabito
>         Bob Supnik
>
>
> ᐧ
> ᐧ
> ᐧ

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

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

* [TUHS] Re: [simh] Announcing the Open SIMH project
  2022-06-03 20:52       ` Will Senn
@ 2022-06-03 21:06         ` Adam Thornton
  2022-06-04  9:09           ` Ralph Corderoy
  0 siblings, 1 reply; 57+ messages in thread
From: Adam Thornton @ 2022-06-03 21:06 UTC (permalink / raw)
  To: Will Senn; +Cc: The Eunuchs Hysterical Society


> On Jun 3, 2022, at 1:52 PM, Will Senn <will.senn@gmail.com> wrote:
> 
> Hear! Hear! I'd say it's about time, but that might be impolitic. This is fantastic news and bodes well for my favorite sim's future.
> 

The fact that Bob Supnik is onboard with this is really what I needed to know, not having followed the controversy.

While we're at it, can we make "make test" a separate target (I know, I know, and I *do* know how to submit a PR)?  I run a lot of stuff on Pi on simh and rebuilding takes a really, really long time (sure, I *could* cross-compile, but I don't), a large portion of which is running the test suite for every build.

Adam


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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 20:23       ` G. Branden Robinson
@ 2022-06-03 21:06         ` Clem Cole
  2022-06-03 21:20           ` Tom Ivar Helbekkmo via TUHS
  2022-06-03 21:35         ` Ben Walton
  1 sibling, 1 reply; 57+ messages in thread
From: Clem Cole @ 2022-06-03 21:06 UTC (permalink / raw)
  To: G. Branden Robinson; +Cc: The Eunuchs Hysterical Society

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

On Fri, Jun 3, 2022 at 4:23 PM G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> At 2022-06-03T16:00:15-0400, Clem Cole wrote:
> > Recently a situation has arisen that compromises some of these
> principles
> > and thus the entire status of the project, creating consternation among
> > many users and contributors.
>

Some of us on this list remember the original BDSi fight, the 386BSD to
FreeBSD, then NetBSD and OpenBSD (I was friends with both sides of many of
these wars).  You mentioned some others, which I was also a witness to.

Sadly, because we are people, people have egos and we are all somewhat
flawed, this is not a new thing.

The specific events really do not matter, as much as we realized that the
governance of a project like this needs to be a tad more structured.  The
"benevolent dictator for life" (BDFL) model only works if the subject is
willing to accept her/him, and he/she truly tries to act in the best
interest of the whole.   We have examples of that model working in a few
cases, and we have examples as you pointed out, where it has failed.

> Previously, we unfortunately never spent the time to codify how we would
> deliver on these concepts. Rather, we have relied on an informal use of
> traditional free and open-source principles.


The leaders of the Steering Group have been (and I expect will continue to)
"burning a lot of midnight oil" hashing this out -> what worked, works,
what has not.  Looking at other large distributed projects, with a
particular focus on FOSS-based ones, that have been modeled using a BSD
style license (the traditional license for simh) which are made up of
fellow travelers with diverse interests.  We have tried to come up with
what we think can work for us as a community.  That is to say, we also have
some excellent examples of a governance model more appropriate to where the
simh community is at this time.

> We have used our best judgment in setting up this structure but are open
> to discussion and consideration of other ideas, and to making improvements.
> Many of us have been part of different projects and understand that past
> mistakes are real. We have tried to learn from these experiences and apply
> the collected wisdom appropriately. We desire to hear from the community as
> we update and refine the operating structure for the Open SIMH project.

The point is  *we don't want to have the project splinter*, but rather
continue to be broadly available to everyone - rather we are trying to *bring
it back together.*  This action is defining what the mainline is, and
formalizing the governance to help make this real.   It also is/had been a
time for us to examine IP ownership, license status, *etc*.   For instance,
the simtools directory contained non-BSD style license technology.  We
started to ask the question of what is the best way we can handle that.

My own take is I would hate to see something good harmed, as an
unintended consequence.  I suspect the other members of the Steering group
feel similarly.  We have taken a specific action that we hope can become
the force to stabilize and clear up any ambiguity that previous structures
might have allowed and provide a way for changes to be considered by the
community in a manner that will be more acceptable to other organizations
-- for instance, the Linux distros want a more formal released process,
which we have not had (for good reasons BTW).

*Good cooking takes time* - please bear with us, but we are here to listen
and consider different ideas.

Clem Cole

member, SIMH Steering Group

By changing some of these details now

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 21:06         ` Clem Cole
@ 2022-06-03 21:20           ` Tom Ivar Helbekkmo via TUHS
  2022-06-03 21:32             ` Larry McVoy
  2022-06-03 22:19             ` Warner Losh
  0 siblings, 2 replies; 57+ messages in thread
From: Tom Ivar Helbekkmo via TUHS @ 2022-06-03 21:20 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

Clem Cole <clemc@ccc.com> writes:

> Some of us on this list remember the original BDSi fight, the 386BSD
> to FreeBSD, then NetBSD and OpenBSD (I was friends with both sides of
> many of these wars).

Irrelevant to the topic, I know, but I'd just like to point out, since
you call these things "wars", that NetBSD grew out of 386bsd in a quiet,
friendly fashion, and then FreeBSD out of NetBSD just as quietly.  (BSDi
growing out of 386bsd was a completely separate affair that I know very
little about, and the OpenBSD fork from NetBSD was mostly just a
personal animosity thing, Theo de Raadt having made enemies in both the
NetBSD and FreeBSD camps -- but it has left no bad blood behind it.)

In other words, no wars that I know of.

That being said, I sincerely wish you all the best working out a
solution that can allow the amazingly good simh project to continue!

-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] 57+ messages in thread

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 21:20           ` Tom Ivar Helbekkmo via TUHS
@ 2022-06-03 21:32             ` Larry McVoy
  2022-06-03 21:34               ` Tom Ivar Helbekkmo via TUHS
                                 ` (2 more replies)
  2022-06-03 22:19             ` Warner Losh
  1 sibling, 3 replies; 57+ messages in thread
From: Larry McVoy @ 2022-06-03 21:32 UTC (permalink / raw)
  To: Tom Ivar Helbekkmo; +Cc: The Eunuchs Hysterical Society

On Fri, Jun 03, 2022 at 11:20:58PM +0200, Tom Ivar Helbekkmo via TUHS wrote:
> Clem Cole <clemc@ccc.com> writes:
> 
> > Some of us on this list remember the original BDSi fight, the 386BSD
> > to FreeBSD, then NetBSD and OpenBSD (I was friends with both sides of
> > many of these wars).
> 
> Irrelevant to the topic, I know, but I'd just like to point out, since
> you call these things "wars", that NetBSD grew out of 386bsd in a quiet,
> friendly fashion, and then FreeBSD out of NetBSD just as quietly.  (BSDi
> growing out of 386bsd was a completely separate affair that I know very
> little about, and the OpenBSD fork from NetBSD was mostly just a
> personal animosity thing, Theo de Raadt having made enemies in both the
> NetBSD and FreeBSD camps -- but it has left no bad blood behind it.)
> 
> In other words, no wars that I know of.

Umm, were you there?  I was a BSD guy before I turned to Linux and I
turned to Linux because of those wars.  There is no good reason to have
{386,Free,Net,Open,DragonFly}bsd other than, as Linus stated, "Nobody
could decide who would drive the big red fire truck so now they each
have their own toy fire truck that they drive around".

BSD would have won if there was a Linus for BSD.  There was not so you
got all this replicated effort, the BSD community effectively divided
and conquered themselves.

It was, and is, a train wreck.  It's the poster child for how not to
manage a project.

I did BitKeeper for Linus because he refused to use any crappy source
management solution and people like Dave Miller were threatening to
fork just so they had some solution.  I did that because a forked Linux
would turn into the same mess of {386,Free,Net,Open,DragonFly}bsd which
is obviously not remotely close to ideal.  Far from it.

I lived through all of that, I was an active kernel developer at Sun, 
SGI and elsewhere.  I would have loved to have seen the SunOS VM system
ported to 4.x BSD and that been the default answer for a kernel.  Instead
we got Linux, which has it's positive points for sure, but it also has
decided to let every feature imaginable into the kernel.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 21:32             ` Larry McVoy
@ 2022-06-03 21:34               ` Tom Ivar Helbekkmo via TUHS
  2022-06-03 21:37                 ` Larry McVoy
  2022-06-03 21:36               ` Tom Ivar Helbekkmo via TUHS
  2022-06-03 22:26               ` Warner Losh
  2 siblings, 1 reply; 57+ messages in thread
From: Tom Ivar Helbekkmo via TUHS @ 2022-06-03 21:34 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

Larry McVoy <lm@mcvoy.com> writes:

>> In other words, no wars that I know of.
>
> Umm, were you there?

Yes, I was.  Otherwise, I would not have presumed to comment.

-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] 57+ messages in thread

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 20:23       ` G. Branden Robinson
  2022-06-03 21:06         ` Clem Cole
@ 2022-06-03 21:35         ` Ben Walton
  1 sibling, 0 replies; 57+ messages in thread
From: Ben Walton @ 2022-06-03 21:35 UTC (permalink / raw)
  To: G. Branden Robinson; +Cc: The Eunuchs Hysterical Society

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

On Fri 3 Jun 2022, 21:23 G. Branden Robinson, <g.branden.robinson@gmail.com>
wrote:

> At 2022-06-03T16:00:15-0400, Clem Cole wrote:
> > Recently a situation has arisen that compromises some of these principles
> > and thus the entire status of the project, creating consternation among
> > many users and contributors.
>
> I wonder if that issue would be the one referred to here.
>
> https://twitter.com/the_aiju/status/1526921795139514368
>
> (I understand if Clem doesn't want to directly answer that.)
>
> It's probably impolitic to reference that matter, and if I'm right
> that's no doubt why reference to same was omitted from the announcement
> email.  It is traditional for such statements to be high-minded even if
> they wouldn't be necessary but for the rather low conduct that compels
> their issue in response.
>
> The above situation seems similar to others we've seen before.  It's
> probably even more impolitic to note that in the Debian Project, this
> sort of licensing shenangians would be referred to as "pulling a Jörg
> Schilling"[1].
>

This stuck a chord for me this evening. I completely understand why such a
saying would come into being, having watched things like cdrecord as a
young person - I totally get the view on licenses here. But I had a chance
to work with Jörg, if only tangentially, on a project and found him to be
warm, engaging, brilliant and overall quite pleasant. I was in a unique
position to connect Jörg and Henry (yes, that Henry) to talk about some old
Unix arcana and it was magic to witness. I hope that in addition to Jörg's
eccentricities people also remember how neat he was as a person. He was a
brilliant mind.

Thanks
-Ben


> I expect that time will soon tell whether an even better term would be
> "committing an XFree86".
>
> On a positive note, I'd like to express my thanks to the SIMH
> contributors past and present for making it straightforward to verify
> the behavior Unix V7 troff in my development work on groff.
>
> If Open SIMH remains dedicated to software freedom in the GNU and DFSG
> senses I expect it will enjoy overwhelming support.
>
> Cheers,
> Branden
>
> [1] https://lwn.net/Articles/195167/
>

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 21:32             ` Larry McVoy
  2022-06-03 21:34               ` Tom Ivar Helbekkmo via TUHS
@ 2022-06-03 21:36               ` Tom Ivar Helbekkmo via TUHS
  2022-06-03 21:40                 ` Larry McVoy
  2022-06-03 22:26               ` Warner Losh
  2 siblings, 1 reply; 57+ messages in thread
From: Tom Ivar Helbekkmo via TUHS @ 2022-06-03 21:36 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

Larry McVoy <lm@mcvoy.com> writes:

> BSD would have won if there was a Linus for BSD.  There was not so you
> got all this replicated effort, the BSD community effectively divided
> and conquered themselves.

I do not agree.  Linux won because BSD was embroiled in litigation.

-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] 57+ messages in thread

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 21:34               ` Tom Ivar Helbekkmo via TUHS
@ 2022-06-03 21:37                 ` Larry McVoy
  0 siblings, 0 replies; 57+ messages in thread
From: Larry McVoy @ 2022-06-03 21:37 UTC (permalink / raw)
  To: Tom Ivar Helbekkmo; +Cc: The Eunuchs Hysterical Society

On Fri, Jun 03, 2022 at 11:34:21PM +0200, Tom Ivar Helbekkmo wrote:
> Larry McVoy <lm@mcvoy.com> writes:
> 
> >> In other words, no wars that I know of.
> >
> > Umm, were you there?
> 
> Yes, I was.  Otherwise, I would not have presumed to comment.

Fair enough, we obviously experienced that differently.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 21:36               ` Tom Ivar Helbekkmo via TUHS
@ 2022-06-03 21:40                 ` Larry McVoy
  2022-06-03 22:16                   ` Tom Ivar Helbekkmo via TUHS
  0 siblings, 1 reply; 57+ messages in thread
From: Larry McVoy @ 2022-06-03 21:40 UTC (permalink / raw)
  To: Tom Ivar Helbekkmo; +Cc: The Eunuchs Hysterical Society

On Fri, Jun 03, 2022 at 11:36:07PM +0200, Tom Ivar Helbekkmo wrote:
> Larry McVoy <lm@mcvoy.com> writes:
> 
> > BSD would have won if there was a Linus for BSD.  There was not so you
> > got all this replicated effort, the BSD community effectively divided
> > and conquered themselves.
> 
> I do not agree.  Linux won because BSD was embroiled in litigation.

Like I said, we experienced that differently.  In my opinion, people lean
on the litigation excuse when they don't want to admit that *BSD was not
a good way to do operating system development.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 21:40                 ` Larry McVoy
@ 2022-06-03 22:16                   ` Tom Ivar Helbekkmo via TUHS
  2022-06-03 22:30                     ` Larry McVoy
  2022-06-03 22:33                     ` Warner Losh
  0 siblings, 2 replies; 57+ messages in thread
From: Tom Ivar Helbekkmo via TUHS @ 2022-06-03 22:16 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

Larry McVoy <lm@mcvoy.com> writes:

>> I do not agree.  Linux won because BSD was embroiled in litigation.
>
> Like I said, we experienced that differently.  In my opinion, people lean
> on the litigation excuse when they don't want to admit that *BSD was not
> a good way to do operating system development.

What were the differences?  The BSD projects were:

- 386bsd: run by Jolitz, with no input from anyone else
- NetBSD: forked from 386bsd, run by Chris de Metriou as a
  cooperative effort between a host of indviduals (me included)
- FreeBSD: forked from NetBSD almost immediately, by a group of
  contributors who felt that performance and device support on the Intel
  platform was more important than maintaining hardware portability
- OpenBSD: forked from NetBSD after de Raadt established a kind of
  record by being kicked off both the NetBSD and FreeBSD mailing lists.

I'm open to contradicting arguments, but I do feel that the BSD platform
was a much better starting point back then, and ought to have won - but
Linux, while inferior, was available and non-threatening.

-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] 57+ messages in thread

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 21:20           ` Tom Ivar Helbekkmo via TUHS
  2022-06-03 21:32             ` Larry McVoy
@ 2022-06-03 22:19             ` Warner Losh
  1 sibling, 0 replies; 57+ messages in thread
From: Warner Losh @ 2022-06-03 22:19 UTC (permalink / raw)
  To: Tom Ivar Helbekkmo; +Cc: The Eunuchs Hysterical Society

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

On Fri, Jun 3, 2022 at 3:21 PM Tom Ivar Helbekkmo via TUHS <tuhs@tuhs.org>
wrote:

> Clem Cole <clemc@ccc.com> writes:
>
> > Some of us on this list remember the original BDSi fight, the 386BSD
> > to FreeBSD, then NetBSD and OpenBSD (I was friends with both sides of
> > many of these wars).
>
> Irrelevant to the topic, I know, but I'd just like to point out, since
> you call these things "wars", that NetBSD grew out of 386bsd in a quiet,
> friendly fashion, and then FreeBSD out of NetBSD just as quietly.  (BSDi
> growing out of 386bsd was a completely separate affair that I know very
> little about, and the OpenBSD fork from NetBSD was mostly just a
> personal animosity thing, Theo de Raadt having made enemies in both the
> NetBSD and FreeBSD camps -- but it has left no bad blood behind it.)
>

My recollection was that FreeBSD grew out of the patch kits in parallel to
NetBSD
growing out of the patch kits, but with the CVS repos hosted on the same
host
before each project got their own hosting...  The CVS history shows FreeBSD
started with NET/2 and then added in the patchkit changes added to it. I
know that
the family tree file says otherwise, but I've not seen convincing evidence
that is
really how things happened (either as an outsider observing at the time, nor
via extant artifacts that would show such a relationship). NetBSD did ship
their
first release before FreeBSD, however.

My recollection from the time of the collegiality of the split differs
somewhat
from yours, however.


> In other words, no wars that I know of.
>

There were a number of shenanigans (like moving the license text to the
end of files) at the time. And you never got a call at 4am from Theo
demanding
that you stop a FreeBSD user from saying bad things about OpenBSD... So
maybe
not "wars," as such, but it wasn't all sweetness and light...


> That being said, I sincerely wish you all the best working out a
> solution that can allow the amazingly good simh project to continue!
>

Yes. This looks nothing at all like the early BSD days. this looks to be a
proactive
attempt to take the sprawling number of forks that have happened and bring
some
order to it so that they don't proliferate too much. As a long-time open
source
governance wonk in the FreeBSD project, I like what I see.

Warner


> -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
>

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 21:32             ` Larry McVoy
  2022-06-03 21:34               ` Tom Ivar Helbekkmo via TUHS
  2022-06-03 21:36               ` Tom Ivar Helbekkmo via TUHS
@ 2022-06-03 22:26               ` Warner Losh
  2 siblings, 0 replies; 57+ messages in thread
From: Warner Losh @ 2022-06-03 22:26 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

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

On Fri, Jun 3, 2022 at 3:32 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Fri, Jun 03, 2022 at 11:20:58PM +0200, Tom Ivar Helbekkmo via TUHS
> wrote:
> > Clem Cole <clemc@ccc.com> writes:
> >
> > > Some of us on this list remember the original BDSi fight, the 386BSD
> > > to FreeBSD, then NetBSD and OpenBSD (I was friends with both sides of
> > > many of these wars).
> >
> > Irrelevant to the topic, I know, but I'd just like to point out, since
> > you call these things "wars", that NetBSD grew out of 386bsd in a quiet,
> > friendly fashion, and then FreeBSD out of NetBSD just as quietly.  (BSDi
> > growing out of 386bsd was a completely separate affair that I know very
> > little about, and the OpenBSD fork from NetBSD was mostly just a
> > personal animosity thing, Theo de Raadt having made enemies in both the
> > NetBSD and FreeBSD camps -- but it has left no bad blood behind it.)
> >
> > In other words, no wars that I know of.
>
> Umm, were you there?  I was a BSD guy before I turned to Linux and I
> turned to Linux because of those wars.  There is no good reason to have
> {386,Free,Net,Open,DragonFly}bsd other than, as Linus stated, "Nobody
> could decide who would drive the big red fire truck so now they each
> have their own toy fire truck that they drive around".
>
> BSD would have won if there was a Linus for BSD.  There was not so you
> got all this replicated effort, the BSD community effectively divided
> and conquered themselves.
>
> It was, and is, a train wreck.  It's the poster child for how not to
> manage a project.
>
> I did BitKeeper for Linus because he refused to use any crappy source
> management solution and people like Dave Miller were threatening to
> fork just so they had some solution.  I did that because a forked Linux
> would turn into the same mess of {386,Free,Net,Open,DragonFly}bsd which
> is obviously not remotely close to ideal.  Far from it.
>

386BSD died because its founder couldn't deal with collaboration. He tried
to
be dictator and that failed because he didn't accept other people's
collaboration
out of worries he couldn't sell 386BSD. NetBSD and FreeBSD took up the
charge
for a free and open system. I'll agree it was unfortunate that there was a
split
since NetBSD focused on portability and FreeBSD focused on fastest possible
i386/i486 code. I'd suggest, though, that the USL lawsuit cast a huge pall
on
things and introduced enough uncertainty to further derail things. Had it
not
been for that additional blow, things would have turned out differently.

OpenBSD and Dragonfly BSD didn't split until years later and also
represented differences of opinion on where to take the focus of the
system (OpenBSD thought the NetBSD folks didn't take security seriously
enough and the DFBSD folks thought the efforts to make a parallel kernel
in FreeBSD were off track and should be done completely differently).


> I lived through all of that, I was an active kernel developer at Sun,
> SGI and elsewhere.  I would have loved to have seen the SunOS VM system
> ported to 4.x BSD and that been the default answer for a kernel.  Instead
> we got Linux, which has it's positive points for sure, but it also has
> decided to let every feature imaginable into the kernel.
>

We wound up with MACH in BSD because when Sun tried to donate their
VM code to Berkeley, the corporate lawyers said no. It was giving away too
much shareholder value, and would result in a huge write-off which would,
one would presume, negatively affect the stock price. Had this donation
actually transpired, 386BSD would have had a bigger advantage from the
get go... Oh well

Warner

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 22:16                   ` Tom Ivar Helbekkmo via TUHS
@ 2022-06-03 22:30                     ` Larry McVoy
  2022-06-03 22:52                       ` Warner Losh
  2022-06-03 22:33                     ` Warner Losh
  1 sibling, 1 reply; 57+ messages in thread
From: Larry McVoy @ 2022-06-03 22:30 UTC (permalink / raw)
  To: Tom Ivar Helbekkmo; +Cc: The Eunuchs Hysterical Society

On Sat, Jun 04, 2022 at 12:16:49AM +0200, Tom Ivar Helbekkmo wrote:
> Larry McVoy <lm@mcvoy.com> writes:
> 
> >> I do not agree.  Linux won because BSD was embroiled in litigation.
> >
> > Like I said, we experienced that differently.  In my opinion, people lean
> > on the litigation excuse when they don't want to admit that *BSD was not
> > a good way to do operating system development.
> 
> What were the differences?  The BSD projects were:
> 
> - 386bsd: run by Jolitz, with no input from anyone else
> - NetBSD: forked from 386bsd, run by Chris de Metriou as a
>   cooperative effort between a host of indviduals (me included)
> - FreeBSD: forked from NetBSD almost immediately, by a group of
>   contributors who felt that performance and device support on the Intel
>   platform was more important than maintaining hardware portability
> - OpenBSD: forked from NetBSD after de Raadt established a kind of
>   record by being kicked off both the NetBSD and FreeBSD mailing lists.
> 
> I'm open to contradicting arguments, but I do feel that the BSD platform
> was a much better starting point back then, and ought to have won - but
> Linux, while inferior, was available and non-threatening.

Dude, I was there.  Jolitz used to work for me at Sun, Theo's Sun 4/470
was given to him by me, I know most of the players.

I agree BSD was a better starting point if there was one BSD.

The problem is there was {386,Net,Free,Open,DragonFly}BSD where there
should have just been "BSD".  One, not a bunch.

Where do you think Linux would be if there was {A,B,C,D,E,F,G}Linux?
There is one kernel.  One and only one.  With everyone working on that
one kernel.

If you can't see the difference, I don't know what to tell you.  Are you
seriously going to take the position that BSD is better off because
it has all these variants and replicated effort?  Because if you are,
this conversation is over, at least from my point of view.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 22:16                   ` Tom Ivar Helbekkmo via TUHS
  2022-06-03 22:30                     ` Larry McVoy
@ 2022-06-03 22:33                     ` Warner Losh
  2022-06-03 22:40                       ` Tom Ivar Helbekkmo via TUHS
  1 sibling, 1 reply; 57+ messages in thread
From: Warner Losh @ 2022-06-03 22:33 UTC (permalink / raw)
  To: Tom Ivar Helbekkmo; +Cc: The Eunuchs Hysterical Society

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

On Fri, Jun 3, 2022 at 4:17 PM Tom Ivar Helbekkmo via TUHS <tuhs@tuhs.org>
wrote:

> Larry McVoy <lm@mcvoy.com> writes:
>
> >> I do not agree.  Linux won because BSD was embroiled in litigation.
> >
> > Like I said, we experienced that differently.  In my opinion, people lean
> > on the litigation excuse when they don't want to admit that *BSD was not
> > a good way to do operating system development.
>
> What were the differences?  The BSD projects were:
>
> - 386bsd: run by Jolitz, with no input from anyone else
> - NetBSD: forked from 386bsd, run by Chris de Metriou as a
>   cooperative effort between a host of indviduals (me included)
> - FreeBSD: forked from NetBSD almost immediately, by a group of
>   contributors who felt that performance and device support on the Intel
>   platform was more important than maintaining hardware portability
>

The FreeBSD 1.x CVS tree shows that it started from NET/2 with the
patchkit added on. It didn't start from the NetBSD tree that I've been
able to find (and I've studied the early CVS history for the git migration
extensively). And oral history from many of the founders who were
also patchkit contributors also matches this recounting... Though I
guess a lot turns on whether you consider the patchkit early NetBSD
or not...

I do agree with the rest of this, though.


> - OpenBSD: forked from NetBSD after de Raadt established a kind of
>   record by being kicked off both the NetBSD and FreeBSD mailing lists.
>

OpenBSD forked from NetBSD after Theo had a personality dispute with
the NetBSD folks. It had little to do with the FreeBSD lists judging from
his email at the time and my early interactions with that project.

Warner

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 22:33                     ` Warner Losh
@ 2022-06-03 22:40                       ` Tom Ivar Helbekkmo via TUHS
  2022-06-03 22:56                         ` Warner Losh
  0 siblings, 1 reply; 57+ messages in thread
From: Tom Ivar Helbekkmo via TUHS @ 2022-06-03 22:40 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

Warner Losh <imp@bsdimp.com> writes:

> The FreeBSD 1.x CVS tree shows that it started from NET/2 with the
> patchkit added on. It didn't start from the NetBSD tree that I've been
> able to find (and I've studied the early CVS history for the git
> migration extensively).

Yeah, I guess it might be better to say that after Chris took the
initiative to create a fork, which he named NetBSD, of Jolitz's 386bsd,
it was decided that there would be two forks; NetBSD and FreeBSD, with
slightly differing objectives.

-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] 57+ messages in thread

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 22:30                     ` Larry McVoy
@ 2022-06-03 22:52                       ` Warner Losh
  2022-06-03 23:48                         ` Larry McVoy
  2022-06-03 23:56                         ` David Arnold
  0 siblings, 2 replies; 57+ messages in thread
From: Warner Losh @ 2022-06-03 22:52 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

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

On Fri, Jun 3, 2022 at 4:30 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Sat, Jun 04, 2022 at 12:16:49AM +0200, Tom Ivar Helbekkmo wrote:
> > Larry McVoy <lm@mcvoy.com> writes:
> >
> > >> I do not agree.  Linux won because BSD was embroiled in litigation.
> > >
> > > Like I said, we experienced that differently.  In my opinion, people
> lean
> > > on the litigation excuse when they don't want to admit that *BSD was
> not
> > > a good way to do operating system development.
> >
> > What were the differences?  The BSD projects were:
> >
> > - 386bsd: run by Jolitz, with no input from anyone else
> > - NetBSD: forked from 386bsd, run by Chris de Metriou as a
> >   cooperative effort between a host of indviduals (me included)
> > - FreeBSD: forked from NetBSD almost immediately, by a group of
> >   contributors who felt that performance and device support on the Intel
> >   platform was more important than maintaining hardware portability
> > - OpenBSD: forked from NetBSD after de Raadt established a kind of
> >   record by being kicked off both the NetBSD and FreeBSD mailing lists.
> >
> > I'm open to contradicting arguments, but I do feel that the BSD platform
> > was a much better starting point back then, and ought to have won - but
> > Linux, while inferior, was available and non-threatening.
>
> Dude, I was there.  Jolitz used to work for me at Sun, Theo's Sun 4/470
> was given to him by me, I know most of the players.
>
> I agree BSD was a better starting point if there was one BSD.
>
> The problem is there was {386,Net,Free,Open,DragonFly}BSD where there
> should have just been "BSD".  One, not a bunch.
>

Except from 1993-1996 there were only two of those BSDs. NetBSD and FreeBSD
forked in 1993 due to the inability of the patchkit to adequately cover the
problems
in 386BSD governance. OpenBSD didn't fork until late 1995 or early 1996
depending
on when you count such things (Theo's firey email, or the first release).
Drangonfly BSD
didn't fork until a decade later in 2004 due to a dispute in how to make
FreeBSD's
kernel SMP. And 386BSD stopped being a thing in 1993 when Jolitz disappeared
from public view and NetBSD/FreeBSD filled the free vacuum that created and
BSDi with BSD/386 filled the commercial space.


> Where do you think Linux would be if there was {A,B,C,D,E,F,G}Linux?
> There is one kernel.  One and only one.  With everyone working on that
> one kernel.
>

Except there never really was only one kernel. There have been hundreds
of forks of the Linux kernel over the years. Most of them have been
commercial
of some flavor (Redhat, Debian, OpenSUSE, MontaVista, WindRiver, Android
etc)
had hundreds or thousands of patches on the base Linux kernel for a long
time
and trying to move from one to another if you also had patches was a
nightmare.

Kernel.org has kept going, and many of the chanages from these systems were
lost.
Some were not as good as what came in upstream, while others were encumbered
by commercial contracts that made them unappealing to upstream. True, many
of
them did wind up in kernel.org, but to say there aren't forks in Linux is
stretching
reality a bit...


> If you can't see the difference, I don't know what to tell you.  Are you
> seriously going to take the position that BSD is better off because
> it has all these variants and replicated effort?  Because if you are,
> this conversation is over, at least from my point of view.
>

I think Linux's greatest strengths were the different distributions, though
at times it causes a great deal of duplicated effort. They allowed
different communities
the room to customize things in an easy way. I believe that, more than one
kernel,
has been a driver of innovation.

But honestly, the litigation was a deal killer for many BSD users in the
early days,
and that gave Linux room to grow. Had the BSDs not faced the competition
from Linux
and had similar resources poured into them, the NetBSD/FreeBSD split would
have
been good competition, much as there's good competition between Debian,
Redhat, Suse,
Canonical, etc today in the Linux space which helps to drive innovation.

Even today, with the benefit of hindsight, it's hard to pin which of these
facts on
the ground was the biggest driver for most people...

Warner

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 22:40                       ` Tom Ivar Helbekkmo via TUHS
@ 2022-06-03 22:56                         ` Warner Losh
  0 siblings, 0 replies; 57+ messages in thread
From: Warner Losh @ 2022-06-03 22:56 UTC (permalink / raw)
  To: Tom Ivar Helbekkmo; +Cc: The Eunuchs Hysterical Society

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

On Fri, Jun 3, 2022 at 4:40 PM Tom Ivar Helbekkmo <tih@hamartun.priv.no>
wrote:

> Warner Losh <imp@bsdimp.com> writes:
>
> > The FreeBSD 1.x CVS tree shows that it started from NET/2 with the
> > patchkit added on. It didn't start from the NetBSD tree that I've been
> > able to find (and I've studied the early CVS history for the git
> > migration extensively).
>
> Yeah, I guess it might be better to say that after Chris took the
> initiative to create a fork, which he named NetBSD, of Jolitz's 386bsd,
> it was decided that there would be two forks; NetBSD and FreeBSD, with
> slightly differing objectives.
>

Yea, there were a number of folks that contributed to the patchkit as
well. Chris did a good thing to try to bring order to that chaos, there is
no doubt, but Nate Williams, Paul Richards and others were big contributors
to the patchkit and the lines of what happened where were somewhat
blurry at the time as people discovered they were working at cross purposes
and/or had issues working with some people....

Thankfully, for the most part the high levels of animosity that developed in
the early 90s between the BSD projects have largely faded away as new
groups of developers have joined the projects...

Warner

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 22:52                       ` Warner Losh
@ 2022-06-03 23:48                         ` Larry McVoy
  2022-06-04  0:10                           ` Warner Losh
  2022-06-03 23:56                         ` David Arnold
  1 sibling, 1 reply; 57+ messages in thread
From: Larry McVoy @ 2022-06-03 23:48 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

On Fri, Jun 03, 2022 at 04:52:52PM -0600, Warner Losh wrote:
> > The problem is there was {386,Net,Free,Open,DragonFly}BSD where there
> > should have just been "BSD".  One, not a bunch.
> >
> 
> Except from 1993-1996 there were only two of those BSDs. NetBSD and FreeBSD
> forked in 1993 due to the inability of the patchkit to adequately cover the
> problems
> in 386BSD governance. 

Um, so there were 3: 386, Net and Free.  That's already 2 too many.

> > Where do you think Linux would be if there was {A,B,C,D,E,F,G}Linux?
> > There is one kernel.  One and only one.  With everyone working on that
> > one kernel.
> 
> Except there never really was only one kernel. There have been hundreds
> of forks of the Linux kernel over the years. Most of them have been
> commercial
> of some flavor (Redhat, Debian, OpenSUSE, MontaVista, WindRiver, Android
> etc)
> had hundreds or thousands of patches on the base Linux kernel for a long
> time
> and trying to move from one to another if you also had patches was a
> nightmare.

So I had a successful commercial product that ran on all of those variants
without issue.  I supported linux on everything from ARM to IBM's z-system
mainframes and all the arches inbetween.  I think I have one #ifdef SPARC
in there because there was a cache flush bug but that was a hardware issue,
not a software issue.

I also supported {Free,Net,Open}BSD and I had way more problems with them
than I did with Linux.

> Kernel.org has kept going, and many of the chanages from these systems were
> lost.
> Some were not as good as what came in upstream, while others were encumbered
> by commercial contracts that made them unappealing to upstream. True, many
> of
> them did wind up in kernel.org, but to say there aren't forks in Linux is
> stretching
> reality a bit...

There is one kernel development stream that matters.  RedHat knows that
if they don't get their stuff into Linus' tree, they have a nightmare
on their hands.  That's why RedHat paid so many of the kernel developers.

Sure, there are forks, but there is one tree that matters, and that is 
Linus' tree.  You can't say that about BSD and that is the problem in
it's entirety.  If I want to change BSD, which one?

> Even today, with the benefit of hindsight, it's hard to pin which of these
> facts on the ground was the biggest driver for most people...

For me, I gave up when there was no longer one BSD, there was one Linux.

--lm

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 22:52                       ` Warner Losh
  2022-06-03 23:48                         ` Larry McVoy
@ 2022-06-03 23:56                         ` David Arnold
  2022-06-04  0:30                           ` Yeechang Lee
  1 sibling, 1 reply; 57+ messages in thread
From: David Arnold @ 2022-06-03 23:56 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

> On 4 Jun 2022, at 08:52, Warner Losh <imp@bsdimp.com> wrote:

< … >

> But honestly, the litigation was a deal killer for many BSD users in the early days,
> and that gave Linux room to grow. Had the BSDs not faced the competition from Linux
> and had similar resources poured into them, the NetBSD/FreeBSD split would have
> been good competition, much as there's good competition between Debian, Redhat, Suse,
> Canonical, etc today in the Linux space which helps to drive innovation.
> 
> Even today, with the benefit of hindsight, it's hard to pin which of these facts on
> the ground was the biggest driver for most people…

Anecdata:

I’d had exposure to HP/UX and SunOS at university, and I used Minix (installed from a stack of floppies) on my 80286 PC at home.  At some point I accidentally dd’d over the DOS partition, and Minix became my primary OS for a year or so.

I was an avid DDJ reader (RIP) and so I’d seen the 386BSD series, but I couldn’t get a hold of the code for some time.  IIRC, my usual method was to FTP each floppy image to my university account (with brutal storage quotas), and then pull it down to my PC to write out locally.  I had an early copy of either FreeBSD or NetBSD (can’t recall which), but I think at that stage it demanded complete ownership of the hard disk (and didn’t cope with PC-style MBR partition tables) and I didn’t have a spare HDD to put it on.  I also seem to recall some driver issue: I didn’t have a SCSI controller, and I think I recall a problem with my MFM (or was it early IDE) controller?

Linux floppies (MCC?  HJ Lu?) were much easier to come by: I borrowed a set from someone, and re-downloaded the corrupt ones, and was able to install Linux beside my existing Minix installation easily.  It was very flakey to start with, but in a relatively short time I had X running, and that was the end of Minix for me.

After university, I had jobs and money, and had various Free/Net/OpenBSD machines, but they typically lacked support for some iffy hardware I was using, and fairly quickly *BSD became a second-class platform for stuff like Netscape, and GPU drivers, and so on.

I think a similar pattern was true for many of my era (late 80’s/early 90’s).  It was quite a bit easier to get a Linux system running while retaining a DOS, Windows or Minix system as a backup, and so that was how it evolved.

It had nothing (directly) to do with the legal issues.





d


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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 23:48                         ` Larry McVoy
@ 2022-06-04  0:10                           ` Warner Losh
  2022-06-04  1:05                             ` Larry McVoy
  0 siblings, 1 reply; 57+ messages in thread
From: Warner Losh @ 2022-06-04  0:10 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

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

On Fri, Jun 3, 2022, 5:48 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Fri, Jun 03, 2022 at 04:52:52PM -0600, Warner Losh wrote:
> > > The problem is there was {386,Net,Free,Open,DragonFly}BSD where there
> > > should have just been "BSD".  One, not a bunch.
> > >
> >
> > Except from 1993-1996 there were only two of those BSDs. NetBSD and
> FreeBSD
> > forked in 1993 due to the inability of the patchkit to adequately cover
> the
> > problems
> > in 386BSD governance.
>
> Um, so there were 3: 386, Net and Free.  That's already 2 too many.
>

No. 386BSD died before then.

> > Where do you think Linux would be if there was {A,B,C,D,E,F,G}Linux?
> > > There is one kernel.  One and only one.  With everyone working on that
> > > one kernel.
> >
> > Except there never really was only one kernel. There have been hundreds
> > of forks of the Linux kernel over the years. Most of them have been
> > commercial
> > of some flavor (Redhat, Debian, OpenSUSE, MontaVista, WindRiver, Android
> > etc)
> > had hundreds or thousands of patches on the base Linux kernel for a long
> > time
> > and trying to move from one to another if you also had patches was a
> > nightmare.
>
> So I had a successful commercial product that ran on all of those variants
> without issue.  I supported linux on everything from ARM to IBM's z-system
> mainframes and all the arches inbetween.  I think I have one #ifdef SPARC
> in there because there was a cache flush bug but that was a hardware issue,
> not a software issue.
>
> I also supported {Free,Net,Open}BSD and I had way more problems with them
> than I did with Linux.
>
> > Kernel.org has kept going, and many of the chanages from these systems
> were
> > lost.
> > Some were not as good as what came in upstream, while others were
> encumbered
> > by commercial contracts that made them unappealing to upstream. True,
> many
> > of
> > them did wind up in kernel.org, but to say there aren't forks in Linux
> is
> > stretching
> > reality a bit...
>
> There is one kernel development stream that matters.  RedHat knows that
> if they don't get their stuff into Linus' tree, they have a nightmare
> on their hands.  That's why RedHat paid so many of the kernel developers.
>
> Sure, there are forks, but there is one tree that matters, and that is
> Linus' tree.  You can't say that about BSD and that is the problem in
> it's entirety.  If I want to change BSD, which one?
>

By your standards, only FreeBSD matters... so that's easy.. but you already
said Redhat is all that matters... and that kernel differs somewhat from
Linus'. Ditto if you are dealing with Android... it's not just one Linux
and never has been.

Warner

>

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-03 23:56                         ` David Arnold
@ 2022-06-04  0:30                           ` Yeechang Lee
  2022-06-04  1:03                             ` Adam Thornton
  0 siblings, 1 reply; 57+ messages in thread
From: Yeechang Lee @ 2022-06-04  0:30 UTC (permalink / raw)
  To: tuhs

David Arnold says:
> I think a similar pattern was true for many of my era (late
> 80’s/early 90’s). It was quite a bit easier to get a Linux system
> running while retaining a DOS, Windows or Minix system as a backup,
> and so that was how it evolved.
>
> It had nothing (directly) to do with the legal issues.

This is consistent with my experience. Until 1999 I used SunOS, then Solaris, as both student and student employee of Columbia's computing group. But I doubt that I would have installed SunOS at home even if free.

Linux, on the other hand, was seemingly everywhere: Shelves of books (some bundling a CD-ROM of some distribution) at bookstores, _Linux Journal_, Usenet discussions, online HOWTOs, others around me installing Linux at home and at work. BSD? It didn't get 10% of the mindshare.

Maybe that was a result of litigation, but I can 100% say for sure that my choosing in 1995 to go with Red Hat 2.1 for a brand new Pentium had nothing directly to do with any BSD-related litigation, because I wasn't aware of any such in the first place.

-- 
geo:37.783333,-122.416667

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-04  0:30                           ` Yeechang Lee
@ 2022-06-04  1:03                             ` Adam Thornton
  0 siblings, 0 replies; 57+ messages in thread
From: Adam Thornton @ 2022-06-04  1:03 UTC (permalink / raw)
  To: Yeechang Lee; +Cc: tuhs

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

The reason I started with Linux was exactly the BSD wanted my whole disk
problem.  I mean maybe it didn’t really but that was my impression and I
needed DOS/Windows 3.1 for some school stuff.

And then I had a lot to do with Linux on the mainframe and the OpenSolaris
port that would have been awesome if IBM and not Oracle had bought Sun.

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-04  0:10                           ` Warner Losh
@ 2022-06-04  1:05                             ` Larry McVoy
  2022-06-04  1:46                               ` David Arnold
  2022-06-06  0:32                               ` Theodore Ts'o
  0 siblings, 2 replies; 57+ messages in thread
From: Larry McVoy @ 2022-06-04  1:05 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

On Fri, Jun 03, 2022 at 06:10:46PM -0600, Warner Losh wrote:
> On Fri, Jun 3, 2022, 5:48 PM Larry McVoy <lm@mcvoy.com> wrote:
> 
> > On Fri, Jun 03, 2022 at 04:52:52PM -0600, Warner Losh wrote:
> > > > The problem is there was {386,Net,Free,Open,DragonFly}BSD where there
> > > > should have just been "BSD".  One, not a bunch.
> > > >
> > >
> > > Except from 1993-1996 there were only two of those BSDs. NetBSD and
> > FreeBSD
> > > forked in 1993 due to the inability of the patchkit to adequately cover
> > the
> > > problems
> > > in 386BSD governance.
> >
> > Um, so there were 3: 386, Net and Free.  That's already 2 too many.
> 
> No. 386BSD died before then.

Says you.  I was running it in at least 1995.

> > Sure, there are forks, but there is one tree that matters, and that is
> > Linus' tree.  You can't say that about BSD and that is the problem in
> > it's entirety.  If I want to change BSD, which one?
> >
> 
> By your standards, only FreeBSD matters... so that's easy.. but you already
> said Redhat is all that matters... and that kernel differs somewhat from
> Linus'. Ditto if you are dealing with Android... it's not just one Linux
> and never has been.

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.

Like I said, I built and supported a very complex application on all the
Linux platforms, all architectures, also supported on *BSD, HP-UX, AIX,
IRIX, SunOS, Solaris, Ultrix, etc, windows{xp,2000,2008,etc}, MacOS.
The problems I had between the various BSDs were orders of magnitude
bigger than the problems I had between the various Linux distros we
supported.

I will admit that we cloned NetBSD's stdio library because we needed
to make changes to it (we stacked CRC, XOR, gzip, lz4, etc on it). 
So we side stepped any stdio issues but for the rest we just made it
work.  

So my actual data trumps your opinion on this one.  The BSD splintered 
enough that they might as well have been IRIX and HP-UX, they weren't
as crazy as AIX, I think AIX wins crazy, but they were dramatically
more different, in subtle and annoying ways, than any Linux distro was.

My whole point is that if BSD had a focus, either a dictator or a 
steering committee that people like me would have followed, it would
have won.  It lost.  It sucks that it did, I'm a BSD guy in my core,
but BSD lost.  And it lost because of a failure in leadership.

You and the other BSD people don't like that message but it is what it
is.  BSD lost because Linux had better leadership.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-04  1:05                             ` Larry McVoy
@ 2022-06-04  1:46                               ` David Arnold
  2022-06-06  0:32                               ` Theodore Ts'o
  1 sibling, 0 replies; 57+ messages in thread
From: David Arnold @ 2022-06-04  1:46 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

To bring the topic back to some relevance to SIMH: 

Does it _matter_ that we’ve ended up with a handful of Linux variants (RH, Ubuntu, etc, plus Android) and BSD derivatives (macOS, iOS, etc) dominating the Unix world?

If xBSD has some great idea, it’ll get wedged into Linux (one can argue about the elegance of course) and the Apple *OS as soon as it proves beneficial to enough users.  If one out-performs the other, you can bet someone will track it down and fix it. 

Even Windows is adopting Unix/Linux concepts now.

If the kernel.org tree is both the source of many distro variants and the sink for many successful ideas, I can only hope OpenSIMH has similar success. 

Vive la différence!



d

> On 4 Jun 2022, at 11:05, Larry McVoy <lm@mcvoy.com> wrote:
> 
> On Fri, Jun 03, 2022 at 06:10:46PM -0600, Warner Losh wrote:
>>> On Fri, Jun 3, 2022, 5:48 PM Larry McVoy <lm@mcvoy.com> wrote:
>>> 
>>> On Fri, Jun 03, 2022 at 04:52:52PM -0600, Warner Losh wrote:
>>>>> The problem is there was {386,Net,Free,Open,DragonFly}BSD where there
>>>>> should have just been "BSD".  One, not a bunch.
>>>>> 
>>>> 
>>>> Except from 1993-1996 there were only two of those BSDs. NetBSD and
>>> FreeBSD
>>>> forked in 1993 due to the inability of the patchkit to adequately cover
>>> the
>>>> problems
>>>> in 386BSD governance.
>>> 
>>> Um, so there were 3: 386, Net and Free.  That's already 2 too many.
>> 
>> No. 386BSD died before then.
> 
> Says you.  I was running it in at least 1995.
> 
>>> Sure, there are forks, but there is one tree that matters, and that is
>>> Linus' tree.  You can't say that about BSD and that is the problem in
>>> it's entirety.  If I want to change BSD, which one?
>>> 
>> 
>> By your standards, only FreeBSD matters... so that's easy.. but you already
>> said Redhat is all that matters... and that kernel differs somewhat from
>> Linus'. Ditto if you are dealing with Android... it's not just one Linux
>> and never has been.
> 
> 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.
> 
> Like I said, I built and supported a very complex application on all the
> Linux platforms, all architectures, also supported on *BSD, HP-UX, AIX,
> IRIX, SunOS, Solaris, Ultrix, etc, windows{xp,2000,2008,etc}, MacOS.
> The problems I had between the various BSDs were orders of magnitude
> bigger than the problems I had between the various Linux distros we
> supported.
> 
> I will admit that we cloned NetBSD's stdio library because we needed
> to make changes to it (we stacked CRC, XOR, gzip, lz4, etc on it). 
> So we side stepped any stdio issues but for the rest we just made it
> work.  
> 
> So my actual data trumps your opinion on this one.  The BSD splintered 
> enough that they might as well have been IRIX and HP-UX, they weren't
> as crazy as AIX, I think AIX wins crazy, but they were dramatically
> more different, in subtle and annoying ways, than any Linux distro was.
> 
> My whole point is that if BSD had a focus, either a dictator or a 
> steering committee that people like me would have followed, it would
> have won.  It lost.  It sucks that it did, I'm a BSD guy in my core,
> but BSD lost.  And it lost because of a failure in leadership.
> 
> You and the other BSD people don't like that message but it is what it
> is.  BSD lost because Linux had better leadership.


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

* [TUHS] Re: [simh] Announcing the Open SIMH project
  2022-06-03 21:06         ` [TUHS] " Adam Thornton
@ 2022-06-04  9:09           ` Ralph Corderoy
  0 siblings, 0 replies; 57+ messages in thread
From: Ralph Corderoy @ 2022-06-04  9:09 UTC (permalink / raw)
  To: tuhs

Hi,

Adam Thornton wrote:
> While we're at it, can we make "make test" a separate target

If so, calling it ‘check’ avoids the right-of-passage head-scratcher
of ‘make test’ doing nothing because one just dumped some temporary
data in ./test.  :-)

-- 
Cheers, Ralph.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-04  1:05                             ` Larry McVoy
  2022-06-04  1:46                               ` David Arnold
@ 2022-06-06  0:32                               ` Theodore Ts'o
  2022-06-06  0:47                                 ` George Michaelson
                                                   ` (3 more replies)
  1 sibling, 4 replies; 57+ messages in thread
From: Theodore Ts'o @ 2022-06-06  0:32 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

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".

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.

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


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.

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.

						- Ted

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-06  0:32                               ` Theodore Ts'o
@ 2022-06-06  0:47                                 ` George Michaelson
  2022-06-06  1:17                                   ` Larry McVoy
  2022-06-06  1:02                                 ` Warner Losh
                                                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 57+ messages in thread
From: George Michaelson @ 2022-06-06  0:47 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: The Eunuchs Hysterical Society

AT&T wanted to monetise all work across the window. Personally, like a
lot of other ex BSD admin in a uni people I had strong opinion, and I
disliked the experience of SysV which was a mixture of unfamiliarity,
and bullshit process overlay.

I think when you put "but only for money" combined with "this is not
how I think" combined with "sorry, your bug is not going to be
important to us" combined with "thats not how AT&T thinks" it was
profoundly de-motivating for people to cohere around.

It is entirely tenable that at the time, a SysV kernel was "best of
breed" but also, in the period. all the exciting work on the network
stack was happening in Van Jacobsen's group, in BSD kernels.

It was only later when he moved to Google, the pace of work in kernel
network stack moved to Linux. Since then, BBR has been a low adoption
path, painful in the extreme, driven by Netflix engineers in BSD. We
now have 4 or 5 competing models to TCP flow management, and they
don't play nice, so its not only kernel fragmentation, its
kernel-featureset-richness fragmentation: inside a kernel, you have
too many tunables to think about.

Same with ZFS. Amazing system. At one point, the meme "it needs >4GB
memory" escaped & people said "you can't run this on a rpi" which is
factually incorrect, as much as "needs > 4GB" is also incorrect: it
works BETTER with a huge arc, and de-dupe burns memory, but if you
don't run de-dupe, you can run ZFS fine on smaller memory model
machines. But the number of tunables... Oh  my gosh.

Kernels might be good: they're also horrendously complex now.

-G

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-06  0:32                               ` Theodore Ts'o
  2022-06-06  0:47                                 ` George Michaelson
@ 2022-06-06  1:02                                 ` Warner Losh
  2022-06-06  1:09                                 ` Dan Cross
  2022-06-06  1:15                                 ` Larry McVoy
  3 siblings, 0 replies; 57+ messages in thread
From: Warner Losh @ 2022-06-06  1:02 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: The Eunuchs Hysterical Society

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

On Sun, Jun 5, 2022 at 6:32 PM Theodore Ts'o <tytso@mit.edu> 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

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-06  0:32                               ` Theodore Ts'o
  2022-06-06  0:47                                 ` George Michaelson
  2022-06-06  1:02                                 ` Warner Losh
@ 2022-06-06  1:09                                 ` Dan Cross
  2022-06-06  1:15                                 ` Larry McVoy
  3 siblings, 0 replies; 57+ messages in thread
From: Dan Cross @ 2022-06-06  1:09 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: The Eunuchs Hysterical Society

On Sun, Jun 5, 2022 at 8:35 PM Theodore Ts'o <tytso@mit.edu> wrote:
> [snip]
> 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.

Isn't that just an accident of history, though? The GNU stuff was
far enough along when Linux got going that he could crib most of
it by default to build a "complete" working system; he was just
providing the kernel, whereas Unix traditionally had been distributed
as a complete system, so the BSDs just kind of followed that model.

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

Sounds very familiar. I'll wager that just about any large organization
with a heavy investment in Linux has a similar problem on their hands.
I've _heard_ that Meta is different, but have no first-hand knowledge.

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

Was CSRG doing research, or producing a production system? It sure
seems like they were trying to thread a needle there that put them into
a weird position.

But more generally, it feels like this doesn't take into account the context
of the times.  $n$ manufacturers back in the minicomputer days were
used to writing their own OS for each new machine; sure they adapted
Unix, but the idea that they'd treat it differently from that standpoint
feels like something that didn't really occur to anyone until the late 80s.
By then, the stage was set for the arrival of something like Linux.

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

This I can totally buy, but my perception (as very much an outsider) was
that people ran --- and continue to run --- Linux because, simply, they
want to run Linux. They choose Not to run a BSD or illumos or whatever
else because they want to run Linux instead.

There was a time in the early 90s when FreeBSD was objectively better
in almost all metrics than Linux, including faster networking.  But people
still wanted to run Linux instead. Why? It just captured the zeitgeist better;
the barrier to entry was lower, you didn't have to put up with the "old school
Unix" mentality of many of the players (my term for what you have referred
to as, "the Gods of BSD" and some of the big egos of the USENIX crowd),
and people got religious about the license.

Many of the explanations we throw around here are interesting, but too
often feel like justifications after the fact. So much of it was simply
preference.

        - Dan C.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-06  0:32                               ` Theodore Ts'o
                                                   ` (2 preceding siblings ...)
  2022-06-06  1:09                                 ` Dan Cross
@ 2022-06-06  1:15                                 ` Larry McVoy
  2022-06-06  1:40                                   ` Dan Cross
  3 siblings, 1 reply; 57+ messages in thread
From: Larry McVoy @ 2022-06-06  1:15 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: The Eunuchs Hysterical Society

On Sun, Jun 05, 2022 at 08:32:47PM -0400, Theodore Ts'o wrote:
> 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....

I think I know but my opinion is very Sun centric.  Sun was the innovator
of the the time.  NFS, RPC, VM system that replaced the buffer cache so
everything was just pages, read/write/map, all the same pages.  Sun had
critical mass in talent and they innovated.  Everyone else followed
Sun (and hated them for it).

AT&T, other than the original group that did Unix, didn't innovate much
in the Unix domain.  SysV was sort of meh compared to SunOS.  When Unix
was sort of a skunk works, tons of good stuff happened.  When corporate
took it over, it became less interesting.  There was some good stuff, I
liked the document work bench stuff, I liked learn(1), it wasn't all bad.
But it wasn't even close to the same pace of innovation that Sun had,
I'm super grateful to have been at Sun while that was happening, that's
a once in a lifetime experience.

AT&T did fund Plan 9, if I remember history correctly, so that was 
a step back towards the original Unix innovation team.  I really wanted
plan 9 to take over but AT&T kept it away from open source too long and
Linux was too entrenched.  Classic Betamax vs VHS, the less good answer
won.  Sigh.

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

I think "it just works" is key.  Linux was really competing with Windows
and Linus knew that.  He could have cared less about *BSD, they just
weren't on his radar screen.  But Windows was.  Very early versions
of RedHat were good enough on the install that you could just tab your
way through it.  I remember being impressed because I was installing a
machine that didn't have a mouse (yet) and I just tabbed my way through
it and it was fine.

Today's FreeBSD install process is like a trip back to 1980.  It is
not pleasant.  The Linux install process 15 years ago was a better
experience than Windows install process (if you've done the windows
install then get some ethernet dongle that windows recognizes so you can
connect to the internet, then do the driver search and install, install,
install all the drivers - contrast that with Linux where it just has 99%
of the drivers in the kernel).

"It just works" for the win.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-06  0:47                                 ` George Michaelson
@ 2022-06-06  1:17                                   ` Larry McVoy
  0 siblings, 0 replies; 57+ messages in thread
From: Larry McVoy @ 2022-06-06  1:17 UTC (permalink / raw)
  To: George Michaelson; +Cc: The Eunuchs Hysterical Society

On Mon, Jun 06, 2022 at 10:47:31AM +1000, George Michaelson wrote:
> Kernels might be good: they're also horrendously complex now.

Amen to that.  I started on uniprocessor kernels that disabled interrupts,
very simple model.  Then SMP but coarse grained locks, still pretty simple.
Then out of order hit and while I get it, it is fine, it still kind of
exploded my mind and I moved to user space, source management stuff.

I have a vague idea what is in a modern Linux kernel and I want nothing 
to do with it, I'm not good enough.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-06  1:15                                 ` Larry McVoy
@ 2022-06-06  1:40                                   ` Dan Cross
  2022-06-06  2:36                                     ` Larry McVoy
                                                       ` (2 more replies)
  0 siblings, 3 replies; 57+ messages in thread
From: Dan Cross @ 2022-06-06  1:40 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

On Sun, Jun 5, 2022 at 9:15 PM Larry McVoy <lm@mcvoy.com> wrote:
> Today's FreeBSD install process is like a trip back to 1980.  It is
> not pleasant.  The Linux install process 15 years ago was a better
> experience than Windows install process (if you've done the windows
> install then get some ethernet dongle that windows recognizes so you can
> connect to the internet, then do the driver search and install, install,
> install all the drivers - contrast that with Linux where it just has 99%
> of the drivers in the kernel).

But every distribution has its own installer, and they vary wildly.

At the start of the pandemic, we realized really quickly that our older
kid needed a dedicated computer for her use, so I put Mint on an Intel
NUC and gave it to her. It was a delightful experience; very simple,
graphical installer, all of that. It does everything she needs for school
and goofing around stuff. It's great.

The other day, I needed a Linux machine for work. I grabbed another
NUC and put Arch on it. A vastly different experience: much more akin
to installing 7th Edition than Windows or macOS. Oh! And I missed a
step, so I had to pull some shenanigans to fix that.

I'd put the FreeBSD install process somewhere between the two.
Sure, it's textual, but it's pretty straightforward. OpenBSD is probably
a tad closer to the Arch-like experience -- it's not as colorful -- but it's
not too hard[*]. So the experience varies across BSDs, but not that
much, while it's vastly different across Linux distributions.

The ABI compatibility thing breaks down, too. A colleague was trying
to get the host-side of a Salae logic analyzer working on Arch, and it
doesn't. They more or less require Ubuntu 18.something, and that's
not what he runs. As far as most end-users are concerned, your
distribution of choice is "Linux", and distributions vary in all kinds of
ways.

        - Dan C.

I ran into some weird behavior in their bootstrap, though; I traced this
to something slow in the BIOS, did a fix locally, sent a bug report along
with a patch, and got told, "go use UEFI." Meh. Ok.... So I went back
and used UEFI, and the same thing was slow (unsurprising as almost
certainly the BIOS and UEFI flows share common code), wrote back,
and got silence. I pinged again the other week and still haven't heard
anything. Very discouraging. I suspect it's that kind of thing that turns
people off of at least some of the BSDs.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-06  1:40                                   ` Dan Cross
@ 2022-06-06  2:36                                     ` Larry McVoy
  2022-06-06 12:43                                       ` Dan Cross
  2022-06-06 14:53                                     ` Henry Bent
  2022-06-07 14:30                                     ` Theodore Ts'o
  2 siblings, 1 reply; 57+ messages in thread
From: Larry McVoy @ 2022-06-06  2:36 UTC (permalink / raw)
  To: Dan Cross; +Cc: The Eunuchs Hysterical Society

On Sun, Jun 05, 2022 at 09:40:44PM -0400, Dan Cross wrote:
> On Sun, Jun 5, 2022 at 9:15 PM Larry McVoy <lm@mcvoy.com> wrote:
> > Today's FreeBSD install process is like a trip back to 1980.  It is
> > not pleasant.  The Linux install process 15 years ago was a better
> > experience than Windows install process (if you've done the windows
> > install then get some ethernet dongle that windows recognizes so you can
> > connect to the internet, then do the driver search and install, install,
> > install all the drivers - contrast that with Linux where it just has 99%
> > of the drivers in the kernel).
> 
> But every distribution has its own installer, and they vary wildly.

Indeed they do.  I'd put RedHat as the best of the best, but truth be
told, Debian is not bad, it's more basic but it works.

I disagree about the BSDs being similar to Linux, go partition a
disk with FreeBSD and then compare that to Linux.  It's night and day.
The Linux stuff works and is obvious, the FreeBSD stuff only makes sense
if you have been using that forever, it's awful if you are a newbie.
And I say that as a guy who went through Sun's stuff, it was similar to
FreeBSD but a bit better.

Linux really did just make stuff work.  Is it elegant like v7 was, absolutely
not.  Does it handle a ton of stuff that nobody could imagine in the v7 days?
Absolutely yes.  Is it more complex than it should be?  I dunno, it is more
complex than I like but I'm an old graybeard.  I really wanted coarse graine
locking with what Clem and crew did with the cluster approach.  The vproc 
stuff.  I loved that and I think that is the knee of the curve, scale up
a bit on SMP but then cluster to scale up more.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-06  2:36                                     ` Larry McVoy
@ 2022-06-06 12:43                                       ` Dan Cross
  2022-06-06 13:41                                         ` Larry McVoy
  0 siblings, 1 reply; 57+ messages in thread
From: Dan Cross @ 2022-06-06 12:43 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

On Sun, Jun 5, 2022 at 10:36 PM Larry McVoy <lm@mcvoy.com> wrote:
> On Sun, Jun 05, 2022 at 09:40:44PM -0400, Dan Cross wrote:
> > [snip]
> > But every distribution has its own installer, and they vary wildly.
>
> Indeed they do.  I'd put RedHat as the best of the best, but truth be
> told, Debian is not bad, it's more basic but it works.

I don't think I've installed RedHat in years, honestly. I believe
you that it's a smooth process.

> I disagree about the BSDs being similar to Linux, go partition a
> disk with FreeBSD and then compare that to Linux.  It's night and day.
> The Linux stuff works and is obvious, the FreeBSD stuff only makes sense
> if you have been using that forever, it's awful if you are a newbie.

But define "Linux" here. Do you mean RedHat, specifically? Because
with Arch, you've got to manually run `fdisk` or `gdisk` or whatever, and
add partitions in that tool, set their type manually, etc, then manually
create the filesystems, install the boot loader and configure it. The steps
aren't necessarily hard, but it is tedious. The FreeBSD installer, on the
other hand, does pretty much all of that for you. My point is that YMMV
widely between Linux distributions, which vary between extremes of,
"manually partition the disk" and "this graphical wizard does all the nasty
stuff for you" and FreeBSD is somewhere between those two.

> And I say that as a guy who went through Sun's stuff, it was similar to
> FreeBSD but a bit better.
>
> Linux really did just make stuff work.

Huh. I remember before GPT you had to manually create MBR partitions
and, if you wanted more than 3 or 4 (or whatever the number was...) you
had to go and explicity create an extended partition and then subdivide
that. With FreeBSD, you just created one MBR partition and then the
installer let you create filesystems within that using their pseudo-graphical
installer (pseudo- in the sense that it was all text-based, but at least it
was menu driven if that was your bag). I found whatever Linux distribution
I was installing at the time a lot more complex than FreeBSD, but I get
that individuals differ here.

Then again, I care a _lot_ less about carefully dividing my disk up into
different filesystems these days. Back in the day, especially on multiuser
machines, you had to either due to limitations in the filesystem code
(2GB FFS partitions!) or to keep random users from filling up / or /usr.
Most of the need for that kind of subdivision has gone away.

> Is it elegant like v7 was, absolutely
> not.  Does it handle a ton of stuff that nobody could imagine in the v7 days?

Oh, absolutely!

> Absolutely yes.  Is it more complex than it should be?  I dunno, it is more
> complex than I like but I'm an old graybeard.  I really wanted coarse graine
> locking with what Clem and crew did with the cluster approach.  The vproc
> stuff.  I loved that and I think that is the knee of the curve, scale up
> a bit on SMP but then cluster to scale up more.

The world that might have been.

I was thinking more about the ABI compatibility stuff that Ted had mentioned,
and the more I think about it, the less I think that the kernel ABI is all that
relevant. Yes, it's nice that you can take a binary compiled on one distribution
of Linux and drop it onto another distribution and it will
theoretically run because
the system call numbers will mostly line up and the convention for trapping into
the kernel is basically stable, but that's only part of the equation,
and for any
non-trivial binaries, you've also got to make sure that a whole slew of shared
libraries are installed and the correct version (hence why my colleague can't
use the Salae controller software on his Arch machine). To compensate, we've
built up a huge amount of complexity around containers and flatpaks and all of
that stuff, which sometimes doesn't work; not to mention moving across ISAs.
A stable kernel ABI may be necessary, but it's definitely not sufficient.

        - Dan C.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-06 12:43                                       ` Dan Cross
@ 2022-06-06 13:41                                         ` Larry McVoy
  2022-06-06 14:27                                           ` Blake McBride
  0 siblings, 1 reply; 57+ messages in thread
From: Larry McVoy @ 2022-06-06 13:41 UTC (permalink / raw)
  To: Dan Cross; +Cc: The Eunuchs Hysterical Society

On Mon, Jun 06, 2022 at 08:43:01AM -0400, Dan Cross wrote:
> On Sun, Jun 5, 2022 at 10:36 PM Larry McVoy <lm@mcvoy.com> wrote:
> > I disagree about the BSDs being similar to Linux, go partition a
> > disk with FreeBSD and then compare that to Linux.  It's night and day.
> > The Linux stuff works and is obvious, the FreeBSD stuff only makes sense
> > if you have been using that forever, it's awful if you are a newbie.
> 
> But define "Linux" here. Do you mean RedHat, specifically? Because
> with Arch, you've got to manually run `fdisk` or `gdisk` or whatever, and
> add partitions in that tool, set their type manually, etc, then manually
> create the filesystems, install the boot loader and configure it. The steps
> aren't necessarily hard, but it is tedious. The FreeBSD installer, on the
> other hand, does pretty much all of that for you. My point is that YMMV
> widely between Linux distributions, which vary between extremes of,
> "manually partition the disk" and "this graphical wizard does all the nasty
> stuff for you" and FreeBSD is somewhere between those two.

RedHat, Ubuntu, any of the major distributions.  Heck, Knoppix is fine.
Arch is an outlier, it's not trying to be easy to install for boomers.

> > Linux really did just make stuff work.
> 
> Huh. I remember before GPT you had to manually create MBR partitions
> and, if you wanted more than 3 or 4 (or whatever the number was...) you
> had to go and explicity create an extended partition and then subdivide
> that. With FreeBSD, you just created one MBR partition and then the
> installer let you create filesystems within that using their pseudo-graphical
> installer (pseudo- in the sense that it was all text-based, but at least it
> was menu driven if that was your bag). I found whatever Linux distribution
> I was installing at the time a lot more complex than FreeBSD, but I get
> that individuals differ here.

All of the major Linux distros have made this point and click painless
(and see my other post, they all work just fine without a mouse in a
point and click world).  FreeBSD hasn't updated their install process
in decades.  It is literally stepping back to the 4BSD era.  Painless,
it ain't.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-06 13:41                                         ` Larry McVoy
@ 2022-06-06 14:27                                           ` Blake McBride
  2022-06-06 14:33                                             ` Steve Nickolas
  0 siblings, 1 reply; 57+ messages in thread
From: Blake McBride @ 2022-06-06 14:27 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

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

On Mon, Jun 6, 2022 at 8:41 AM Larry McVoy <lm@mcvoy.com> wrote:

> [...]
>
> All of the major Linux distros have made this point and click painless
> (and see my other post, they all work just fine without a mouse in a
> point and click world).  FreeBSD hasn't updated their install process
> in decades.  It is literally stepping back to the 4BSD era.  Painless,
> it ain't.
>

I installed BSD and Linux many times.  As you state, the BSD installs are
incredibly poor.  It is amazing to me.  I believe that it would be simple
to fix if one person who cared and had some common sense fixed it.  It's
all pretty basic.  The first thing someone sees when they try BSD is their
incredibly poor installer.  That sets the stage for the Linux preference.

I know.  I know.  The answer is "why don't you fix it and submit a patch".
Answer is - I already work nearly 12/7 on other responsibilities (some of
which are open-source projects that benefit the public).

Blake McBride

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-06 14:27                                           ` Blake McBride
@ 2022-06-06 14:33                                             ` Steve Nickolas
  0 siblings, 0 replies; 57+ messages in thread
From: Steve Nickolas @ 2022-06-06 14:33 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Mon, 6 Jun 2022, Blake McBride wrote:

> I installed BSD and Linux many times.  As you state, the BSD installs are
> incredibly poor.  It is amazing to me.  I believe that it would be simple
> to fix if one person who cared and had some common sense fixed it.  It's
> all pretty basic.  The first thing someone sees when they try BSD is their
> incredibly poor installer.  That sets the stage for the Linux preference.

IMO, NetBSD seems easier than that...though not so much as Debian.

-uso.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-06  1:40                                   ` Dan Cross
  2022-06-06  2:36                                     ` Larry McVoy
@ 2022-06-06 14:53                                     ` Henry Bent
  2022-06-06 23:28                                       ` David Arnold
  2022-06-07 14:30                                     ` Theodore Ts'o
  2 siblings, 1 reply; 57+ messages in thread
From: Henry Bent @ 2022-06-06 14:53 UTC (permalink / raw)
  To: Dan Cross; +Cc: The Eunuchs Hysterical Society

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

On Sun, 5 Jun 2022 at 21:41, Dan Cross <crossd@gmail.com> wrote:

>
> The other day, I needed a Linux machine for work. I grabbed another
> NUC and put Arch on it. A vastly different experience: much more akin
> to installing 7th Edition than Windows or macOS. Oh! And I missed a
> step, so I had to pull some shenanigans to fix that.
>

Gentoo is even more arcane, but that's essentially an "I want to do
everything myself" distribution.  I suppose my point is that there exist a
full range of distributions, from the truly masochistic Linux From Scratch
to the most hands-off/static ChromeOS Flex.  I don't believe that any other
"OS" has such a wide range of offerings.  This is obviously both a
wonderful feature and a confusing nightmare, depending on your audience.


> I'd put the FreeBSD install process somewhere between the two.
> Sure, it's textual, but it's pretty straightforward. OpenBSD is probably
> a tad closer to the Arch-like experience -- it's not as colorful -- but
> it's
> not too hard[*]. So the experience varies across BSDs, but not that
> much, while it's vastly different across Linux distributions.
>

I haven't installed FreeBSD or OpenBSD in many years, but I am familiar
with NetBSD's text-based installer.  It almost reminds me of how Solaris
from the console was - if you want to you can manually set partition sizes
and choose which portions of the OS you want to install, but if you just
choose all of the defaults you'll almost certainly have a reasonable
system.  That being said, it does assume some preexisting level of Unix
knowledge if you want to actually understand what is happening, or
understand how/why you would want to change the defaults.


> The ABI compatibility thing breaks down, too. A colleague was trying
> to get the host-side of a Salae logic analyzer working on Arch, and it
> doesn't. They more or less require Ubuntu 18.something, and that's
> not what he runs. As far as most end-users are concerned, your
> distribution of choice is "Linux", and distributions vary in all kinds of
> ways.
>

What I think might be most confusing to the average user is that there is
not really a "Linux 2" or "Linux 4" or what have you with which to
advertise compatibility.  Specific kernel versions are virtually
meaningless to precompiled or closed-source binaries, it's all about the
libraries.  So you run into the situation of "we tested it on Ubuntu 18 and
that works so that's what we're supporting" because it's probably not worth
the time for a smaller company to validate their software against the
plethora of available versions of available distributions, even if the
solution might be as simple as "add this one package and it will work."

Tangentially, this reminds me of the situation with Solaris and software
compatibility.  For example, the Sun Workshop Compiler 6 was advertised as
only being for Solaris 2.6 and up.  Upon close inspection it turned out
that the only reason for this was that it wanted access to snprintf() and
vsnprintf(), which weren't in the 2.5.1 kernel.  But it turned out that
__snprintf() and __vsnprintf() were, so if you created a very simple shared
library and forced it in the environment with LD_PRELOAD, everything worked
just fine.  Sun later appeared to wise up to this with the introduction of
dependencies on internal shared library versioning.


> I ran into some weird behavior in their bootstrap, though; I traced this
> to something slow in the BIOS, did a fix locally, sent a bug report along
> with a patch, and got told, "go use UEFI." Meh. Ok.... So I went back
> and used UEFI, and the same thing was slow (unsurprising as almost
> certainly the BIOS and UEFI flows share common code), wrote back,
> and got silence. I pinged again the other week and still haven't heard
> anything. Very discouraging. I suspect it's that kind of thing that turns
> people off of at least some of the BSDs.
>

I've submitted patches to NetBSD and this was definitely not my
experience.  It's disappointing to see OpenBSD's "user hostile" stereotype
borne out in reality.

-Henry

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-06 14:53                                     ` Henry Bent
@ 2022-06-06 23:28                                       ` David Arnold
  0 siblings, 0 replies; 57+ messages in thread
From: David Arnold @ 2022-06-06 23:28 UTC (permalink / raw)
  To: Henry Bent; +Cc: The Eunuchs Hysterical Society

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

> On 7 Jun 2022, at 00:53, Henry Bent <henry.r.bent@gmail.com> wrote:
> 
> On Sun, 5 Jun 2022 at 21:41, Dan Cross <crossd@gmail.com <mailto:crossd@gmail.com>> wrote:
> 
> The other day, I needed a Linux machine for work. I grabbed another
> NUC and put Arch on it. A vastly different experience: much more akin
> to installing 7th Edition than Windows or macOS. Oh! And I missed a
> step, so I had to pull some shenanigans to fix that.
> 
> Gentoo is even more arcane, but that's essentially an "I want to do everything myself" distribution.  I suppose my point is that there exist a full range of distributions, from the truly masochistic Linux From Scratch to the most hands-off/static ChromeOS Flex.  I don't believe that any other "OS" has such a wide range of offerings.  This is obviously both a wonderful feature and a confusing nightmare, depending on your audience.

Lest it be thought that all is sweetness and light in Linux-land, there were years of fairly intense competition involved in getting installers to the point that you can start with a downloaded image, burn it to a USB, boot it, run it, and (optionally) make it persist over a reboot, all with very minimal need to understand or care about the many, many things going on under the hood.

More recently, installation has become more-or-less settled technology (and so things like Arch have arisen that specialise away from that experience), and there’s increasing competition around the end-user experience.  Distributions like ChromeOS or https://elementary.io/ or (from the BSD world!) https://hellosystem.github.io/, are attempting to provide a more seamless user experience than the standard GNOME-or-KDE duopoly that has until recently focused on being competitive with decades old Windows/macOS.

Perhaps that’s something OpenSIMH could take from this history: a focus on painless installation and a decent UI!




d




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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-06  1:40                                   ` Dan Cross
  2022-06-06  2:36                                     ` Larry McVoy
  2022-06-06 14:53                                     ` Henry Bent
@ 2022-06-07 14:30                                     ` Theodore Ts'o
  2022-06-07 15:08                                       ` Dan Cross
  2 siblings, 1 reply; 57+ messages in thread
From: Theodore Ts'o @ 2022-06-07 14:30 UTC (permalink / raw)
  To: Dan Cross, David Arnold; +Cc: The Eunuchs Hysterical Society

On Tue, Jun 07, 2022 at 09:28:14AM +1000, David Arnold wrote:
> Lest it be thought that all is sweetness and light in Linux-land,
> there were years of fairly intense competition involved in getting
> installers to the point that you can start with a downloaded image,
> burn it to a USB, boot it, run it, and (optionally) make it persist
> over a reboot, all with very minimal need to understand or care
> about the many, many things going on under the hood.

On Sun, Jun 05, 2022 at 09:40:44PM -0400, Dan Cross wrote:
> 
> But every distribution has its own installer, and they vary wildly.

The key is I think *competition*.  Distributions were competing to
attract a user base, and one of the ways they could do that was by
improving the install experience.  There were people who reviewed
distributions based on which one had the better installer, and that
helped users who were Windows refugees choose the ones that had the
better installer.

The other advantages of having a many distributions is that gave more
people to opportunity to exercise leadership --- you can "drive the
big red firetruck" by founding a distro like Debian or Slackware, and
the people who are interested in improving a distribution can be
different from those who drive kernel development.  This is one of the
things that I've learned from my rector at my church, who had a
background in community organizing.  One of the big differences
between community organizing compared to the corporate world is that
it's more important to give more people --- volunteers ---
opportunities to contribute, and very often this is far more important
than efficiently organizing a corporate-style team to get some job
done.  Was it inefficient to have multiple teams competing on
installer development, and release engineering?  Sure, but it also
drew more people into the Linux ecosystem.

> The ABI compatibility thing breaks down, too. A colleague was trying
> to get the host-side of a Salae logic analyzer working on Arch, and it
> doesn't. They more or less require Ubuntu 18.something, and that's
> not what he runs. As far as most end-users are concerned, your
> distribution of choice is "Linux", and distributions vary in all kinds of
> ways.

There are three different things that's worth separating.  One is a
consistent kernel<->user space interface, this is what Linus Torvalds
considers high priority when he says, "Thou shalt not break
userspace".  This is what allows pretty much all distributions to
replace the kernel that was shipped with the distribution with the
latest upstream kernel.  And this is something that in general doesn't
work with *BSD systems.

The second is application source-level compatibility, and this is what
allows you to download some open source application, and recompile it
on different Linux distributions, and it should Just Work.  In
practice this works for most Linux and *BSD users.

And the third is application *binary* level compatibility.  And this
is what is important if you have some binary that you've downloaded,
or some commerical application which you've purchased, and you want to
run it on Linux distribution different from the one which is
originally designed.  Static linking solves most of the problems, but
if the user needs to use proprietary/commercial binaries, if they
stick to RHEL, Fedora, Ubuntu/Debian, they will generally not have
issues.

						 - Ted

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-07 14:30                                     ` Theodore Ts'o
@ 2022-06-07 15:08                                       ` Dan Cross
  2022-06-07 15:25                                         ` Larry McVoy
  2022-06-07 15:55                                         ` [TUHS] Re: Fwd: " Richard Salz
  0 siblings, 2 replies; 57+ messages in thread
From: Dan Cross @ 2022-06-07 15:08 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: The Eunuchs Hysterical Society

On Tue, Jun 7, 2022 at 10:30 AM Theodore Ts'o <tytso@mit.edu> wrote:
> On Tue, Jun 07, 2022 at 09:28:14AM +1000, David Arnold wrote:
> > Lest it be thought that all is sweetness and light in Linux-land,
> > there were years of fairly intense competition involved in getting
> > installers to the point that you can start with a downloaded image,
> > burn it to a USB, boot it, run it, and (optionally) make it persist
> > over a reboot, all with very minimal need to understand or care
> > about the many, many things going on under the hood.
>
> On Sun, Jun 05, 2022 at 09:40:44PM -0400, Dan Cross wrote:
> >
> > But every distribution has its own installer, and they vary wildly.
>
> The key is I think *competition*.  Distributions were competing to
> attract a user base, and one of the ways they could do that was by
> improving the install experience.  There were people who reviewed
> distributions based on which one had the better installer, and that
> helped users who were Windows refugees choose the ones that had the
> better installer.

My point is that this is something that varies from distro to distro;
it is therefore inaccurate to claim that "Linux solved it" since many
different distros that have widely varying installation processes
fall under the very large "Linux" umbrella.

> The other advantages of having a many distributions is that gave more
> people to opportunity to exercise leadership --- you can "drive the
> big red firetruck" by founding a distro like Debian or Slackware, and
> the people who are interested in improving a distribution can be
> different from those who drive kernel development.  This is one of the
> things that I've learned from my rector at my church, who had a
> background in community organizing.  One of the big differences
> between community organizing compared to the corporate world is that
> it's more important to give more people --- volunteers ---
> opportunities to contribute, and very often this is far more important
> than efficiently organizing a corporate-style team to get some job
> done.  Was it inefficient to have multiple teams competing on
> installer development, and release engineering?  Sure, but it also
> drew more people into the Linux ecosystem.

That's an interesting angle and one that I think bears more on the topic
at hand than many folks are willing to let on: the barrier to contribution is,
in a lot of important ways, lower in the Linux ecosystem than it is in the
BSD world. At least historically speaking, and perhaps still true. Anecdotally,
I was able to get a patch into the KVM unit tests (not precisely Linux but
related) in pretty short order recently while the OpenBSD people simply
ignored my problem report and patch. YMMV.

> > The ABI compatibility thing breaks down, too. A colleague was trying
> > to get the host-side of a Salae logic analyzer working on Arch, and it
> > doesn't. They more or less require Ubuntu 18.something, and that's
> > not what he runs. As far as most end-users are concerned, your
> > distribution of choice is "Linux", and distributions vary in all kinds of
> > ways.
>
> There are three different things that's worth separating.  One is a
> consistent kernel<->user space interface, this is what Linus Torvalds
> considers high priority when he says, "Thou shalt not break
> userspace".  This is what allows pretty much all distributions to
> replace the kernel that was shipped with the distribution with the
> latest upstream kernel.  And this is something that in general doesn't
> work with *BSD systems.

Eh? I feel like I can upgrade the kernel on the various BSDs
without binaries breaking pretty easily. Then again, there _have_
been times when there were flag days that required rebuilding
the world; but surely externalities are more common here (e.g.,
switching from one ISA to another).

> The second is application source-level compatibility, and this is what
> allows you to download some open source application, and recompile it
> on different Linux distributions, and it should Just Work.  In
> practice this works for most Linux and *BSD users.

This, I think, is where things break down. Simply put, the way
people build applications has changed, and "source-level"
compatibility means compatibility with a bunch of third-party
libraries; in many ways the kernel interfaces matter much, much
less (many of which are defined by externally imposed standards
anyway). If a distro ships a too-old or too-new version of the
dependency, then the open source thing will often not build, and
for most end users, this is a distinction without a difference.

> And the third is application *binary* level compatibility.  And this
> is what is important if you have some binary that you've downloaded,
> or some commerical application which you've purchased, and you want to
> run it on Linux distribution different from the one which is
> originally designed.  Static linking solves most of the problems, but
> if the user needs to use proprietary/commercial binaries, if they
> stick to RHEL, Fedora, Ubuntu/Debian, they will generally not have
> issues.

Yup. But then that you're running Linux is mostly immaterial; it could
be Windows and the same would be true.

        - Dan C.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-07 15:08                                       ` Dan Cross
@ 2022-06-07 15:25                                         ` Larry McVoy
  2022-06-07 16:03                                           ` Will Senn
  2022-06-07 15:55                                         ` [TUHS] Re: Fwd: " Richard Salz
  1 sibling, 1 reply; 57+ messages in thread
From: Larry McVoy @ 2022-06-07 15:25 UTC (permalink / raw)
  To: Dan Cross; +Cc: The Eunuchs Hysterical Society

On Tue, Jun 07, 2022 at 11:08:34AM -0400, Dan Cross wrote:
> On Tue, Jun 7, 2022 at 10:30 AM Theodore Ts'o <tytso@mit.edu> wrote:
> > The key is I think *competition*.  Distributions were competing to
> > attract a user base, and one of the ways they could do that was by
> > improving the install experience.  There were people who reviewed
> > distributions based on which one had the better installer, and that
> > helped users who were Windows refugees choose the ones that had the
> > better installer.
> 
> My point is that this is something that varies from distro to distro;
> it is therefore inaccurate to claim that "Linux solved it" since many
> different distros that have widely varying installation processes
> fall under the very large "Linux" umbrella.

Yeah, there are a large number of distros but I'm willing to bet that
Debian, RedHat and Ubuntu variants account for the vast majority of
installs.

> > There are three different things that's worth separating.  One is a
> > consistent kernel<->user space interface, this is what Linus Torvalds
> > considers high priority when he says, "Thou shalt not break
> > userspace".  This is what allows pretty much all distributions to
> > replace the kernel that was shipped with the distribution with the
> > latest upstream kernel.  And this is something that in general doesn't
> > work with *BSD systems.
> 
> Eh? I feel like I can upgrade the kernel on the various BSDs
> without binaries breaking pretty easily. Then again, there _have_
> been times when there were flag days that required rebuilding
> the world; but surely externalities are more common here (e.g.,
> switching from one ISA to another).

Try installing an OpenBSD kernel on FreeBSD, that's what we mean by
compat.  I'm more than willing to believe that you can pull head on
the FreeBSD source tree and build & install it on FreeBSD.  Much less
willing to believe that that works Open/Free or Net/Free.

With Linux, on pretty much any distro, you can pull Linus' tree and
build and install it without drama.  If you are running some ancient
release you might have to update your toolchain but that's about it.
Linus is super careful to not break the syscall table.  It's extend
only, which makes it a mess, but a binary compat mess.

> > The second is application source-level compatibility, and this is what
> > allows you to download some open source application, and recompile it
> > on different Linux distributions, and it should Just Work.  In
> > practice this works for most Linux and *BSD users.
> 
> This, I think, is where things break down. Simply put, the way
> people build applications has changed, and "source-level"
> compatibility means compatibility with a bunch of third-party
> libraries; in many ways the kernel interfaces matter much, much
> less (many of which are defined by externally imposed standards
> anyway). If a distro ships a too-old or too-new version of the
> dependency, then the open source thing will often not build, and
> for most end users, this is a distinction without a difference.

Yes, you are correct, I've experienced that as well with sort of
newer complex apps.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-07 15:08                                       ` Dan Cross
  2022-06-07 15:25                                         ` Larry McVoy
@ 2022-06-07 15:55                                         ` Richard Salz
  1 sibling, 0 replies; 57+ messages in thread
From: Richard Salz @ 2022-06-07 15:55 UTC (permalink / raw)
  To: Dan Cross; +Cc: The Eunuchs Hysterical Society

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

> > Lest it be thought that all is sweetness and light in Linux-land,

I don't think anyone has thought or said that about Linux ever.

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-07 15:25                                         ` Larry McVoy
@ 2022-06-07 16:03                                           ` Will Senn
  2022-06-07 16:38                                             ` Warner Losh
  0 siblings, 1 reply; 57+ messages in thread
From: Will Senn @ 2022-06-07 16:03 UTC (permalink / raw)
  To: Larry McVoy, Dan Cross; +Cc: The Eunuchs Hysterical Society

Interesting crossover from Linux to Linux Distros... Debian's my 
personal fave (in the form of Mint, MX, or even Ubuntu), mostly cuz apt 
seems to just work (for me, ymmv) and rpm sucks :). However, all of 
these run on the same kernel and generally provide the same userland 
(core-utils, etc). I constantly switch from Mac (Mojave) to FreeBSD to 
Linux (Mint, usually, but occassionally opensuse) and other than minor 
differences in switches, they are all reminiscent of v7, from a user 
perspective, outside of GUIs. Except for ZFS, which will keep FreeBSD in 
my environment until it's added to the Linux Kernel - is hell freezing 
over yet?

-w



On 6/7/22 10:25 AM, Larry McVoy wrote:
> On Tue, Jun 07, 2022 at 11:08:34AM -0400, Dan Cross wrote:
>> On Tue, Jun 7, 2022 at 10:30 AM Theodore Ts'o <tytso@mit.edu> wrote:
>>> The key is I think *competition*.  Distributions were competing to
>>> attract a user base, and one of the ways they could do that was by
>>> improving the install experience.  There were people who reviewed
>>> distributions based on which one had the better installer, and that
>>> helped users who were Windows refugees choose the ones that had the
>>> better installer.
>> My point is that this is something that varies from distro to distro;
>> it is therefore inaccurate to claim that "Linux solved it" since many
>> different distros that have widely varying installation processes
>> fall under the very large "Linux" umbrella.
> Yeah, there are a large number of distros but I'm willing to bet that
> Debian, RedHat and Ubuntu variants account for the vast majority of
> installs.
>
>>> There are three different things that's worth separating.  One is a
>>> consistent kernel<->user space interface, this is what Linus Torvalds
>>> considers high priority when he says, "Thou shalt not break
>>> userspace".  This is what allows pretty much all distributions to
>>> replace the kernel that was shipped with the distribution with the
>>> latest upstream kernel.  And this is something that in general doesn't
>>> work with *BSD systems.
>> Eh? I feel like I can upgrade the kernel on the various BSDs
>> without binaries breaking pretty easily. Then again, there _have_
>> been times when there were flag days that required rebuilding
>> the world; but surely externalities are more common here (e.g.,
>> switching from one ISA to another).
> Try installing an OpenBSD kernel on FreeBSD, that's what we mean by
> compat.  I'm more than willing to believe that you can pull head on
> the FreeBSD source tree and build & install it on FreeBSD.  Much less
> willing to believe that that works Open/Free or Net/Free.
>
> With Linux, on pretty much any distro, you can pull Linus' tree and
> build and install it without drama.  If you are running some ancient
> release you might have to update your toolchain but that's about it.
> Linus is super careful to not break the syscall table.  It's extend
> only, which makes it a mess, but a binary compat mess.
>
>>> The second is application source-level compatibility, and this is what
>>> allows you to download some open source application, and recompile it
>>> on different Linux distributions, and it should Just Work.  In
>>> practice this works for most Linux and *BSD users.
>> This, I think, is where things break down. Simply put, the way
>> people build applications has changed, and "source-level"
>> compatibility means compatibility with a bunch of third-party
>> libraries; in many ways the kernel interfaces matter much, much
>> less (many of which are defined by externally imposed standards
>> anyway). If a distro ships a too-old or too-new version of the
>> dependency, then the open source thing will often not build, and
>> for most end users, this is a distinction without a difference.
> Yes, you are correct, I've experienced that as well with sort of
> newer complex apps.


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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-07 16:03                                           ` Will Senn
@ 2022-06-07 16:38                                             ` Warner Losh
  2022-06-07 16:45                                               ` Larry McVoy
                                                                 ` (2 more replies)
  0 siblings, 3 replies; 57+ messages in thread
From: Warner Losh @ 2022-06-07 16:38 UTC (permalink / raw)
  To: Will Senn; +Cc: The Eunuchs Hysterical Society

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

On Tue, Jun 7, 2022, 9:03 AM Will Senn <will.senn@gmail.com> wrote:

> Interesting crossover from Linux to Linux Distros... Debian's my
> personal fave (in the form of Mint, MX, or even Ubuntu), mostly cuz apt
> seems to just work (for me, ymmv) and rpm sucks :). However, all of
> these run on the same kernel and generally provide the same userland
> (core-utils, etc).


But not the same binaries. I've run into a lot of issues trying to run a
binary for Debian on red hat or vice Vera due to shared libraries not being
completely compatible... kinda makes the whole system call argument moot
since there is always significant version skew...

Warner

I constantly switch from Mac (Mojave) to FreeBSD to
> Linux (Mint, usually, but occassionally opensuse) and other than minor
> differences in switches, they are all reminiscent of v7, from a user
> perspective, outside of GUIs. Except for ZFS, which will keep FreeBSD in
> my environment until it's added to the Linux Kernel - is hell freezing
> over yet?
>
> -w
>
>
>
> On 6/7/22 10:25 AM, Larry McVoy wrote:
> > On Tue, Jun 07, 2022 at 11:08:34AM -0400, Dan Cross wrote:
> >> On Tue, Jun 7, 2022 at 10:30 AM Theodore Ts'o <tytso@mit.edu> wrote:
> >>> The key is I think *competition*.  Distributions were competing to
> >>> attract a user base, and one of the ways they could do that was by
> >>> improving the install experience.  There were people who reviewed
> >>> distributions based on which one had the better installer, and that
> >>> helped users who were Windows refugees choose the ones that had the
> >>> better installer.
> >> My point is that this is something that varies from distro to distro;
> >> it is therefore inaccurate to claim that "Linux solved it" since many
> >> different distros that have widely varying installation processes
> >> fall under the very large "Linux" umbrella.
> > Yeah, there are a large number of distros but I'm willing to bet that
> > Debian, RedHat and Ubuntu variants account for the vast majority of
> > installs.
> >
> >>> There are three different things that's worth separating.  One is a
> >>> consistent kernel<->user space interface, this is what Linus Torvalds
> >>> considers high priority when he says, "Thou shalt not break
> >>> userspace".  This is what allows pretty much all distributions to
> >>> replace the kernel that was shipped with the distribution with the
> >>> latest upstream kernel.  And this is something that in general doesn't
> >>> work with *BSD systems.
> >> Eh? I feel like I can upgrade the kernel on the various BSDs
> >> without binaries breaking pretty easily. Then again, there _have_
> >> been times when there were flag days that required rebuilding
> >> the world; but surely externalities are more common here (e.g.,
> >> switching from one ISA to another).
> > Try installing an OpenBSD kernel on FreeBSD, that's what we mean by
> > compat.  I'm more than willing to believe that you can pull head on
> > the FreeBSD source tree and build & install it on FreeBSD.  Much less
> > willing to believe that that works Open/Free or Net/Free.
> >
> > With Linux, on pretty much any distro, you can pull Linus' tree and
> > build and install it without drama.  If you are running some ancient
> > release you might have to update your toolchain but that's about it.
> > Linus is super careful to not break the syscall table.  It's extend
> > only, which makes it a mess, but a binary compat mess.
> >
> >>> The second is application source-level compatibility, and this is what
> >>> allows you to download some open source application, and recompile it
> >>> on different Linux distributions, and it should Just Work.  In
> >>> practice this works for most Linux and *BSD users.
> >> This, I think, is where things break down. Simply put, the way
> >> people build applications has changed, and "source-level"
> >> compatibility means compatibility with a bunch of third-party
> >> libraries; in many ways the kernel interfaces matter much, much
> >> less (many of which are defined by externally imposed standards
> >> anyway). If a distro ships a too-old or too-new version of the
> >> dependency, then the open source thing will often not build, and
> >> for most end users, this is a distinction without a difference.
> > Yes, you are correct, I've experienced that as well with sort of
> > newer complex apps.
>
>

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-07 16:38                                             ` Warner Losh
@ 2022-06-07 16:45                                               ` Larry McVoy
  2022-06-07 16:57                                                 ` Warner Losh
  2022-06-07 16:46                                               ` Blake McBride
  2022-06-07 17:00                                               ` Paul Winalski
  2 siblings, 1 reply; 57+ messages in thread
From: Larry McVoy @ 2022-06-07 16:45 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

On Tue, Jun 07, 2022 at 10:38:57AM -0600, Warner Losh wrote:
> On Tue, Jun 7, 2022, 9:03 AM Will Senn <will.senn@gmail.com> wrote:
> 
> > Interesting crossover from Linux to Linux Distros... Debian's my
> > personal fave (in the form of Mint, MX, or even Ubuntu), mostly cuz apt
> > seems to just work (for me, ymmv) and rpm sucks :). However, all of
> > these run on the same kernel and generally provide the same userland
> > (core-utils, etc).
> 
> 
> But not the same binaries. I've run into a lot of issues trying to run a
> binary for Debian on red hat or vice Vera due to shared libraries not being
> completely compatible... kinda makes the whole system call argument moot
> since there is always significant version skew...

Yep, shared libraries can screw you but that's true anywhere.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-07 16:38                                             ` Warner Losh
  2022-06-07 16:45                                               ` Larry McVoy
@ 2022-06-07 16:46                                               ` Blake McBride
  2022-06-07 17:26                                                 ` Paul Winalski
  2022-06-07 17:00                                               ` Paul Winalski
  2 siblings, 1 reply; 57+ messages in thread
From: Blake McBride @ 2022-06-07 16:46 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

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

On Tue, Jun 7, 2022 at 11:39 AM Warner Losh <imp@bsdimp.com> wrote:

>
> But not the same binaries. I've run into a lot of issues trying to run a
> binary for Debian on red hat or vice Vera due to shared libraries not being
> completely compatible... kinda makes the whole system call argument moot
> since there is always significant version skew...
>

That's why God created static linking.

Blake

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-07 16:45                                               ` Larry McVoy
@ 2022-06-07 16:57                                                 ` Warner Losh
  2022-06-07 17:05                                                   ` Larry McVoy
  0 siblings, 1 reply; 57+ messages in thread
From: Warner Losh @ 2022-06-07 16:57 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

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

On Tue, Jun 7, 2022, 9:45 AM Larry McVoy <lm@mcvoy.com> wrote:

> On Tue, Jun 07, 2022 at 10:38:57AM -0600, Warner Losh wrote:
> > On Tue, Jun 7, 2022, 9:03 AM Will Senn <will.senn@gmail.com> wrote:
> >
> > > Interesting crossover from Linux to Linux Distros... Debian's my
> > > personal fave (in the form of Mint, MX, or even Ubuntu), mostly cuz apt
> > > seems to just work (for me, ymmv) and rpm sucks :). However, all of
> > > these run on the same kernel and generally provide the same userland
> > > (core-utils, etc).
> >
> >
> > But not the same binaries. I've run into a lot of issues trying to run a
> > binary for Debian on red hat or vice Vera due to shared libraries not
> being
> > completely compatible... kinda makes the whole system call argument moot
> > since there is always significant version skew...
>
> Yep, shared libraries can screw you but that's true anywhere.
>

Kinda my point: you brag of a misleading compatibility and then attack
others that decide to slice things up differently and don't have that,
these days useless, talking point.

Warner

-- 
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>

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

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-07 16:38                                             ` Warner Losh
  2022-06-07 16:45                                               ` Larry McVoy
  2022-06-07 16:46                                               ` Blake McBride
@ 2022-06-07 17:00                                               ` Paul Winalski
  2022-06-07 23:41                                                 ` [TUHS] " Chris Hanson
  2 siblings, 1 reply; 57+ messages in thread
From: Paul Winalski @ 2022-06-07 17:00 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On 6/7/22, Warner Losh <imp@bsdimp.com> wrote:
>
> But not the same binaries. I've run into a lot of issues trying to run a
> binary for Debian on red hat or vice Vera due to shared libraries not being
> completely compatible... kinda makes the whole system call argument moot
> since there is always significant version skew...

Part of my last job was to maintain a suite of software development
and testing tools for our product across three different operating
system platforms:  Windows, Mac OS X, and Linux.  The suite had to run
on several versions of four or five Linux distributions.  It is all
user mode, unprivileged code.

Windows and OS X rarely had problems with upward compatibility (newer
versions able to run executables built for older versions), but Linux
was living hell.   Shared library compatibility was the biggest
problem.  Not only were shared libraries often incompatible between
different Linux distributions, they were sometimes incompatible even
between different versions of the same distribution.

The problem of keeping shared libraries upward compatible from release
to release was solved circa 1975 by the engineers who designed the
VAX/VMS ABI.  If not before that.  It's not rocket science, but it
does require a degree of discipline, care, and attention to detail
when adding new or incompatible changes to an existing library.  That
bit of developer culture seems to be absent from Linux and the pieces
of GNU that supply Linux's fundamental libraries (libc, etc.).

To bring this back closer to TUHS, I don't know if the Unix
distributions that support shared libraries suffer from the same
problem.

-Paul W.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-07 16:57                                                 ` Warner Losh
@ 2022-06-07 17:05                                                   ` Larry McVoy
  0 siblings, 0 replies; 57+ messages in thread
From: Larry McVoy @ 2022-06-07 17:05 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

On Tue, Jun 07, 2022 at 10:57:15AM -0600, Warner Losh wrote:
> On Tue, Jun 7, 2022, 9:45 AM Larry McVoy <lm@mcvoy.com> wrote:
> 
> > On Tue, Jun 07, 2022 at 10:38:57AM -0600, Warner Losh wrote:
> > > On Tue, Jun 7, 2022, 9:03 AM Will Senn <will.senn@gmail.com> wrote:
> > >
> > > > Interesting crossover from Linux to Linux Distros... Debian's my
> > > > personal fave (in the form of Mint, MX, or even Ubuntu), mostly cuz apt
> > > > seems to just work (for me, ymmv) and rpm sucks :). However, all of
> > > > these run on the same kernel and generally provide the same userland
> > > > (core-utils, etc).
> > >
> > >
> > > But not the same binaries. I've run into a lot of issues trying to run a
> > > binary for Debian on red hat or vice Vera due to shared libraries not
> > being
> > > completely compatible... kinda makes the whole system call argument moot
> > > since there is always significant version skew...
> >
> > Yep, shared libraries can screw you but that's true anywhere.
> >
> 
> Kinda my point: you brag of a misleading compatibility and then attack
> others that decide to slice things up differently and don't have that,
> these days useless, talking point.
> 
> Warner

OK, Warner knower of all things, I'm sure you are right.  It's not like
I've done the things I've talked about, I'm actually an AI bot programmed
to annoy you.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-07 16:46                                               ` Blake McBride
@ 2022-06-07 17:26                                                 ` Paul Winalski
  2022-06-07 20:09                                                   ` Blake McBride
  0 siblings, 1 reply; 57+ messages in thread
From: Paul Winalski @ 2022-06-07 17:26 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On 6/7/22, Blake McBride <blake1024@gmail.com> wrote:
(regarding shared library incompatibility between Linux versions)
>
> That's why God created static linking.

I assume you're being at least partly facetious.  Maintaining upward
compatibility for shared libraries has been a solved problem for about
50 years.  Many OSes other than Linux do/have solved the problem.
There's no excuse for it other than laziness or ignorance.

-Paul W.

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

* [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project
  2022-06-07 17:26                                                 ` Paul Winalski
@ 2022-06-07 20:09                                                   ` Blake McBride
  0 siblings, 0 replies; 57+ messages in thread
From: Blake McBride @ 2022-06-07 20:09 UTC (permalink / raw)
  To: Paul Winalski; +Cc: The Eunuchs Hysterical Society

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

On Tue, Jun 7, 2022 at 12:26 PM Paul Winalski <paul.winalski@gmail.com>
wrote:

> On 6/7/22, Blake McBride <blake1024@gmail.com> wrote:
> (regarding shared library incompatibility between Linux versions)
> >
> > That's why God created static linking.
>
> I assume you're being at least partly facetious.  Maintaining upward
> compatibility for shared libraries has been a solved problem for about
> 50 years.  Many OSes other than Linux do/have solved the problem.
> There's no excuse for it other than laziness or ignorance.
>
> -Paul W.
>

And there is the rub - laziness or ignorance.  Unlike closed systems like
Windows and macOS, it is harder to enforce rules with so many random
developers.  Further, Linux has so many developers that it changes far more
often.

Blake

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

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

* [TUHS] Re: [simh] Announcing the Open SIMH project
  2022-06-07 17:00                                               ` Paul Winalski
@ 2022-06-07 23:41                                                 ` Chris Hanson
  0 siblings, 0 replies; 57+ messages in thread
From: Chris Hanson @ 2022-06-07 23:41 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Jun 7, 2022, at 10:00 AM, Paul Winalski <paul.winalski@gmail.com> wrote:
> 
> Windows and OS X rarely had problems with upward compatibility (newer
> versions able to run executables built for older versions), but Linux
> was living hell. Shared library compatibility was the biggest
> problem. Not only were shared libraries often incompatible between
> different Linux distributions, they were sometimes incompatible even
> between different versions of the same distribution.

That's because, at least when it comes to macOS (nee OS X, nee Mac OS X, nee OPENSTEP/Mach, nee NEXTSTEP in various capitalizations) we treat treat binary compatibility as something for the operating system as a whole to maintain, not just the kernel or the kernel userspace.

Linux's ABI compatibility is itself kind of bare-bones; it achieves userspace compatibility by having a fixed set of system call numbers with well-specified calling sequences that get compiled into every binary for a particular architecture, and it doesn't even attempt to provide the kernel ABI compatibility needed by commercial driver vendors.

We handle userspace ABI compatibility in macOS by actually putting the syscalls on the other side of a shared library (libSystem.dylib) so the calling sequences and syscall numbers are entirely hidden from userspace. We've historically taken a different approach to kernel ABI compatibility but have provided it too, though not to the same extent as userspace.

As an example of where this helps, things like Linux-derived containers would be much faster on non-Linux platforms if the container system could swap in its own "libsyscall.so" instead of having to run atop a VM of some sort to handle the Linux syscall traps.

  -- Chris


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

end of thread, other threads:[~2022-06-07 23:41 UTC | newest]

Thread overview: 57+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <BCDAF4C4-12EC-49D6-84A6-4592E245922F@comcast.net>
     [not found] ` <CAC20D2NGMK1NG3J+iR8t2rAzOc2uWCe9ZGRJzkZn6ECgMETJEQ@mail.gmail.com>
     [not found]   ` <CAC20D2OK9muQm=gCSeRzarV_HQF6vZ9VNuYRas4uCbMyxYKjJA@mail.gmail.com>
2022-06-03 20:00     ` [TUHS] Fwd: [simh] Announcing the Open SIMH project Clem Cole
2022-06-03 20:12       ` [TUHS] " Blake McBride
2022-06-03 20:23       ` G. Branden Robinson
2022-06-03 21:06         ` Clem Cole
2022-06-03 21:20           ` Tom Ivar Helbekkmo via TUHS
2022-06-03 21:32             ` Larry McVoy
2022-06-03 21:34               ` Tom Ivar Helbekkmo via TUHS
2022-06-03 21:37                 ` Larry McVoy
2022-06-03 21:36               ` Tom Ivar Helbekkmo via TUHS
2022-06-03 21:40                 ` Larry McVoy
2022-06-03 22:16                   ` Tom Ivar Helbekkmo via TUHS
2022-06-03 22:30                     ` Larry McVoy
2022-06-03 22:52                       ` Warner Losh
2022-06-03 23:48                         ` Larry McVoy
2022-06-04  0:10                           ` Warner Losh
2022-06-04  1:05                             ` Larry McVoy
2022-06-04  1:46                               ` David Arnold
2022-06-06  0:32                               ` Theodore Ts'o
2022-06-06  0:47                                 ` George Michaelson
2022-06-06  1:17                                   ` Larry McVoy
2022-06-06  1:02                                 ` Warner Losh
2022-06-06  1:09                                 ` Dan Cross
2022-06-06  1:15                                 ` Larry McVoy
2022-06-06  1:40                                   ` Dan Cross
2022-06-06  2:36                                     ` Larry McVoy
2022-06-06 12:43                                       ` Dan Cross
2022-06-06 13:41                                         ` Larry McVoy
2022-06-06 14:27                                           ` Blake McBride
2022-06-06 14:33                                             ` Steve Nickolas
2022-06-06 14:53                                     ` Henry Bent
2022-06-06 23:28                                       ` David Arnold
2022-06-07 14:30                                     ` Theodore Ts'o
2022-06-07 15:08                                       ` Dan Cross
2022-06-07 15:25                                         ` Larry McVoy
2022-06-07 16:03                                           ` Will Senn
2022-06-07 16:38                                             ` Warner Losh
2022-06-07 16:45                                               ` Larry McVoy
2022-06-07 16:57                                                 ` Warner Losh
2022-06-07 17:05                                                   ` Larry McVoy
2022-06-07 16:46                                               ` Blake McBride
2022-06-07 17:26                                                 ` Paul Winalski
2022-06-07 20:09                                                   ` Blake McBride
2022-06-07 17:00                                               ` Paul Winalski
2022-06-07 23:41                                                 ` [TUHS] " Chris Hanson
2022-06-07 15:55                                         ` [TUHS] Re: Fwd: " Richard Salz
2022-06-03 23:56                         ` David Arnold
2022-06-04  0:30                           ` Yeechang Lee
2022-06-04  1:03                             ` Adam Thornton
2022-06-03 22:33                     ` Warner Losh
2022-06-03 22:40                       ` Tom Ivar Helbekkmo via TUHS
2022-06-03 22:56                         ` Warner Losh
2022-06-03 22:26               ` Warner Losh
2022-06-03 22:19             ` Warner Losh
2022-06-03 21:35         ` Ben Walton
2022-06-03 20:52       ` Will Senn
2022-06-03 21:06         ` [TUHS] " Adam Thornton
2022-06-04  9:09           ` Ralph Corderoy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).