[ale] Sorry

[Jim Kinney]

I think this underscores how and why new distros come into being.

Over the years I've settled into what causes the least perceived pain for distro use. Had crunchy spots happened earlier or later in my heavy " test them all!" phase, I might be using something different. Inertia matters. Moving to a new release is a pain in the ass. Totally changing distros would have the mental tool chain stumbling.

I gave up on the pursuit of the perfect distro years ago. I'm happy with "didn't move the buttons around much on an upgrade".  Firefox, vim, and ssh are 99% of daily toolchain.

On February 9, 2021 10:28:30 AM EST, Solomon Peachy via Ale <ale at ale.org> wrote:
>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)

-- 
Computers amplify human error
Super computers are really cool
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20210209/40f277ce/attachment.html>