The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: David Arnold <davida@pobox.com>
To: segaloco <segaloco@protonmail.com>
Cc: 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 12:28:49 +1100	[thread overview]
Message-ID: <E91FB522-C02C-4551-B574-2F6071F7A72F@pobox.com> (raw)
In-Reply-To: <xSseKsNvUAE-XBs3p0AWnfIF4oX2rtPcuUI3dieLDA8tD_HLDvmN7-esktM5ca1cZokr6CHHdFX6u4CTK39_nj-4gDRGBS6wMQRgeMqRy-I=@protonmail.com>

> On 10 Nov 2022, at 11:47, segaloco via TUHS <tuhs@tuhs.org> wrote:
> 
> What I find incredibly interesting any time the concept of fragmentation comes up is how did several versions of UNIX with slightly differing interfaces create such a headache for UNIX vendors and users in the day, but now we've got a Linux/BSD landscape out there with still pretty significant differences between distributions and UNIX's progeny seem to be doing just fine.
> 
> Were users looking for different things from their computers in the 90s vs today?  Have folks just gotten more used to variability in computing environments and just accept it as part of the plan?

Two things, I think:
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).
b) A lot of Unix software is now distributed (more or less) by the OS vendor.  Packaging has hidden the portability problem from the end user.

> What comes to mind for me is the different init systems, desktop environments, networking tools, user management tools, and basically that anything that isn't lore in POSIX seems to be up in the air these days.  However, you go back to when SVR4 derivatives were king, they all had the same init, the same useradd, the same /etc/passwd, the same ifconfig.  Maybe some of the snazzier new features were pretty variable, but the most basic stuff like starting your system, creating a user, seeing if you were connected to a network, essential administrative functions, were relatively consistent.
> 
> Nowadays I have to wonder if my init system is runlevel based or some systemd monstrosity.  I have to question whether I can rely on useradd or some other tool being present or if I should forgo it all and just edit the /etc files directly.  Heck, I couldn't say which but I seem to recall a distro I played around with in the past year where this actually didn't work, I had to research whatever arcane user management tools they shipped with that one because whatever they chose broke with convention so much.  I have to pray it has ifconfig or else go look up the docs for iproute2 and iw because nobody can make up their mind on what to replace ifconfig with, just that it has to go and replacing it haphazardly and non-universally is better than fixing/modernizing it.
> 
> Not looking to start some great debate over which of these components is ideal of course, just remarking at the fact that in the early 90s, if you were on a contemporary UNIX system, you'd probably have no trouble modifying system init, adding users, networks, etc., but today I sit down at an unknown Linux machine and I have no confidence that the particular flavor of system administration that I'm used to will be even remotely represented in the subset of tools that particular distro ships.  Luckily, it's free, so perhaps that is what has made the difference, folks are more willing to deal with variability when they aren't paying for what should be a consistent experience, but regardless, the fragmentation in Linux world today feels like it is much more severe than UNIX was in the past, but that's also looking through a lens upon a time I certainly wasn't cognizant of this stuff in.

iOS and Android are the most popular end-user Unix systems.  None of these concerns matter there — they’ve got two completely incompatible layered APIs that hide the fact they’re Unix from applications and users.

Even if you restrict the discussion to non-mobile systems, macOS and ChromeOS probably top the list for end-user systems.  Again, none of these concerns matter.  I mention this to make the point that “Unix” is not what it once was, both in technical terms, and in commercial success.




d

  parent reply	other threads:[~2022-11-10  1:29 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 [this message]
2022-11-10  6:14         ` Theodore Ts'o
2022-11-10  9:12           ` David Arnold
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=E91FB522-C02C-4551-B574-2F6071F7A72F@pobox.com \
    --to=davida@pobox.com \
    --cc=joseph@josephholsten.com \
    --cc=segaloco@protonmail.com \
    --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).