|
|
Log in / Subscribe / Register

Conill: The long-term consequences of maintainers’ actions

Conill: The long-term consequences of maintainers’ actions

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

> Package management infrastructure is different now. Thinks like Cargo make updating dependencies easier. It’s not a quest of figuring out which of your dependencies exactly embed zlib and how to update it for their bespoke build system. Another thing is this static linking by default approach which makes maintaining ABI compatibility less of a concern: just rebuild everything when you need to upgrade something.

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. 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.

Rust (plus Go and all other static-link-only paradigms) makes you completely at the mercy of the software developer / vendor for all updates and fixes. That's what made the zlib thing so bad, and Cargo/etc won't change this -- even the relatively trivial "change your crate list to pull in a fixed version and recompile" actions represent more effort than has been historically demonstrated.


to post comments

Conill: The long-term consequences of maintainers’ actions

Posted Sep 19, 2021 15:47 UTC (Sun) by ilammy (subscriber, #145312) [Link] (2 responses)

> 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.

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.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds