|
|
Subscribe / Log in / New account

Soller: Real hardware breakthroughs, and focusing on rustc

Soller: Real hardware breakthroughs, and focusing on rustc

Posted Dec 2, 2019 11:05 UTC (Mon) by NAR (subscriber, #1313)
In reply to: Soller: Real hardware breakthroughs, and focusing on rustc by nim-nim
Parent article: Soller: Real hardware breakthroughs, and focusing on rustc

I think devs are so drunk on their new tooling ability to bypass free software distributions, they forget users do require a level of stability.

Actually providing stability is a reason to bypass distributions. It's more than annoying when installing/upgrading an unrelated application upgrades a common dependency too with an incompatible new version...


to post comments

Soller: Real hardware breakthroughs, and focusing on rustc

Posted Dec 3, 2019 10:56 UTC (Tue) by roblucid (guest, #48964) [Link]

This argument depends on an application that's broken requiring an obsolete (or new) library implementation for some reason (probably excessive bundling creating a non API implementation dependency).

Library updates should support the API, incompatible API changes require a new package, which may provide a legacy API or support co-existence with an installation of the old library by changing filenames or directories. Shared libraries actually do permit applications choosing different implementations if required.

Rather than 'just in case' silos, fix the bugs and write competent software. Bad security fixes breaking stuff are bugs, regressions which ought be fixed and the sysadmin is the only one who can decide the right mitigation in the deployment ..

The ability to secretly rely on vulnerabilities IS NOT a benefit to the end user

Soller: Real hardware breakthroughs, and focusing on rustc

Posted Dec 3, 2019 13:52 UTC (Tue) by farnz (subscriber, #17727) [Link]

To expand on that, there are three groups involved here, not two:

  1. Users, who don't care about the technical stuff as long as the computer does what they need it to do. Any change, even a security upgrade, is unpopular with users, as there's always the risk that the computer will stop doing what they need it to do on a change; users, however, do want some changes, because they see what the developers can make computers do, and decide they want that.
  2. Developers, who find new ways to make the computer do useful stuff. Developers are keen on some forms of change, because changing things is how you find a new way to make the computer do useful stuff.
  3. Operations, who keep the computer restricted to only doing what the users want it to do, and not doing things that the users don't want. Operations like different forms of change to developers, as they want changes that reduce the chance of the compuer doing things the users don't want it to do.

Distributions that survive end up being a compromise between the three. They update fast enough to keep developers happy; they're good enough at stopping things that you don't want to have happen to keep operations happy; they make the computer do enough useful things that users are happy. But note that distributions are not essential in this set - they just happen to be one form of compromise between the three groups that has historically worked out well enough to survive. Containers are another - especially combined with CI - where you build a complete FS image of the "application" and run it; you regularly update that image, and all is good.

Basically, things go wrong when the desires of the three groups are unbalanced - if a distribution becomes "this is what operations want", then users and developers leave it to ossify; if a distribution becomes "this is what users want", it loses developers and operations; if it becomes "this is what developers want", it loses users and operations. And as every real individual is a combination of users, developers and operations to various degrees, the result of such ossification is a gradual loss of people to work on the distribution.

As soon as distributions see themselves as "in opposition" to developers (or operations, or users), they're at risk - this is about finding a balance between developers' love of using the best technologies they know about, and operations' love of not bringing in tech for the sake of it that results in users getting value from the distribution.


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