6 ms·

Hot take: package distributors are 'fake jobs' that don't need to exist, or exist only for the make-work of packaging. Tools like flatpak, snap, appimage, conta

Hot take: package distributors are 'fake jobs' that don't need to exist, or exist only for the make-work of packaging. Tools like flatpak, snap, appimage, containerization, etc. have made the need for adapting software to different distributions unnecessary.

bombolo 4y ago
I don't want debian to be like the android app store, where there are thousands apps that work badly and overflow me with ads. I much prefer the f-droid model, of having curated repositories to keep crap outside. Also, I can't understand why people on the internet think that upstream developers are omniscient. They make lots of mistakes and errors. Distribute maintainers fix a lot of things, and send the fixes to the authors.
- qbasic_forever 4y ago
  There's nothing stopping someone from making a flatpak or other similar tech feed or 'store' that's only the curated apps they deem appropriate for users. Bugs should be fixed upstream, not kept in distro specific silos. There's no reason why only a packager can fix some upstream issues or become a contributor. On the contrary shipping your app as a universal tech like flatpak means Redhat, Debian, Arch or any other user can use it, develop for it, and send fixes upstream.
  - creshal 4y ago
    The strawman sounds compelling on the surface, but that's not what happens in practice: Bug fixes are sent upstream by all relevant distributions, and they regularly cooperate with each other directly, as well as upstream. The "new world" of users of all distributions working together has been reality for the past 20+ years.
  - noirscape 4y ago
    > Bugs should be fixed upstream, not kept in distro specific silos. This is mostly a Debian issue fwiw. Debian is literally notable because they're obsessed with making sure that any package in their repositories is kept with the same "API"[0], no matter how old the software is. The result is that Debian packages can end up hugely derivative compared to the equivalent of upstream and other distros, but it's usually also because the software in question is half a decade old. With other distros, packaging changes to upstream usually just reflect the preference to match a certain style of configuration (to pull another example from Debian: nginx ships with sites-{enabled,available} folders and is configured to load from sites-enabled by default. This is to match the same configuration style that's used for apache2 and that it's associated tools assume you configure apache2 with, even though nginx just uses a conf.d folder and has no extra tools to facilitate anything fancy with sites-{enabled,available}). The extreme end is nix, which actively requires you to have the upstream written with nix in mind because nix will basically demand you configure the source code in ways to accommodate for it. [0]: This includes actual software-intended interfaces and the ones hacked together by users by ie. reading out logfiles.
    - creshal 4y ago
      And even Debian tries to upstream fixes where feasible, which isn't too uncommon for security vulnerabilities, they tend to lurk in old parts of codebases that haven't been refactored for a while.
    - ParetoOptimal 4y ago
      > The extreme end is nix, which actively requires you to have the upstream written with nix in mind because nix will basically demand you configure the source code in ways to accommodate for it. I'm pretty sure this isn't true. What does upstream emacs have to do for Nix to provide https://github.com/NixOS/nixpkgs/blob/nixos-22.11/pkgs/applications/editors/emacs/generic.nix https://github.com/NixOS/nixpkgs/blob/nixos-22.11/pkgs/appli... I will agree though that applications which have their own update mechanism or do other things that make reproducibility harder are much more difficult to create a Nix expression for.
  - account42 4y ago
    Bugs should be fixed upstream but unfortunately sometimes upstream does not see them as bugs - for example, telemetry.
bayesian_horse 4y ago
There is a very good and strong use case for a "distribution" of packages working well together. But those packages need to be selected carefully.
- qbasic_forever 4y ago
  I agree but I don't think the software packages themselves should be held back by the available time and attention of packagers. In the new world a packager or distro creator can just pick and choose what flatpaks, snaps, appimage, etc. sources they deem good enough to push to users. They shouldn't be a roadblock in the way of users getting the latest version of software.
  - bombolo 4y ago
    Then you install the new version, find out it requires a new version of python and all its libraries, but you can't install it because pytorch only works on old versions of python.
    - qbasic_forever 4y ago
      That doesn't happen when apps are packaged in their own containers with all dependencies. The new version you installed has its own python dependencies.
AnIdiotOnTheNet 4y ago
I agree. Maintainers are useless middlemen (at best) who only exist because of Linux userland's particular diseases and a desire for distros to rule over their own little repo fiefdoms. No other desktop OS has done it like Linux and for good reason. People have been citing this as a reason they don't want to use Linux as a desktop for decades to mostly deaf ears, who then turn around and wonder loudly why no one wants to use their OS. Hell, even Linus Torvalds himself complained about it.
- simon_o 4y ago
  This has to be the dumbest take on this thread. If you want the dystopian hellhole you seemingly long for, just use Android and enjoy the ad-infested crapware? No reason to moan about things you seemingly don't understand.
  - deleted 4y ago
    [deleted]
- Steltek 4y ago
  I have no earthly idea what you are talking about. For decades, Linux package managers have been the killer app for Linux. They made installing and updating every single one of your applications trivial. You didn't google for sketchy download sites and unsigned exe's. You didn't have to fight the system to cleanly uninstall things. Even release upgrades were the smoothest thing ever. In 25 years, I've never had a Debian release upgrade go wrong. Anyone bitching about package managers as user hostile is a flat out idiot.
  - AnIdiotOnTheNet 4y ago
    What's wrong isn't so much the package managers as the necessity for them and for an army of third party volunteers to maintain packages and all the problems that predictably arise from that. Linus famously complained about how things work at DebConf 14[0], but I guess he's an idiot for doing so? That's a pretty hot take but whatever. If a package is not in the repo? Sorry, you have to compile from source. Want a newer version? Compile from source and hope that the build environment dependencies are in the repo. Want an older version for some reason? Break out docker or KVM so you don't break your system. None of this is fundamental to the model, that much is true, but in practice it is how all Linux distributions using a package manager/repo model without things like Snap, AppImage, and Flatpak work. Here's the best part though: Even with Flatpaks and AppImage you can still use a repo! In fact Fedora Silverblue, which uses an immutable base system and installs everything through Flatpak and Toolbox, uses a Fedora controlled Flatpak repo by default. [0] http://saimei.ftp.acc.umu.se/pub/debian-meetings/2014/debconf14/webm/QA_with_Linus_Torvalds.webm http://saimei.ftp.acc.umu.se/pub/debian-meetings/2014/debcon...
cardanome 4y ago
Yeah, if you don't mind hugely increased start-up times, RAM usage and less curation and more crap, sure no need for package distribution. I personally do mind very much. Just the differences in startup times between apt and snap applications are huge and I would absolutely despise working with such a sluggish system. I would rather build everything myself from source if forced to.
- vetinari 4y ago
  That snap slowness is snap's problem, not general non-apt problem. Flatpak doesn't suffer from it.
- Karunamon 4y ago
  The mass proliferation of electron and other such webpages-as-desktop-applications would seem to indicate that the average user doesn't care for any of those things.
  - cardanome 4y ago
    So much weird assumptions. First of all, there is no such thing as an average user. Also, it is not relevant to the discussion. I care about what I want in a system, not what some imaginary users want. Now, we could stop there but I will play: Electron solves a real problem for developers. Writing cross-platform GUI apps is a real pain. Yes, there are native solution but ensuring the user has the exact same experience on every platform tends to be orders of magnitude more costly compare to web based solutions. (That or they are exotic options like Lazarus with Free Pascal that have a much lower Developer pool.) Many apps wouldn't even have Linux ports if they were not written on Electron. Now, why do users accept them? Why are they not out-competed by native solution? Oh, honey. Why do I have Microsoft Teams installed? Because I like it? Hell, no! Because I need it for work. Why do I have the Discord Client? Because it is great? Nah, I long for good old IRC but Discord it there the people currently are. Did I think the Epic Games launcher is such an great app? Nah, they bought me with offering free games. Users tolerate shitty software for many reasons, mostly because they have to. It does not follow from that, that they don't mind software being shitty.
Steltek 4y ago
What's the base image for the containers? Do none of your Dockerfiles have apk or apt commands?
- qbasic_forever 4y ago
  It's best practice not to have any shell tools in your app container, including package managers. It bloats the image and can be a security vulnerability if a zero day exploit hits the app. Ideally a container is something like distroless which just has the libc and dependencies you care about and nothing else, not even bash.
  - Steltek 4y ago
    But where do your dependencies come from? Your compiler? Are you building everything from source after libc?
    - qbasic_forever 4y ago
      If you're shipping modern code like go or rust you have a static build with no real dependencies. If you're shipping a scripting language like python you're probably going to use their base images, and if you're shipping native C/C++ you have to figure out your risk tolerance for trusting a distro to ship good dependencies vs. just building them yourself. It's not hard to build all your deps in a container, and arguably is the best security practice so you have total control and knowledge of their versions.
  - m4rtink 4y ago
    Wouldn't something like that be really hard to debug in real world scenarios ?
account42 4y ago
As long as there is unavoidable software made by organizations like Mozilla that don't care for their users's choices there is an important role for distributions: To make sure what you get is what you want.
ranger207 4y ago
I agree. Devs would like to statically link and have their app work. Maintainers don't want that to happen for IMO reasons that have far less benefit than claimed. flatpak and snap are ultimately efforts to get around the vortex of maintainers, maintainer efforts to get things not to be statically linked, and all the complexity that entails. I think there's still currently value in distro maintainers that do things like getting KDE running on Wayland using pipewire, but IMO that role should be limited to configuration and compilation only. There should not be any distro-specific patches in existence
- bombolo 4y ago
  > Maintainers don't want that to happen for IMO reasons that have far less benefit than claimed. You have apparently no idea how much it costs to recompile everything, every single time that openssl fixes a bug.

bombolo 4y ago

I don't want debian to be like the android app store, where there are thousands apps that work badly and overflow me with ads. I much prefer the f-droid model, of having curated repositories to keep crap outside. Also, I can't understand why people on the internet think that upstream developers are omniscient. They make lots of mistakes and errors. Distribute maintainers fix a lot of things, and send the fixes to the authors.

qbasic_forever 4y ago
There's nothing stopping someone from making a flatpak or other similar tech feed or 'store' that's only the curated apps they deem appropriate for users. Bugs should be fixed upstream, not kept in distro specific silos. There's no reason why only a packager can fix some upstream issues or become a contributor. On the contrary shipping your app as a universal tech like flatpak means Redhat, Debian, Arch or any other user can use it, develop for it, and send fixes upstream.
- creshal 4y ago
  The strawman sounds compelling on the surface, but that's not what happens in practice: Bug fixes are sent upstream by all relevant distributions, and they regularly cooperate with each other directly, as well as upstream. The "new world" of users of all distributions working together has been reality for the past 20+ years.
- noirscape 4y ago
  > Bugs should be fixed upstream, not kept in distro specific silos. This is mostly a Debian issue fwiw. Debian is literally notable because they're obsessed with making sure that any package in their repositories is kept with the same "API"[0], no matter how old the software is. The result is that Debian packages can end up hugely derivative compared to the equivalent of upstream and other distros, but it's usually also because the software in question is half a decade old. With other distros, packaging changes to upstream usually just reflect the preference to match a certain style of configuration (to pull another example from Debian: nginx ships with sites-{enabled,available} folders and is configured to load from sites-enabled by default. This is to match the same configuration style that's used for apache2 and that it's associated tools assume you configure apache2 with, even though nginx just uses a conf.d folder and has no extra tools to facilitate anything fancy with sites-{enabled,available}). The extreme end is nix, which actively requires you to have the upstream written with nix in mind because nix will basically demand you configure the source code in ways to accommodate for it. [0]: This includes actual software-intended interfaces and the ones hacked together by users by ie. reading out logfiles.
  - creshal 4y ago
    And even Debian tries to upstream fixes where feasible, which isn't too uncommon for security vulnerabilities, they tend to lurk in old parts of codebases that haven't been refactored for a while.
  - ParetoOptimal 4y ago
    > The extreme end is nix, which actively requires you to have the upstream written with nix in mind because nix will basically demand you configure the source code in ways to accommodate for it. I'm pretty sure this isn't true. What does upstream emacs have to do for Nix to provide https://github.com/NixOS/nixpkgs/blob/nixos-22.11/pkgs/applications/editors/emacs/generic.nix https://github.com/NixOS/nixpkgs/blob/nixos-22.11/pkgs/appli... I will agree though that applications which have their own update mechanism or do other things that make reproducibility harder are much more difficult to create a Nix expression for.
- account42 4y ago
  Bugs should be fixed upstream but unfortunately sometimes upstream does not see them as bugs - for example, telemetry.

bayesian_horse 4y ago

There is a very good and strong use case for a "distribution" of packages working well together. But those packages need to be selected carefully.

qbasic_forever 4y ago
I agree but I don't think the software packages themselves should be held back by the available time and attention of packagers. In the new world a packager or distro creator can just pick and choose what flatpaks, snaps, appimage, etc. sources they deem good enough to push to users. They shouldn't be a roadblock in the way of users getting the latest version of software.
- bombolo 4y ago
  Then you install the new version, find out it requires a new version of python and all its libraries, but you can't install it because pytorch only works on old versions of python.
  - qbasic_forever 4y ago
    That doesn't happen when apps are packaged in their own containers with all dependencies. The new version you installed has its own python dependencies.

AnIdiotOnTheNet 4y ago

I agree. Maintainers are useless middlemen (at best) who only exist because of Linux userland's particular diseases and a desire for distros to rule over their own little repo fiefdoms. No other desktop OS has done it like Linux and for good reason. People have been citing this as a reason they don't want to use Linux as a desktop for decades to mostly deaf ears, who then turn around and wonder loudly why no one wants to use their OS. Hell, even Linus Torvalds himself complained about it.

simon_o 4y ago
This has to be the dumbest take on this thread. If you want the dystopian hellhole you seemingly long for, just use Android and enjoy the ad-infested crapware? No reason to moan about things you seemingly don't understand.
- deleted 4y ago
  [deleted]
Steltek 4y ago
I have no earthly idea what you are talking about. For decades, Linux package managers have been the killer app for Linux. They made installing and updating every single one of your applications trivial. You didn't google for sketchy download sites and unsigned exe's. You didn't have to fight the system to cleanly uninstall things. Even release upgrades were the smoothest thing ever. In 25 years, I've never had a Debian release upgrade go wrong. Anyone bitching about package managers as user hostile is a flat out idiot.
- AnIdiotOnTheNet 4y ago
  What's wrong isn't so much the package managers as the necessity for them and for an army of third party volunteers to maintain packages and all the problems that predictably arise from that. Linus famously complained about how things work at DebConf 14[0], but I guess he's an idiot for doing so? That's a pretty hot take but whatever. If a package is not in the repo? Sorry, you have to compile from source. Want a newer version? Compile from source and hope that the build environment dependencies are in the repo. Want an older version for some reason? Break out docker or KVM so you don't break your system. None of this is fundamental to the model, that much is true, but in practice it is how all Linux distributions using a package manager/repo model without things like Snap, AppImage, and Flatpak work. Here's the best part though: Even with Flatpaks and AppImage you can still use a repo! In fact Fedora Silverblue, which uses an immutable base system and installs everything through Flatpak and Toolbox, uses a Fedora controlled Flatpak repo by default. [0] http://saimei.ftp.acc.umu.se/pub/debian-meetings/2014/debconf14/webm/QA_with_Linus_Torvalds.webm http://saimei.ftp.acc.umu.se/pub/debian-meetings/2014/debcon...

cardanome 4y ago

Yeah, if you don't mind hugely increased start-up times, RAM usage and less curation and more crap, sure no need for package distribution. I personally do mind very much. Just the differences in startup times between apt and snap applications are huge and I would absolutely despise working with such a sluggish system. I would rather build everything myself from source if forced to.

vetinari 4y ago
That snap slowness is snap's problem, not general non-apt problem. Flatpak doesn't suffer from it.
Karunamon 4y ago
The mass proliferation of electron and other such webpages-as-desktop-applications would seem to indicate that the average user doesn't care for any of those things.
- cardanome 4y ago
  So much weird assumptions. First of all, there is no such thing as an average user. Also, it is not relevant to the discussion. I care about what I want in a system, not what some imaginary users want. Now, we could stop there but I will play: Electron solves a real problem for developers. Writing cross-platform GUI apps is a real pain. Yes, there are native solution but ensuring the user has the exact same experience on every platform tends to be orders of magnitude more costly compare to web based solutions. (That or they are exotic options like Lazarus with Free Pascal that have a much lower Developer pool.) Many apps wouldn't even have Linux ports if they were not written on Electron. Now, why do users accept them? Why are they not out-competed by native solution? Oh, honey. Why do I have Microsoft Teams installed? Because I like it? Hell, no! Because I need it for work. Why do I have the Discord Client? Because it is great? Nah, I long for good old IRC but Discord it there the people currently are. Did I think the Epic Games launcher is such an great app? Nah, they bought me with offering free games. Users tolerate shitty software for many reasons, mostly because they have to. It does not follow from that, that they don't mind software being shitty.

Steltek 4y ago

What's the base image for the containers? Do none of your Dockerfiles have apk or apt commands?

qbasic_forever 4y ago
It's best practice not to have any shell tools in your app container, including package managers. It bloats the image and can be a security vulnerability if a zero day exploit hits the app. Ideally a container is something like distroless which just has the libc and dependencies you care about and nothing else, not even bash.
- Steltek 4y ago
  But where do your dependencies come from? Your compiler? Are you building everything from source after libc?
  - qbasic_forever 4y ago
    If you're shipping modern code like go or rust you have a static build with no real dependencies. If you're shipping a scripting language like python you're probably going to use their base images, and if you're shipping native C/C++ you have to figure out your risk tolerance for trusting a distro to ship good dependencies vs. just building them yourself. It's not hard to build all your deps in a container, and arguably is the best security practice so you have total control and knowledge of their versions.
- m4rtink 4y ago
  Wouldn't something like that be really hard to debug in real world scenarios ?

account42 4y ago

As long as there is unavoidable software made by organizations like Mozilla that don't care for their users's choices there is an important role for distributions: To make sure what you get is what you want.

ranger207 4y ago

I agree. Devs would like to statically link and have their app work. Maintainers don't want that to happen for IMO reasons that have far less benefit than claimed. flatpak and snap are ultimately efforts to get around the vortex of maintainers, maintainer efforts to get things not to be statically linked, and all the complexity that entails. I think there's still currently value in distro maintainers that do things like getting KDE running on Wayland using pipewire, but IMO that role should be limited to configuration and compilation only. There should not be any distro-specific patches in existence

bombolo 4y ago
> Maintainers don't want that to happen for IMO reasons that have far less benefit than claimed. You have apparently no idea how much it costs to recompile everything, every single time that openssl fixes a bug.