4 ms·

This is written from the point of view that implicitly assumes only a single application installed (= a container), where distro is reduced to API provider and

This is written from the point of view that implicitly assumes only a single application installed (= a container), where distro is reduced to API provider and some common utils the app author doesn't care about. It would be correct only if I was building an appliance. But as the user I have a general purpose computer which gets the work done over multiple apps. I think there lies deeper, cultural division between developers, who think the world (at least the computer) revolves around their app and their downstream, who desperately try to avoid more and more code shipped unto them for the upstream's convenience. 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.

microtonal 4y ago
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.
mmis1000 4y ago
I think you are going to have 20 gcc available at same time if you do want this model. Windows literally showed you what would happen if everyone just require their own dependency version. It is choice between a system with bleeding edge / ancient(or sometimes insecure) program mixed together or a system with well audited recent enough programs. Windows/Snaps go for the first, and apt/yum..etc chose the later. It's just all about it.

microtonal 4y ago

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.

mmis1000 4y ago

I think you are going to have 20 gcc available at same time if you do want this model. Windows literally showed you what would happen if everyone just require their own dependency version. It is choice between a system with bleeding edge / ancient(or sometimes insecure) program mixed together or a system with well audited recent enough programs. Windows/Snaps go for the first, and apt/yum..etc chose the later. It's just all about it.