4 ms·

The solution is simple: ship your fucking dependencies. Every application should ship every dependency it requires. Attempting to use random shit that may or

The solution is simple: ship your fucking dependencies. Every application should ship every dependency it requires. Attempting to use random shit that may or may not be installed on the system is a disaster. Containers that include all dependencies achieves this. Infact I like to argue that the only reason containers exist is because reliably launching software is so outrageously complex the only way to do is create a full system imagine. It’s a modern day tragedy. Disk space is cheap. If every application shipped duplicate dependencies it’d be… totally fine. The downside is inability to update security vulnerabilities. But if everyone is shipping containers that seems kinda moot. iOS and Android don’t have this issue. When you install an app it just works. Windows has the issue somewhat, but it’s mostly a problem with dev tools that are trying to pretend their in Linux. If you ship your fucking dependencies it’s a non-issue.

mab122 4y ago
What is the difference between shipping dependencies and shipping container? Thin layer of metadata? Or am I missing something?
mjevans 4y ago
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
FooBarWidget 4y ago
> The solution is simple: ship your fucking dependencies. And then you get Electron, and people start complaining about the fact that you ship all your dependencies instead of using the dependencies that are already there.
- forrestthewoods 4y ago
  Who is complaining about the install size of Electron? The problem with Electron is it’s laggy and slow. Using a different source for dependencies wouldn’t solve performance. It’d just slightly reduce storage footprint. I mean there’s always someone who complains about something. But if Electron apps had a large folder of binaries but it was super fast and responsive that would eliminate the vast majority of complaints.
  - JohnFen 4y ago
    Install size matters to me. Not as much as other things such as performance and memory footprint, but it still matters.
  - chii 4y ago
    > The problem with Electron is it’s laggy and slow. electron isn't laggy or slow, the app might be because it's poorly written. There are fast electron apps! The complaint about electron i hear the most are 1) the memory footprint - each instance of electron takes up at least a gig of ram. 2) the browser is duplicated, and cannot be upgraded independently (but i argue that is the point of electron). The third, but irrelevant complaint is from people on high horses talking about wanting native apps, and look down on html based apps.
    - pabs3 4y ago
      My complaint with electron is they don't keep up with security updates to the browser engine that electron is a fork of. Even electron-nightly is based on an outdated version of chromium.
  - llanowarelves 4y ago
alkonaut 4y ago
Yes. For a desktop system where you want to update complex multi-gig apps perhaps once per week this isn't just the better option, this is the ONLY option. For a smartphone, the same. For a server or security sensitive system? Perhaps a different scenario. You wouldn't update a dozen large complex apps every week on such a system. I think the issue is that the distros with their application trees are trying to solve a handful of completely different problems. Me updating a 5GB IDE and a Game once a week is not the same problem to solve as running a web server.
pasc1878 4y ago
And this is what NeXTStep/macOS has done for 30 years. Well you could also ship common Frameworks but they all have a version number so should not cause a problem if different apps need different versions of a library. The AppStore or using a library like Sparkle will update when the developer finds an issue or security issue with a dependency. The advantage here is that the OS knows about bundles and so gives an organisation above the file. Anything in that bundle should not be used by anything else. I suspect this is what using containers gives Linux Alternative do as work did 30 years ago - explicitly link to a versioned number of a library. OK then you need to identify which apps use a particular library that needs to be updated for security reasons.

mab122 4y ago

What is the difference between shipping dependencies and shipping container? Thin layer of metadata? Or am I missing something?

mjevans 4y ago

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

FooBarWidget 4y ago

> The solution is simple: ship your fucking dependencies. And then you get Electron, and people start complaining about the fact that you ship all your dependencies instead of using the dependencies that are already there.

forrestthewoods 4y ago
Who is complaining about the install size of Electron? The problem with Electron is it’s laggy and slow. Using a different source for dependencies wouldn’t solve performance. It’d just slightly reduce storage footprint. I mean there’s always someone who complains about something. But if Electron apps had a large folder of binaries but it was super fast and responsive that would eliminate the vast majority of complaints.
- JohnFen 4y ago
  Install size matters to me. Not as much as other things such as performance and memory footprint, but it still matters.
- chii 4y ago
  > The problem with Electron is it’s laggy and slow. electron isn't laggy or slow, the app might be because it's poorly written. There are fast electron apps! The complaint about electron i hear the most are 1) the memory footprint - each instance of electron takes up at least a gig of ram. 2) the browser is duplicated, and cannot be upgraded independently (but i argue that is the point of electron). The third, but irrelevant complaint is from people on high horses talking about wanting native apps, and look down on html based apps.
  - pabs3 4y ago
    My complaint with electron is they don't keep up with security updates to the browser engine that electron is a fork of. Even electron-nightly is based on an outdated version of chromium.
- llanowarelves 4y ago

alkonaut 4y ago

Yes. For a desktop system where you want to update complex multi-gig apps perhaps once per week this isn't just the better option, this is the ONLY option. For a smartphone, the same. For a server or security sensitive system? Perhaps a different scenario. You wouldn't update a dozen large complex apps every week on such a system. I think the issue is that the distros with their application trees are trying to solve a handful of completely different problems. Me updating a 5GB IDE and a Game once a week is not the same problem to solve as running a web server.

pasc1878 4y ago

And this is what NeXTStep/macOS has done for 30 years. Well you could also ship common Frameworks but they all have a version number so should not cause a problem if different apps need different versions of a library. The AppStore or using a library like Sparkle will update when the developer finds an issue or security issue with a dependency. The advantage here is that the OS knows about bundles and so gives an organisation above the file. Anything in that bundle should not be used by anything else. I suspect this is what using containers gives Linux Alternative do as work did 30 years ago - explicitly link to a versioned number of a library. OK then you need to identify which apps use a particular library that needs to be updated for security reasons.