5 ms·

Every security update means updating every big bundle of packages when it's a small change in some commonly used core library. Even IF my bandwidth and time we

Every security update means updating every big bundle of packages when it's a small change in some commonly used core library. Even IF my bandwidth and time were free (neither are) that is still a ton of duplicated work and wear on non-volatile memory life.

forrestthewoods 4y ago
> Every security update means updating every big bundle of packages when it's a small change in some commonly used core library. Replacing all instances of libFFMoeg.so on a drive is not particularly harder than replacing one. > that is still a ton of duplicated work and wear on non-volatile memory life. Nonsense. We’re talking about replacing libraries on the order tens to hundreds of megabytes during a monthly update. It’s peanuts. Time I’ll give you. But the current system of system-wide libraries is objectively broken. As evidenced by the increasing usage of containers to work around the brokenness. I’d wager far more time is wasted on docker orchestration. It’s probably worth differentiating between servers and personal machines. Lord knows how many vulnerabilities are in your Steam library. It’s a lot.
- teddyh 4y ago
  It’s not harder for you, when you do it, for your package which you maintain. However, when your machine has N large bundles of packages installed, and an issue is found with a vendored dependency in all of them, you have to wait for every single one of them to be upgraded, which requires the work of N people, individually, none of whom work for you.
- chii 4y ago
  > Replacing all instances of libFFMoeg.so on a drive is not particularly harder than replacing one. but how would you know the new version works with the app? And how do you even know the app needed this library? Are you going to now investigate every app, and check that the library needed updating? It's work, even if each individual app has only a small amount, it will add up. And not to mention _every_ user would need to do it for themselves.
  - forrestthewoods 4y ago
    > but how would you know the new version works with the app? How is this any different than replacing one instance of a library that is then used by all applications?
- spookie 4y ago
  I always feel that takes like "a few hundreds of MB is peanuts" are the marker of someone so privileged, that they have never thought about those not living in a developed country. We really need to get this mentality sorted, as we are quite literally blocking everyone else from better technology.
  - rascul 4y ago
    Even in developed countries there are people and areas that don't have fast internet connections, at least not without significant cost.
- goodpoint 4y ago
  > Replacing all instances of libFFMoeg.so on a drive is not particularly harder than replacing one. Instead, ensuring that your applications do not break is extremely hard.
compsciphd 4y ago
It's only due to the way docker containers and the like are constructed. Predating docker by a few years I built a docker like mechanism that viewed what docker calls layers (i also used the term) as packages in a traditional distribution. Instead of unpackaging a package into a file systme, the package is just a layer that can be unioned in on demand (for live updates, though in the age of containizerization, this hasn't aged as well, so in practice it be running a new container). link to paper is somewhere in the threads here

forrestthewoods 4y ago

> Every security update means updating every big bundle of packages when it's a small change in some commonly used core library. Replacing all instances of libFFMoeg.so on a drive is not particularly harder than replacing one. > that is still a ton of duplicated work and wear on non-volatile memory life. Nonsense. We’re talking about replacing libraries on the order tens to hundreds of megabytes during a monthly update. It’s peanuts. Time I’ll give you. But the current system of system-wide libraries is objectively broken. As evidenced by the increasing usage of containers to work around the brokenness. I’d wager far more time is wasted on docker orchestration. It’s probably worth differentiating between servers and personal machines. Lord knows how many vulnerabilities are in your Steam library. It’s a lot.

teddyh 4y ago
It’s not harder for you, when you do it, for your package which you maintain. However, when your machine has N large bundles of packages installed, and an issue is found with a vendored dependency in all of them, you have to wait for every single one of them to be upgraded, which requires the work of N people, individually, none of whom work for you.
chii 4y ago
> Replacing all instances of libFFMoeg.so on a drive is not particularly harder than replacing one. but how would you know the new version works with the app? And how do you even know the app needed this library? Are you going to now investigate every app, and check that the library needed updating? It's work, even if each individual app has only a small amount, it will add up. And not to mention _every_ user would need to do it for themselves.
- forrestthewoods 4y ago
  > but how would you know the new version works with the app? How is this any different than replacing one instance of a library that is then used by all applications?
spookie 4y ago
I always feel that takes like "a few hundreds of MB is peanuts" are the marker of someone so privileged, that they have never thought about those not living in a developed country. We really need to get this mentality sorted, as we are quite literally blocking everyone else from better technology.
- rascul 4y ago
  Even in developed countries there are people and areas that don't have fast internet connections, at least not without significant cost.
goodpoint 4y ago
> Replacing all instances of libFFMoeg.so on a drive is not particularly harder than replacing one. Instead, ensuring that your applications do not break is extremely hard.

compsciphd 4y ago

It's only due to the way docker containers and the like are constructed. Predating docker by a few years I built a docker like mechanism that viewed what docker calls layers (i also used the term) as packages in a traditional distribution. Instead of unpackaging a package into a file systme, the package is just a layer that can be unioned in on demand (for live updates, though in the age of containizerization, this hasn't aged as well, so in practice it be running a new container). link to paper is somewhere in the threads here