Conill: The long-term consequences of maintainers’ actions [LWN.net]

Conill: The long-term consequences of maintainers’ actions

Posted Sep 19, 2021 15:47 UTC (Sun) by ilammy (subscriber, #145312)
In reply to: Conill: The long-term consequences of maintainers’ actions by pizza
Parent article: Conill: The long-term consequences of maintainers’ actions

> A key difference is that Cargo only helps those already capable of recompiling the software. If you don't have the complete source code to _everything_ then you can't fix it yourself, period.

But that’s already the case for FOSS distributions. They have all the source code available. They have the automatic build infrastructure. (Or well, should have it.) Rebuilding the world surely wastes time, electricity, bandwidth, storage space – more than ideally maintained dynamic linking ecosystem would – but it’s not impossible. Popularity of static-link-only paradigm shows that people are willing to rather accept some waste than maintain ABI compatibility.

> You can't rely on a third party (eg distributions or some other system integrator) to update that one component and generate a new binary.

But people rely on their distributions and vendors all the time to keep stuff updated.

to post comments

Conill: The long-term consequences of maintainers’ actions

Posted Sep 19, 2021 17:08 UTC (Sun) by pizza (subscriber, #46) [Link]

> But that’s already the case for FOSS distributions.

Much as I'd like it to be otherwise, FOSS distributions only ship a tiny portion of the software being written, and are not where most folks get their software. Indeed, this is gleefully called an advantage by the static-linked-world proponents ("cut out the middleman!") even though in practical terms this shifts F/OSS more like proprietary stuff.

But even putting aside proprietary software (which tends to fall more on the Apache OpenOffice side of the competency/responsiveness curve rather than LibreOffice side) the overwhelming trend is to push the F/OSS world into a app-store model with an all-in-one opaque blob per application that might as well be statically linked for all the technical ability an end-user has to modify things. The store itself has no ability to update anything; at best all it can do is scan for a known issue and prevent future downloads if a problem is found. Actually fixing things falls back to whomever "owns" that software's entry on the store. The software might as well be proprietary at that point.

We've been down this route before, more than once, and it has not gone well.

Conill: The long-term consequences of maintainers’ actions

Posted Sep 19, 2021 22:09 UTC (Sun) by JanC_ (subscriber, #34940) [Link]

Automatic rebuilds would also trigger automatic updates everywhere much more frequently than they do now, and I can tell you that would upset pretty much anyone.