3 ms·

It's not really a difference for upstream if they bundle a dependency or not (or 10k+, in the case of npm), but it quickly becomes a big support burden if you h

It's not really a difference for upstream if they bundle a dependency or not (or 10k+, in the case of npm), but it quickly becomes a big support burden if you have multiple such "apps" installed. But only because distributions want to take control of everything. If a distribution just provided the necessary infrastructure to empower developers to maintain their own dependencies (like eg. Flatpak does), we wouldn’t have this issue.

qwery 4y ago
> distributions want to take control of everything. I'm not sure where that's coming from. Distros/packagers (should) rightly feel a responsibility for a packaged application's quality, security, interoperability. > If a distribution just provided the necessary infrastructure to empower developers to maintain their own dependencies To stick with the Arch Linux example in the article, is the flatpak you get from `# pacman -S flatpak` not suitable for some reason?
- iudqnolq 4y ago
  > I'm not sure where that's coming from. Distros/packagers (should) rightly feel a responsibility for a packaged application's quality, security, interoperability. This seems like false advertising. Ensuring an application is secure would require reading it's source. Based on maintainer complaints (like when that python package added a rust dependency) they don't seem to have the resources to even read all the changelogs.
  - camgunz 4y ago
    It's not really fair to extrapolate from this one instance you keep bringing up to all package maintenance everywhere. I think a more balanced assessment of the current situation would be that by and large the system works, there are 1000s of packages that are up to date, well-maintained and secure to the best of our knowledge, and they function in concert with each other. That's a big job!
throw_a_grenade 4y ago
General purpose computing (and particularly Free Software) is about empowering users, not developers. This quickly becomes important when interests misalign, for example when developers want to push incompatible update to users and stop supporting previous version, or the upstream simply vanishes and stop providing security updates. Why is it OK for developers to "manage dependencies" (pin older versions of libraries) and somehow not for the end user agents (distros) to "manage" their dependencies (i.e. apps)? Moreover, why shouldn't we empower libraries' developers to push their versions as they want? They also have limited manpower and support capabilities.
- microtonal 4y ago
  General purpose computing (and particularly Free Software) is about empowering users, not developers. Empowering users is also making it easy to install what they want or need to install, not just what a distribution decides to offer. To give an example, many people need Slack for work, but distributions don't offer it, because it is non-free. This quickly becomes important when interests misalign, for example when developers want to push incompatible update to users and stop supporting previous version, Why should a distributor decide what my interests are? Also, this argument is kind of strange, if a developer is pushing an incompatible update or stops supporting a previous version, will the distribution continue to maintain the application? Not really. Usually, it just means that the application is frozen in time and you can only hope that security updates are applied. If the application happens to be (e.g.) in Ubuntu Universe, you are usually out of luck and you just get to keep a bunch of applications with known vulnerabilities.
  - pabs3 4y ago
    Looking at the Slack .deb I see that there isn't even any info on what the license is for Slack, so distros couldn't distribute it even in their non-free archives. https://downloads.slack-edge.com/releases/linux/4.28.171/prod/x64/slack-desktop-4.28.171-amd64.deb https://downloads.slack-edge.com/releases/linux/4.28.171/pro... Not only that, but it contains ffmpeg and other LGPL stuff without distributing source code, which seems like an LGPL license violation to me.
friendzis 4y ago
> But only because distributions want to take control of everything. This misses entirety of what distributions are. Distribution is a collection of software packages that in tandem create uniform coherent unit. They only want to control what they distribute. As I have mentioned in another comment, one of the core problems is that we do not understand our dependency trees. If you use version "latest" (or even do not audit your dependency trees not to contain such meta-versions) you consciously relinquish control of dependencies. At this point there is no real difference in power and control between trusting apt and npm not to break anything. Trusting npm (or pip, or whatever) is actually even worse, because they explicitly are just registries without any supervision or soft guarantees.

qwery 4y ago

> distributions want to take control of everything. I'm not sure where that's coming from. Distros/packagers (should) rightly feel a responsibility for a packaged application's quality, security, interoperability. > If a distribution just provided the necessary infrastructure to empower developers to maintain their own dependencies To stick with the Arch Linux example in the article, is the flatpak you get from `# pacman -S flatpak` not suitable for some reason?

iudqnolq 4y ago
> I'm not sure where that's coming from. Distros/packagers (should) rightly feel a responsibility for a packaged application's quality, security, interoperability. This seems like false advertising. Ensuring an application is secure would require reading it's source. Based on maintainer complaints (like when that python package added a rust dependency) they don't seem to have the resources to even read all the changelogs.
- camgunz 4y ago
  It's not really fair to extrapolate from this one instance you keep bringing up to all package maintenance everywhere. I think a more balanced assessment of the current situation would be that by and large the system works, there are 1000s of packages that are up to date, well-maintained and secure to the best of our knowledge, and they function in concert with each other. That's a big job!

throw_a_grenade 4y ago

General purpose computing (and particularly Free Software) is about empowering users, not developers. This quickly becomes important when interests misalign, for example when developers want to push incompatible update to users and stop supporting previous version, or the upstream simply vanishes and stop providing security updates. Why is it OK for developers to "manage dependencies" (pin older versions of libraries) and somehow not for the end user agents (distros) to "manage" their dependencies (i.e. apps)? Moreover, why shouldn't we empower libraries' developers to push their versions as they want? They also have limited manpower and support capabilities.

microtonal 4y ago
General purpose computing (and particularly Free Software) is about empowering users, not developers. Empowering users is also making it easy to install what they want or need to install, not just what a distribution decides to offer. To give an example, many people need Slack for work, but distributions don't offer it, because it is non-free. This quickly becomes important when interests misalign, for example when developers want to push incompatible update to users and stop supporting previous version, Why should a distributor decide what my interests are? Also, this argument is kind of strange, if a developer is pushing an incompatible update or stops supporting a previous version, will the distribution continue to maintain the application? Not really. Usually, it just means that the application is frozen in time and you can only hope that security updates are applied. If the application happens to be (e.g.) in Ubuntu Universe, you are usually out of luck and you just get to keep a bunch of applications with known vulnerabilities.
- pabs3 4y ago
  Looking at the Slack .deb I see that there isn't even any info on what the license is for Slack, so distros couldn't distribute it even in their non-free archives. https://downloads.slack-edge.com/releases/linux/4.28.171/prod/x64/slack-desktop-4.28.171-amd64.deb https://downloads.slack-edge.com/releases/linux/4.28.171/pro... Not only that, but it contains ffmpeg and other LGPL stuff without distributing source code, which seems like an LGPL license violation to me.

friendzis 4y ago

> But only because distributions want to take control of everything. This misses entirety of what distributions are. Distribution is a collection of software packages that in tandem create uniform coherent unit. They only want to control what they distribute. As I have mentioned in another comment, one of the core problems is that we do not understand our dependency trees. If you use version "latest" (or even do not audit your dependency trees not to contain such meta-versions) you consciously relinquish control of dependencies. At this point there is no real difference in power and control between trusting apt and npm not to break anything. Trusting npm (or pip, or whatever) is actually even worse, because they explicitly are just registries without any supervision or soft guarantees.