The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Greg A. Woods" <woods@robohack.ca>
To: The Unix Heritage Society mailing list <tuhs@tuhs.org>
Subject: Re: [TUHS] Macs and future unix derivatives
Date: Tue, 16 Feb 2021 14:55:09 -0800	[thread overview]
Message-ID: <m1lC9FN-0036urC@more.local> (raw)
In-Reply-To: <13ded1a4-d717-c57c-5168-0f1f44ca4b5b@gmail.com>

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

Henry Bent <henry.r.bent@gmail.com> wrote:
>      	   			    Apple loves to move quickly and
> abandon compatibility, and in that respect it's an interesting
> counterpoint to Linux or a *BSD where you can have decades old
> binaries that still run.

Nothing in the open-source (OS) world churns and moves around and grows
and wiggles as much as Linux.  The rate of change of the kernel is
simply incomprehensibly staggering.  Linux userland isn't much better
off.

In the commercial (OS) world Microsoft might be churning at a similar
rate.  Apple on the other hand is relatively stable by comparison -- too
stable at times and not always regularly picking up fixes from
third-party projects they make use of.  Apple is guilty of extreme churn
in their GUI though -- at least from a user's perspective (perhaps their
APIs are a bit more stable, but somehow from observing them from afar I
highly doubt it).  Apple's ABIs seem relatively stable -- I still run a
few binary apps (albeit quite simple ones) I installed over a decade ago
and haven't updated since.


At Mon, 8 Feb 2021 22:05:57 -0900, Michael Huff <mphuff@gmail.com> wrote:
Subject: Re: [TUHS] Macs and future unix derivatives
>
> I don't think there's any change on NetBSD, no idea about OpenBSD but
> I assume they're the same.


Indeed, NetBSD/i386 is still a "tier 1" port as of the 9.1 release last
fall:

	http://wiki.NetBSD.org/ports/

Note there is a caveat with regard to true 80386:  "Any i486 or better
CPU should work - genuine Intel or a compatible such as Cyrix, AMD, or
NexGen."

Also NetBSD comes with a good group of compatability and emulation
modules for its kernel ABI, including support for both all of its own
older releases, as well as for port-specific third-party ABI emulations,
such as Linux and SCO Unix.

See for example:  https://wiki.NetBSD.org/guide/linux/

I've only once ever needed to run a Linux binary, and quite a long time
ago, so I'm not so up to date on these things, but it may well be that
NetBSD/i386 can run old 32-bit Linux i386 binaries better than any
current release of Linux.

Personally I work in a world where there's source code for every
application I use, which means I generally only need backward
compatability for the earliest release I might be running at any given
time -- I.e. just enough to keep things running after an upgrade while I
get it all re-compiled and tested.

> In all honest, I don't think that backwards compatibility has ever
> been that great on Linux -at least not for the last twenty or so
> years, in my (limited) experience.

Really good backward compatability for older kernel and library ABIs is
a cornerstone of NetBSD release engineering.  It is very well designed
and implemented and it is pretty much guaranteed to work or get fixed.
Unlike Linux it doesn't rely on shared libraries to work, and also the
system shared libraries have very good backward compatability support as
well.  I.e. NetBSD backward compatability is far more complete and
reliable at all levels (including ABIs and their APIs)

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  reply	other threads:[~2021-02-16 22:55 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-08 18:11 Will Senn
2021-02-08 18:21 ` Larry McVoy
2021-02-08 18:32   ` Justin Coffey
2021-02-08 18:39     ` Larry McVoy
2021-02-09  1:59     ` Theodore Ts'o
2021-02-12 13:48     ` Angel M Alganza
2021-02-08 18:42 ` Henry Bent
2021-02-09  6:55   ` John Gilmore
2021-02-09  7:05     ` Michael Huff
2021-02-16 22:55       ` Greg A. Woods [this message]
2021-02-09  7:17     ` Will Senn
2021-02-09 19:02     ` Theodore Ts'o
2021-02-10  1:34       ` Larry McVoy
2021-02-09 22:59     ` Wesley Parish
2021-02-08 18:43 ` Dan Stromberg
2021-02-12 13:39   ` Angel M Alganza
2021-02-08 18:45 ` Thomas Paulsen
2021-02-25 22:45   ` Dave Horsfall
2021-02-08 20:07 ` Al Kossow
2021-02-09  5:10 ` Andrew Warkentin
2021-02-09  7:42   ` [TUHS] QNX John Gilmore
2021-02-09 11:03     ` Robert Brockway
2021-02-09 18:24       ` Nemo Nusquam
2021-02-09 20:18         ` Jose R Valverde via TUHS
2021-02-09 14:05     ` Larry McVoy
2021-02-09  3:58 [TUHS] Macs and future unix derivatives M Douglas McIlroy
2021-02-09  4:07 ` Adam Thornton
2021-02-09  4:13 ` Will Senn
2021-02-09  5:21 ` Andrew Warkentin
2021-02-09  5:29 ` Theodore Ts'o
2021-02-09  6:37   ` Andrew Warkentin
2021-02-09 16:13     ` Theodore Ts'o
2021-02-09 17:31       ` John Cowan
2021-02-09 19:06         ` Chet Ramey
2021-02-10  2:31       ` Andrew Warkentin
2021-02-09 19:00   ` Jon Steinhart
2021-02-10  1:41     ` Larry McVoy
2021-02-10  1:52       ` George Michaelson
2021-02-10  2:24         ` Larry McVoy
2021-02-10  2:44           ` Dan Cross
2021-02-10  3:10             ` Larry McVoy
2021-02-10 20:03             ` Kevin Bowling
2021-02-10  2:57         ` Warner Losh
2021-02-10  2:56       ` Warner Losh
2021-02-10  3:02         ` Larry McVoy
2021-02-10  3:53       ` Andrew Warkentin
2021-02-09 11:34 ` Thomas Paulsen
2021-02-09 18:29 ` Nemo Nusquam
2021-02-09  8:30 Bakul Shah
2021-02-09 12:22 M Douglas McIlroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1lC9FN-0036urC@more.local \
    --to=woods@robohack.ca \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).