The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: David Arnold <davida@pobox.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: segaloco <segaloco@protonmail.com>,
	Joseph Holsten <joseph@josephholsten.com>,
	segaloco <tuhs@tuhs.org>
Subject: [TUHS] Re: [OT?] 1993 'Sourceware' paper anniversary. What was right & any surprises?
Date: Thu, 10 Nov 2022 20:12:32 +1100	[thread overview]
Message-ID: <FCEE2FB2-2FB0-43B1-9CCC-9637DD6B13B8@pobox.com> (raw)
In-Reply-To: <Y2yWy8BYFxFiIy4D@mit.edu>

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

> On 10 Nov 2022, at 17:14, Theodore Ts'o <tytso@mit.edu> wrote:
> On Thu, Nov 10, 2022 at 12:28:49PM +1100, David Arnold wrote:

>> a) Today most identifiably Unix software is “sourceware”, and so the
>> differences between Linuxes, *BSD, and macOS are fairly easily
>> taken care of (eg. with autotools).
> 
> I'd also argue that (a) the differences between the Linuxes aren't as
> big some people would make it out to be --- especially compared to the
> differences between AIX and Solaris and HPUX, and (b) *BSD and macOS
> has their ports and homebrew systems which also ease any pai that
> isn't handled by autoconf and friends.

I agree.

The differences between desktop/server Linux distributions are largely invisible to application code.  THe most obvious exceptions are locations for files. I’ve found it’s basically easier to deal with that dynamically (in the application code), rather than doing an autoconf-based distro switch.  Init script vs. units, etc, are minor issues too.

Sometimes I’ve found a particular platform doesn’t have a package for eg. the right SSL library, or the right version of something, but that’s fairly rare, and mostly able to be worked around by being conservative in dependency choices.

Alpine’s use of musl rather than glibc was a bigger problem, but musl is increasingly glibc compatible.  Other libc versions used by embedded platforms, create more problems, but then those applications tend to be fairly narrowly targeted anyway.

But all that said … it’s a heap easier than making source code compile across every common Unix in the mid-to-late 90’s.




d


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

  reply	other threads:[~2022-11-10  9:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-09 22:01 [TUHS] " steve jenkin
2022-11-09 22:16 ` [TUHS] " Larry McVoy
2022-11-09 22:24   ` Clem Cole
2022-11-09 22:51   ` Joseph Holsten
2022-11-10  0:47     ` segaloco via TUHS
2022-11-10  0:54       ` Joseph Holsten
2022-11-10  1:28       ` David Arnold
2022-11-10  6:14         ` Theodore Ts'o
2022-11-10  9:12           ` David Arnold [this message]
2022-11-10 13:27             ` Tom Ivar Helbekkmo via TUHS
2022-11-10 15:33           ` Clem Cole
2022-11-10  1:42       ` Larry McVoy

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=FCEE2FB2-2FB0-43B1-9CCC-9637DD6B13B8@pobox.com \
    --to=davida@pobox.com \
    --cc=joseph@josephholsten.com \
    --cc=segaloco@protonmail.com \
    --cc=tuhs@tuhs.org \
    --cc=tytso@mit.edu \
    /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).