4 ms·

There is, I think, a bit of a paradigm shift in action. In the old world, disk space was limited and download speeds were slow. So it made sense for every app

by edent 4y ago

There is, I think, a bit of a paradigm shift in action. In the old world, disk space was limited and download speeds were slow. So it made sense for every app to use the system-provided version of Library X. Additionally, stability and backwards compatibility was assumed. So if the distro updated to Library X v1.2, and your app relied on v1.1, everything would still work. Today's world is very different (for many users). Disk space is cheap and plentiful and downloading a couple of GB takes an instant. So why not bundle everything together? Additionally, developers can't be sure of stability in their dependencies. And the app developer is the person who receives the complaints from angry users, not the library developer. So it makes perfect sense to use a self-contained set of libraries and dependencies. The pendulum will swing the other way in time. We'll all get annoyed at having a dozen different Electron libraries taking up space, and we'll go back to one-library-to-rule-them all. But - as someone who used to hate battling dependency hell - I love Flatpack.

Karellen 4y ago
> Additionally, stability and backwards compatibility was assumed. So if the distro updated to Library X v1.2, and your app relied on v1.1, everything would still work. I thought all the cool kids had adopted `semver` these days, so this shouldn't be a problem? Except for crappy libraries/dependencies, in which case surely the answer is: Don't use crappy dependencies; find an alternative that does the same thing, without sucking. > Additionally, developers can't be sure of stability in their dependencies. Again, be more judicious in which dependencies you use. Stay away from the crap ones, find ones that do the right thing. > Disk space is cheap and plentiful and downloading a couple of GB takes an instant. Maybe for you. But not for everyone on the planet. Or, maybe people who live in places with intermittent internet connectivity don't deserve new software, or for their needs to be considered? > So why not bundle everything together? Security. If a serious vulnerability is found in Library X v1.1, I want to be able to upgrade it to Library X v1.1.1 and know that every single app that uses it is safe, without even needing to know which apps use it. I don't want to have to figure out which apps use it (which, OK, might not be too hard if the tools are written to find that out), and then have to download an update for every single one. Even if I do have unlimited gigabit broadband, that could still be awkward if the library is sufficiently popular and widely used.
okasaki 4y ago
> Disk space is cheap and plentiful and downloading a couple of GB takes an instant. True in a data center. Not true for many people. > So why not bundle everything together? Security updates, RAM usage.
- edent 4y ago
  > True in a data center. Not true for many people. Even the cheapest laptop you can buy today has literally 1,000x the disk space of a 1990's tower PC. The packaging format APT was developed in the late 1990s when the average user's modem speed was unlikely to hit 56kbps. Times have changed. Time to update the way we package software. > Security updates, RAM usage. True in a data centre. Not true for many people.
  - spookie 4y ago
    Even the simplest of program today is way bigger than an alternative of yesterday. I don't see your point.
  - oriolid 4y ago
    There's also the option that we could finally end the hardware upgrade cycle. After all, the laptop that I already have costs me less both in money and setup time than even the cheapest laptop I could buy if I was forced to. For desktop app developers it's other people's money so it's not as important.
ginko 4y ago
>Additionally, developers can't be sure of stability in their dependencies. And the app developer is the person who receives the complaints from angry users, not the library developer. That seems like the main issue to me. Why has it become acceptable for libraries to break backwards compatibility left and right?
goodpoint 4y ago
> In the old world, disk space was limited and download speeds were slow No, the problem is that production systems need to receive fine-grained and timely security updates. You can't rebuild, test and deploy a whole OS every time a vulnerability in OpenSSL is fixed. It would be extremely risky for any non-trivial production workload. Disk space is not the issue. Distributions do the crucial and painstaking work of backporting security fixes. This cannot be done when applications are shipped with huge blobs of dependencies, like with flatpack or containers, it's simply too much work for any organization to do that.

by edent 4y ago

Karellen 4y ago

> Additionally, stability and backwards compatibility was assumed. So if the distro updated to Library X v1.2, and your app relied on v1.1, everything would still work. I thought all the cool kids had adopted `semver` these days, so this shouldn't be a problem? Except for crappy libraries/dependencies, in which case surely the answer is: Don't use crappy dependencies; find an alternative that does the same thing, without sucking. > Additionally, developers can't be sure of stability in their dependencies. Again, be more judicious in which dependencies you use. Stay away from the crap ones, find ones that do the right thing. > Disk space is cheap and plentiful and downloading a couple of GB takes an instant. Maybe for you. But not for everyone on the planet. Or, maybe people who live in places with intermittent internet connectivity don't deserve new software, or for their needs to be considered? > So why not bundle everything together? Security. If a serious vulnerability is found in Library X v1.1, I want to be able to upgrade it to Library X v1.1.1 and know that every single app that uses it is safe, without even needing to know which apps use it. I don't want to have to figure out which apps use it (which, OK, might not be too hard if the tools are written to find that out), and then have to download an update for every single one. Even if I do have unlimited gigabit broadband, that could still be awkward if the library is sufficiently popular and widely used.

okasaki 4y ago

> Disk space is cheap and plentiful and downloading a couple of GB takes an instant. True in a data center. Not true for many people. > So why not bundle everything together? Security updates, RAM usage.

edent 4y ago
> True in a data center. Not true for many people. Even the cheapest laptop you can buy today has literally 1,000x the disk space of a 1990's tower PC. The packaging format APT was developed in the late 1990s when the average user's modem speed was unlikely to hit 56kbps. Times have changed. Time to update the way we package software. > Security updates, RAM usage. True in a data centre. Not true for many people.
- spookie 4y ago
  Even the simplest of program today is way bigger than an alternative of yesterday. I don't see your point.
- oriolid 4y ago
  There's also the option that we could finally end the hardware upgrade cycle. After all, the laptop that I already have costs me less both in money and setup time than even the cheapest laptop I could buy if I was forced to. For desktop app developers it's other people's money so it's not as important.

ginko 4y ago

>Additionally, developers can't be sure of stability in their dependencies. And the app developer is the person who receives the complaints from angry users, not the library developer. That seems like the main issue to me. Why has it become acceptable for libraries to break backwards compatibility left and right?

goodpoint 4y ago

> In the old world, disk space was limited and download speeds were slow No, the problem is that production systems need to receive fine-grained and timely security updates. You can't rebuild, test and deploy a whole OS every time a vulnerability in OpenSSL is fixed. It would be extremely risky for any non-trivial production workload. Disk space is not the issue. Distributions do the crucial and painstaking work of backporting security fixes. This cannot be done when applications are shipped with huge blobs of dependencies, like with flatpack or containers, it's simply too much work for any organization to do that.