The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Larry McVoy <>
To: segaloco <>
Cc: Joseph Holsten <>, segaloco <>
Subject: [TUHS] Re: [OT?] 1993 'Sourceware' paper anniversary. What was right & any surprises?
Date: Wed, 9 Nov 2022 17:42:35 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Nov 10, 2022 at 12:47:37AM +0000, segaloco via TUHS wrote:
> 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.

This is sooooo not true.  I was supporting BitKeeper on all Unix
variations as well as MacOS and Windows from about 2000 to 2018ish.
At the very least you had BSD based systems and Sys5 based systems but
the Sys5 systems had all diverged.  AIX had smit for admin, other systems
would let you edit the /etc files but they were in different locations.
ifconfig was most definitely not compatible across all the systems, nor
was ps.  There were tons and tons of differences.  We ended up pulling in
NetBSDs libc so we at least had one libc (we didn't use the native libc,
yep, you read that right, even that was incompatible).

Even /etc/passwd wasn't consist, some places had /etc/shadow that had the
passwords (I think, it's all getting blurry), and I think there was one,
probably AIX, that had /etc/shadow but not in /etc/shadow.

The best way I can explain all of this is a lack of a dictator over
all the versions.  You need someone who is pushing back on changes and
is making everything consistent.  That's hard to do within a single
organization and impossible over multiple organizations.  POSIX tried
but it wasn't enough.  It helped a little.  If it had worked, we wouldn't
have needed to ship our own libc.

      parent reply	other threads:[~2022-11-10  1:43 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
2022-11-10 13:27             ` Tom Ivar Helbekkmo via TUHS
2022-11-10 15:33           ` Clem Cole
2022-11-10  1:42       ` Larry McVoy [this message]

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:

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

  git send-email \ \ \ \ \ \

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