Re: [TUHS] Macs and future unix derivatives

[Jon Steinhart <jon@fourwinds.com>]

Theodore Ts'o writes:
> On Mon, Feb 08, 2021 at 10:58:08PM -0500, M Douglas McIlroy wrote:
> > > Do they *really* want something which is just V7 Unix, with nothing else?
> > > No TCP/IP, no hot-plug USB support?  No web browsing?
> > 
> > > Oh, you wanted more than that?  Feature bloat!  Feature bloat!
> > > Feature bloat!   Shame!  Shame!   Shame!
> > 
> > % ls /usr/share/man/man2|wc
> >     495     495    7230
> > % ls /bin|wc
> >    2809    2809   30468
> > 
> > How many of roughly 500 system calls (to say nothing of uncounted
> > ioctl's) do you think are necessary for writing those few crucial
> > capabilities that distinguish Linux from v7? There is
> > undeniably bloat, but only a sliver of it contributes to the
> > distinctive utility of today's systems.
>
> Well, let's take a look at those system calls.  They fall into a
> number of major categories:
>
> *) BSD innovations
>   *) BSD socket interfaces (so if you want TCP/IP... is it bloat?)
>   *) BSD job control
>   *) BSD effective id and its extensions
>   *) BSD groups
> *) New versions to maintain stable ABI's, e.g., (dup vs dup2 vs dup3,
>    wait vs wait3 vs wait4 vs waitpid, stat vs stat64, lstat vs lstat64,
>    chown vs chown32, etc.)
> *) System V IPC support (is support for enterprise databases like
>    Oracle "bloat"?)
> *) Posix real-time extensions
> *) Posix extended attributes
> *) Windows file streams support (the original reason for the *at(2)
>    system calls -- openat, linkat, renameat, and a dozen more)
>
> Ok, that last I'd agree was *pure* bloat, and an amazingly bad idea.
> But there are plenty of people who have bugged/begged me to add
> windows file streams because they were *convinced* it was a critical
> feature.  And I dare say bug-for-bugs Windows compatibility was worth
> millions of $$$ of potential sales, which is why they agreed to add it
> --- and why I kept on getting nagged to add that feature to ext4 (and
> I pushed back where the Solaris developers caved, so there.  :-)
>
> As for things like System V IPC support, that was only added to Linux
> because it was worth $$$, because enterprise databases like DB2 and
> Oracle demanded it.  Is that evidence of "cancer"?  You might not want
> it, but that's a great example of "one person's bloat is another
> person's critical feature".
>
> Or consider the dozen plus BSD sockets interface, which if removed
> would mean no TCP/IP support, and no graphical windowing systems.
> Critical feature, or bloat?
>
> But hey, if you only want V7 Unix, why are you complaining?  Just go
> and use it, and give up on all of this cancerous new features.  And I
> promise to get off of your lawn.  :-)

I'm with Doug here.  Some time ago, I was asked to give a talk at OSU
based on my life with UNIX.  Mostly figured out what to say while
driving down there.  I started the talk by posing the question of what
makes UNIX great.  I said that while many people had different answers,
to me it was the good abstractions and the composability of programs
that it supported.  I then asked why so many people had forgotten that
which started a very lively discussion.

When I look at linux (and pretty much anything else today), the loss of
good abstractions is quite evident and in my opinion is responsible for
much of the bloat and mess.

This didn't begin with linux.  To me, it started when UNIX moved out of
research.  Changes were made without any artistry or elegance.  And it
happened in BSD-land too.  I never liked the socket interface, would
have preferred to open("/dev/ip").  But, as Clem and I have discussed,
the socket API was the result of the original code coming from elsewhere
(BBN I think), and the political desire to keep the networking code
separable from the rest of the kernel.

At this point in time, I feel that linux is suffering from the tragedy
of the commons.  I'm not interested in getting into an argument over
this.  My opinion is that I think that more direction would have helped.
I think that there was a golden era for contribution that has passed.
There was a time when because of cost of machines and education that
open-source contributors were somewhat of the same caliber.  But now that
machines are essentially free and every java programmer thinks that they
know everything, the quality of contributions and especially design has
dropped.

While I use linux, it's no longer a system that I trust in any way.  It's
huge, bloated, rats-nest undocumented code.  Yes, I know that a small
percentage of people like Ted spend a lot of time on the code and therefore
know it well.  But I find it an impenetrable mess.  When I first had a need
to look at the UNIX kernel, it was easy to figure out what was going on.  Not
so with linux.  Of course, I'm getting old and maybe not as good at this stuff
as I used to be.

You might claim that the code is stable and debugged, but if that was the case
then I wouldn't be getting a new kernel on practically every daily update.

To me, it also seems like linux is focused on two ends of the spectrum with
the middle mostly ignored.  Lots of focus on embedded and data centers.  As
a desktop system, it's tolerable but generally annoying.  Again, somewhat a
function of the tragedy of the commons; the environment consists of programs
with little consistency.  I think that if one compared the user interfaces to,
let's say, gimp, audacity, and blender, the common features would be close to
the null set.  And those are just a few "major" programs.

So a more interesting question to me is, when is linux going to die under its
own weight, and what if anything will replace it.  With the exception of
Windows, most everything today has some roots in UNIX.  If one was going to
reimagine a system going back to the UNIX philosophy, what would it look like?
Is there likely to ever be an opportunity for a replacement, designed system
or are we stuck with the status quo forever?

Jon