<html><head></head><body>I think this underscores how and why new distros come into being.<br><br>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.<br><br>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.<br><br><div class="gmail_quote">On February 9, 2021 10:28:30 AM EST, Solomon Peachy via Ale <ale@ale.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On Mon, Feb 08, 2021 at 10:47:54AM -0500, Leam Hall via Ale wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">I still think much of Linux could be kept more modular, and my value<br>system thinks it should be that way. Not sure how best to contribute<br>to that cause, though.<br></blockquote><br>Here's the thing. "modular" is an abstract design principle; it does <br>not mean "can arbitrary replace any one component with another and <br>expect it to continue working"<br><br>As an example:<br><br>My 27-year-old GM truck is "modular" -- In its specific model year, they <br>offered five engines, four transmissions, four (or five?) chassis <br>lengths (nearly all in available in three "duties"), three bed sizes, <br>four braking systems, two- and four-wheel-drive, at least half a dozen <br>different front and rear-end + suspension setups, at least five <br>different base cab/body designs, three different gas tank <br>configurations, three variations of the HVAC system, and countless <br>interior/exterior trim options.<br><br>All of this was only possible due to a fairly modular design. But that <br>modularity only really benefitted GM at production time -- The specific <br>combination of modules on my truck isn't easily changed once it rolled <br>off the production line.<br><br>As a more extreme example of this, if I wanted to drop one of the stock <br>factory diesel motors into my truck I'd have to replace the entire fuel, <br>cooling & braking systems, replace (or at least reinforce) the front <br>suspension, and if I am to have any hope of hitting highway speeds, the <br>gearing in the differentials -- which also means I'd need to swap out <br>components in speed sensor electronics so the antilock brakes (and <br>speedometer) will function properly.<br><br>That's a ton of work, but it's entirely doable, and made much easier <br>(versus starting from scratch) due to the modularity of GM's platform <br>and the wide availability of all necessary parts. <br><br>But no matter how much I hack on on it, it's never going to turn into a <br>competitive sports car, as every single component in that truck was <br>designed with the utilitarian nature of a truck in mind.<br><br>Where am I going with this? Linux distros are in the same boat. The <br>underlying bits are _very_ modular, but once a specific combination of <br>modules is assembled, integrated, and tested (ie as part of a "linux <br>distributions") swapping out one or more of those modules after the fact <br>is going to really suck.<br><br>Try swapping out glibc with musl. Sure, it's doable, but you're going <br>to have to rebuild _everything_, and possibly patch a bunch of your <br>software in the process. Swap the "init system" with a different one? <br>You have to adapt everything that interacts with it [1]. Don't like PAM <br>for user authentication? Everything that uses authentication needs to <br>be rebuilt... assuming it even supports what you want. And so on.<br><br>Moving up a layer, there is "modularity" with system services -- For <br>example, Fedora packages least five SQL-compatibile databases, but <br>you're not going to be able to freely switch from one to the other; you <br>might have to partially rewrite your applications, due to differing <br>syntaxes and operating paradigms, or limit yourself to least-common <br>functionality that can and will change over time. Indeed, there's no <br>portable way to guarantee data consistency, which is one of the primary <br>reasons to use SQL databases to begin with!<br><br>...Or networking (especially wifi). Or graphics. Or sound. Or <br>all-singing/dancing "desktop environments". Or (my personal favorite) <br>printing, which is a perpetual dumpster fire in even the best of <br>circumstances. Does anyone here truly apprciate just how complex CUPS <br>is, and how that overall complexity is due to trying to map a <br>more-exceptions-than-rules problem space onto a loosely-coupled, <br>pipe-based UNIX-y approach? [2]<br><br>This holds even at the level of the vaunted "do one thing well" UNIX <br>tools; let's take tar. On my system it's GNU [3] tar; but I could use BSD <br>tar (which one?) if I wanted, right? Or even busybox's tar? Except it <br>turns out I'm using features that only exist in GNU tar [4], so I can't <br>actually switch to a different one unless I limit the features I'm <br>using or use slightly different command line invocations.<br><br>One can only freely swap out modules if they are functionally identical.<br>But if they are identical... why swap them out to begin with? [5]<br><br>All linux distros have made choices about their foundational building <br>blocks and how they're configured. The general purpose distros try to <br>enable as many options as possible and allow them to be configured at <br>runtime (eg by using PAM and SSSD for user management, or lvm vs mdraid <br>vs bare partitioning and a variety of filesystems) but the further down <br>the stack you go, the price/burden of choice goes higher, and at some <br>point one has to say "this is what we're targeting".<br><br>More-focused distros take that "this is what we're targeting, and we're <br>making our choices with that in mind" principle and dial it up,. <br>possibly way up, making a _lot_ of choices that restrict what the <br>end-user can ultimately do. This is especially true for domain-specific <br>distributions (eg OpenWRT) or those that target specific embedded <br>hardware -- eg limits on ram/storage usage, flash-aware filesystems, <br>specialized hardware support, semi-realtime requirements, and so forth)<br><br>But big or small, all of these distros start from the same available set <br>of fundamental building blocks/modules, and mix and match to get what <br>they want -- and along the way, the choices they make restrict the <br>choices available to their userbase.<br><br>But the end-users aren't somehow "less free" if they use OpenWRT vs <br>Debian; in both cases end-users have the same rights to the software; <br>namely the complete corresponding source code to everything and the <br>legal right to modify or replace it. That doesn't mean it will <br>necessarily be _easy_; it takes skill and time to modify things, which <br>you may not have. But that is hardly the fault of distributions like <br>Debian or OpenWRT, or any indididual F/OSS software project or author.<br><br> - Solomon<br><br>[1] Startup "scripts" and daemon ordering, management & reporting tools, etc.<br> Or build some sort of compatibility shim that only exposes the least <br> common functionality across the set. Or convince someone else to<br> carry on this thankless task for you.<br><br>[2] CUPS-as-a-print-server has been completely abandoned by its authors <br> due to it being an eveolutionary dead end. The new model they <br> envision draws those modular boundaries quite differently, resulting <br> in a simpler (and much more robust) overall system, at the price of <br> larger modules. Note that the actual modules usually end up simpler <br> too, as they no longer have to [un]marshal data across an <br> unstrucutured pipe interface, allowing a great deal of <br> mostly-boilerplate-yet-very-error-prone code to no longer be <br> necessary.<br><br>[3] And we all know GNU's Not Unix<br><br>[4] GNU tar's man page is nearly 20 single-spaced pages!<br><br>[5] There is rarely a sound technical reason for this, which leaves <br> "religion" (including licensing) as the primary reason.<br><br> - Solomon</pre></blockquote></div><br>-- <br>Computers amplify human error<br>Super computers are really cool</body></html>