From: segaloco via TUHS <firstname.lastname@example.org>
To: Joseph Holsten <email@example.com>
Cc: segaloco <firstname.lastname@example.org>
Subject: [TUHS] Re: [OT?] 1993 'Sourceware' paper anniversary. What was right & any surprises?
Date: Thu, 10 Nov 2022 00:47:37 +0000 [thread overview]
Message-ID: <xSseKsNvUAE-XBs3p0AWnfIF4oX2rtPcuUI3dieLDA8tD_HLDvmN7-esktM5ca1cZokr6CHHdFX6u4CTK39_nj-4gDRGBS6wMQRgeMqRy-Iemail@example.com> (raw)
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?
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.
Anywho, that was definitely an informative read, thanks for the share. As someone who is constantly trying to dial in my own personal Linux distro, the questions of standardization and uniformity feature in my mind often.
- Matt G.
------- Original Message -------
On Wednesday, November 9th, 2022 at 2:51 PM, Joseph Holsten <firstname.lastname@example.org> wrote:
> On Wed, Nov 9, 2022, at 14:16, Larry McVoy wrote:
> > On Thu, Nov 10, 2022 at 09:01:42AM +1100, steve jenkin wrote:
> > > I???ve only recently stumbled across this paper.
> > >
> > > It gives the answer to one question I???ve had:
> > >
> > > Why did Linux become more popular than everything that came before it?
> > Yeah, that was a difficult time. My boss, Ken Okin (SVP of all server
> > hardware) didn't like the switch from SunOS to SVR4 any more than I did.
> > He paid me to go argue with the execs for 6 months. That paper was
> > the result.
> > It obviously went nowhere and Linux won. Big surprise.
> > The one thing I learned in that 6 months was respect for the execs.
> > As an engineer, I had the luxury of taking the time to solve a problem and
> > know that I solved it correctly. The execs didn't have that. They had
> > to make decisions essentially with their gut, they couldn't afford the
> > time to figure out the right answer, they had to come up with the right
> > answer on the fly. I don't think I could do that.
> It’s painful to look at where (Open)Solaris was when Oracle acquired it and where it is now. SMF, Zones, ZFS, dtrace, mdb. Oracle Cloud doesn’t use Solaris for anything. I can’t recall hearing anyone using dtrace or ZFS around the place.
> Meanwhile, illumos derivs have actually done interesting things. Not that NexenStor or SmartOS have made a big dent, but at least they’ve had more recent ideas to copy.
> Joseph Holsten
next prev parent reply other threads:[~2022-11-10 0:48 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 [this message]
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
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).