[ale] [EXTERNAL] Re: Sorry

[Beddingfield, Allen]

Using your automobile example, when I say "modular", THIS is what I mean:
If there were a modular design, manufacturers would have an agreed upon standard for engines, transmissions, etc...
So, I would be able to pull the engine out of my Jeep, drop it into your GMC, and put a Ford engine in my Jeep.  Everything would line up, all the hoses, cables, and connectors would just be attached, bolted in, and it would work.  Same with the transmission, etc...
Sort of like ATX, MATX, etc.... case standards.
THAT is how I want all things to work.  It will never happen, though.
Allen B.
--
Allen Beddingfield
Systems Engineer
Office of Information Technology
The University of Alabama
Office 205-348-2251
allen at ua.edu


________________________________________
From: Ale <ale-bounces at ale.org> on behalf of Solomon Peachy via Ale <ale at ale.org>
Sent: Tuesday, February 9, 2021 9:28 AM
To: Leam Hall; Atlanta Linux Enthusiasts
Subject: [EXTERNAL] Re: [ale] Sorry

On Mon, Feb 08, 2021 at 10:47:54AM -0500, Leam Hall via Ale wrote:
> I still think much of Linux could be kept more modular, and my value
> system thinks it should be that way. Not sure how best to contribute
> to that cause, though.

Here's the thing.  "modular" is an abstract design principle; it does
not mean "can arbitrary replace any one component with another and
expect it to continue working"

As an example:

My 27-year-old GM truck is "modular" -- In its specific model year, they
offered five engines, four transmissions, four (or five?) chassis
lengths (nearly all in available in three "duties"), three bed sizes,
four braking systems, two- and four-wheel-drive, at least half a dozen
different front and rear-end + suspension setups, at least five
different base cab/body designs, three different gas tank
configurations, three variations of the HVAC system, and countless
interior/exterior trim options.

All of this was only possible due to a fairly modular design.  But that
modularity only really benefitted GM at production time -- The specific
combination of modules on my truck isn't easily changed once it rolled
off the production line.

As a more extreme example of this, if I wanted to drop one of the stock
factory diesel motors into my truck I'd have to replace the entire fuel,
cooling & braking systems, replace (or at least reinforce) the front
suspension, and if I am to have any hope of hitting highway speeds, the
gearing in the differentials -- which also means I'd need to swap out
components in speed sensor electronics so the antilock brakes (and
speedometer) will function properly.

That's a ton of work, but it's entirely doable, and made much easier
(versus starting from scratch) due to the modularity of GM's platform
and the wide availability of all necessary parts.

But no matter how much I hack on on it, it's never going to turn into a
competitive sports car, as every single component in that truck was
designed with the utilitarian nature of a truck in mind.

Where am I going with this?  Linux distros are in the same boat. The
underlying bits are _very_ modular, but once a specific combination of
modules is assembled, integrated, and tested (ie as part of a "linux
distributions") swapping out one or more of those modules after the fact
is going to really suck.

Try swapping out glibc with musl.  Sure, it's doable, but you're going
to have to rebuild _everything_, and possibly patch a bunch of your
software in the process.  Swap the "init system" with a different one?
You have to adapt everything that interacts with it [1].  Don't like PAM
for user authentication?  Everything that uses authentication needs to
be rebuilt... assuming it even supports what you want. And so on.

Moving up a layer, there is "modularity" with system services -- For
example, Fedora packages least five SQL-compatibile databases, but
you're not going to be able to freely switch from one to the other; you
might have to partially rewrite your applications, due to differing
syntaxes and operating paradigms, or limit yourself to least-common
functionality that can and will change over time.  Indeed, there's no
portable way to guarantee data consistency, which is one of the primary
reasons to use SQL databases to begin with!

...Or networking (especially wifi).  Or graphics.  Or sound.  Or
all-singing/dancing "desktop environments".  Or (my personal favorite)
printing, which is a perpetual dumpster fire in even the best of
circumstances.  Does anyone here truly apprciate just how complex CUPS
is, and how that overall complexity is due to trying to map a
more-exceptions-than-rules problem space onto a loosely-coupled,
pipe-based UNIX-y approach? [2]

This holds even at the level of the vaunted "do one thing well" UNIX
tools; let's take tar.  On my system it's GNU [3] tar; but I could use BSD
tar (which one?) if I wanted, right? Or even busybox's tar?  Except it
turns out I'm using features that only exist in GNU tar [4], so I can't
actually switch to a different one unless I limit the features I'm
using or use slightly different command line invocations.

One can only freely swap out modules if they are functionally identical.
But if they are identical... why swap them out to begin with? [5]

All linux distros have made choices about their foundational building
blocks and how they're configured.  The general purpose distros try to
enable as many options as possible and allow them to be configured at
runtime (eg by using PAM and SSSD for user management, or lvm vs mdraid
vs bare partitioning and a variety of filesystems) but the further down
the stack you go, the price/burden of choice goes higher, and at some
point one has to say "this is what we're targeting".

More-focused distros take that "this is what we're targeting, and we're
making our choices with that in mind" principle and dial it up,.
possibly way up, making a _lot_ of choices that restrict what the
end-user can ultimately do. This is especially true for domain-specific
distributions (eg OpenWRT) or those that target specific embedded
hardware -- eg limits on ram/storage usage, flash-aware filesystems,
specialized hardware support, semi-realtime requirements, and so forth)

But big or small, all of these distros start from the same available set
of fundamental building blocks/modules, and mix and match to get what
they want -- and along the way, the choices they make restrict the
choices available to their userbase.

But the end-users aren't somehow "less free" if they use OpenWRT vs
Debian; in both cases end-users have the same rights to the software;
namely the complete corresponding source code to everything and the
legal right to modify or replace it.  That doesn't mean it will
necessarily be _easy_; it takes skill and time to modify things, which
you may not have.  But that is hardly the fault of distributions like
Debian or OpenWRT, or any indididual F/OSS software project or author.

 - Solomon

[1] Startup "scripts" and daemon ordering, management & reporting tools, etc.
    Or build some sort of compatibility shim that only exposes the least
    common functionality across the set.  Or convince someone else to
    carry on this thankless task for you.

[2] CUPS-as-a-print-server has been completely abandoned by its authors
    due to it being an eveolutionary dead end.  The new model they
    envision draws those modular boundaries quite differently, resulting
    in a simpler (and much more robust) overall system, at the price of
    larger modules.  Note that the actual modules usually end up simpler
    too, as they no longer have to [un]marshal data across an
    unstrucutured pipe interface, allowing a great deal of
    mostly-boilerplate-yet-very-error-prone code to no longer be
    necessary.

[3] And we all know GNU's Not Unix

[4] GNU tar's man page is nearly 20 single-spaced pages!

[5] There is rarely a sound technical reason for this, which leaves
    "religion" (including licensing) as the primary reason.

 - Solomon
--
Solomon Peachy                        pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)