7 ms·

The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. And application develop

by zorr 3y ago

The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. And application developers have to essentially wait for each distro to repackage their app before it becomes available on that distro. Or start messing with alternate repositories for each distro they want to support. The old model works for established software, but breaks down a little now that it becomes easier to write software applications. Personally I use my distro packages for foundational stuff (DE, systemd, tools and utilities) but I use an alternative package manager (flatpak) for most other applications. What Flatpak, Snap and AppImage try to achieve is to limit the packaging burden for both distro maintainers and application developers, so that end-user applications can become immediately available on a wide variety of distros.

dTal 3y ago
AppImage is not like the other two, it is fundamentally just a way to make a self-contained binary directory into a single runnable file - a way to avoid having to tell the user to extract a tarball and run a particular file inside. Convenience, nothing more. The other two define entire alternate runtimes.
- bionade24 3y ago
  No, an Appimage still ships a dynamically linked executable + lots of dynamically linked libraries, that only link against system libraries when strictly needed, e.g glibc and libGL. Those files are bundled in a squashfs and have a script setting a custom LD_LIBRARY_PATH to the squashfs content for the binary. Snap does use this technique, too, but does more, for worse. AppImages are not comparable with statically linked binaries.
  - dTal 3y ago
    I can't make out what you're disagreeing with - you seem to be arguing against something I didn't say? The point is that the contents of an AppImage - "a dynamically linked executable + lots of dynamically linked libraries" - works just as well without all the squashfs backflips. If you can ship an AppImage, you can ship a regular ol' tarball with a binary named "RunMe" inside. The purpose of an AppImage is simply to condense such a tarball to a single runnable file, for convenience - nothing more. Meanwhile, Snap and Flatpak are package managers - what's more, they're invasive heavyweights with permanent costs that are even worse than distro package managers. Snap permanently runs a daemon, and Flatpak requires you to run programs with "flatpak run" - yuck! They are both trying to impose some dubious vision of sandboxed apps that require bureaucracy to communicate with each other, instead of just tackling the core issue of software distribution. Maybe you even like sandboxing! But I've seen no justification why that should be co-mingled with package management.
    - Kinrany 3y ago
      > But I've seen no justification why that should be co-mingled with package management. Building sandboxing on top of package management makes a lot of sense because you want sandboxing to work by default, and for that you need to identify the sandboxable things without making the user point to each one individually.
      - simon_o 3y ago
        > want sandboxing to work by default Yeah, wake me up when Flatpak is remotely close to doing this. Most "apps" simply disable the sandbox. Not to mention I'm not going to trust "app" developers setting their own permissions. That's the job of package maintainers.
        bionade24 3y ago
        Afaik they disable filesystem sandboxing, not process namespaces. Still better if programs can't ptrace around, although this is indeed a big issue. If someone knows why this sandboxing is better/worse than SELinux or AppArmor access rules, can you pls elaborate? I'd really like to know.
        simon_o 3y ago
        I'm not comparing sandboxing against SELinux/AppArmor. It's a social problem, not a technical one. I'm comparing "app developers holding themselves accountable" to "package maintainers dish out consequences for misbehavior". I have absolutely zero trust in the former, and lots of trust in the latter.
        account42 3y ago
        You don't need any fancy packaging to restrict ptrace: https://www.kernel.org/doc/Documentation/security/Yama.txt https://www.kernel.org/doc/Documentation/security/Yama.txt
        Kinrany 3y ago
        What do you mean? If package developers don't specify permissions correctly, their code doesn't work when sandboxed.
phkahler 3y ago
>> The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. That's kinda what the distros ARE. Also, if you're debian based and debian packages are not compatible with your distribution you're actively fucking something up for "reasons" - stop doing that. If an app can't use a standard .deb or .rpm then the distro is doing something wrong. If dependency version management is too hard, someone is doing something wrong - not sure who, could be a library maintainer or an app maintainter. Let's not ship half an OS with every app to avoid this stuff.
- mikae1 3y ago
  > That's kinda what the distros ARE. What things are can change, sometimes for the better. Imagine if distros maintainers could spend their time doing something more productive than doing the same work as hundreds of others are doing.
  - mulmen 3y ago
    But if hundreds of distro maintainers don’t do it then millions of users have to do it.
    - tapoxi 3y ago
      No, users don't do it. The application developers do it in their CI pipelines. Application developers should be the ones building and testing the app, not distro maintainers responsible for a dozen other applications.
      - prmoustache 3y ago
        History has shown that application developers are very bad at releasing good deliverable without too much security holes in the packaged libraries or bad practices. And the sandboxing in flatpak is actually meant to protect users from harm done by clueless devs but it fails because devs can actually build non sandboxed flatpaks and they will do it because they don't care
calvinmorrison 3y ago
> The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. You know, that was never a problem when we had to package the other 500000 packages available in debian, just when users want seemingly popular packages updated more than once per decade. Firefox for starters.
JustSomeNobody 3y ago
> The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. That's ... kind of the job of a distro maintainer.
- wander_homer 3y ago
  Can you name one distribution which isn't severely understaffed?
JohnFen 3y ago
> The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. But isn't that the primary job of a distro?
- zorr 3y ago
  For base packages like desktop environments, tools, libraries, popular applications, etc, yes. But I don't think they should be responsible for every end-user third party application. It's a massive waste of time for everyone involved.
  - JohnFen 3y ago
    I think they should be responsible for the packages in their package manager. That's the main thing that distros do. For software that they can't do this with, or that isn't worth their time, they just omit it from the package manager.
CoolCold 3y ago
I feel one day you will make step further and join me on Windows desktop path:)
tpoacher 3y ago
> And application developers have to essentially wait for each distro to repackage their app before it becomes available on that distro. Nonsense. Developers can do their thing, and distro maintainers can do theirs. The two have very different priorities and goals. I'm perfectly happy downloading the latest version of hip package X directly from the developer's website while relying on distro packages for all the boring, stable stuff. The whole "it's either all hip or all boring" is a false dichotomy.

by zorr 3y ago

dTal 3y ago

AppImage is not like the other two, it is fundamentally just a way to make a self-contained binary directory into a single runnable file - a way to avoid having to tell the user to extract a tarball and run a particular file inside. Convenience, nothing more. The other two define entire alternate runtimes.

bionade24 3y ago
No, an Appimage still ships a dynamically linked executable + lots of dynamically linked libraries, that only link against system libraries when strictly needed, e.g glibc and libGL. Those files are bundled in a squashfs and have a script setting a custom LD_LIBRARY_PATH to the squashfs content for the binary. Snap does use this technique, too, but does more, for worse. AppImages are not comparable with statically linked binaries.
- dTal 3y ago
  I can't make out what you're disagreeing with - you seem to be arguing against something I didn't say? The point is that the contents of an AppImage - "a dynamically linked executable + lots of dynamically linked libraries" - works just as well without all the squashfs backflips. If you can ship an AppImage, you can ship a regular ol' tarball with a binary named "RunMe" inside. The purpose of an AppImage is simply to condense such a tarball to a single runnable file, for convenience - nothing more. Meanwhile, Snap and Flatpak are package managers - what's more, they're invasive heavyweights with permanent costs that are even worse than distro package managers. Snap permanently runs a daemon, and Flatpak requires you to run programs with "flatpak run" - yuck! They are both trying to impose some dubious vision of sandboxed apps that require bureaucracy to communicate with each other, instead of just tackling the core issue of software distribution. Maybe you even like sandboxing! But I've seen no justification why that should be co-mingled with package management.
  - Kinrany 3y ago
    > But I've seen no justification why that should be co-mingled with package management. Building sandboxing on top of package management makes a lot of sense because you want sandboxing to work by default, and for that you need to identify the sandboxable things without making the user point to each one individually.
    - simon_o 3y ago
      > want sandboxing to work by default Yeah, wake me up when Flatpak is remotely close to doing this. Most "apps" simply disable the sandbox. Not to mention I'm not going to trust "app" developers setting their own permissions. That's the job of package maintainers.
      - bionade24 3y ago
        Afaik they disable filesystem sandboxing, not process namespaces. Still better if programs can't ptrace around, although this is indeed a big issue. If someone knows why this sandboxing is better/worse than SELinux or AppArmor access rules, can you pls elaborate? I'd really like to know.
        simon_o 3y ago
        I'm not comparing sandboxing against SELinux/AppArmor. It's a social problem, not a technical one. I'm comparing "app developers holding themselves accountable" to "package maintainers dish out consequences for misbehavior". I have absolutely zero trust in the former, and lots of trust in the latter.
        account42 3y ago
        You don't need any fancy packaging to restrict ptrace: https://www.kernel.org/doc/Documentation/security/Yama.txt https://www.kernel.org/doc/Documentation/security/Yama.txt
      - Kinrany 3y ago
        What do you mean? If package developers don't specify permissions correctly, their code doesn't work when sandboxed.

phkahler 3y ago

>> The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. That's kinda what the distros ARE. Also, if you're debian based and debian packages are not compatible with your distribution you're actively fucking something up for "reasons" - stop doing that. If an app can't use a standard .deb or .rpm then the distro is doing something wrong. If dependency version management is too hard, someone is doing something wrong - not sure who, could be a library maintainer or an app maintainter. Let's not ship half an OS with every app to avoid this stuff.

mikae1 3y ago
> That's kinda what the distros ARE. What things are can change, sometimes for the better. Imagine if distros maintainers could spend their time doing something more productive than doing the same work as hundreds of others are doing.
- mulmen 3y ago
  But if hundreds of distro maintainers don’t do it then millions of users have to do it.
  - tapoxi 3y ago
    No, users don't do it. The application developers do it in their CI pipelines. Application developers should be the ones building and testing the app, not distro maintainers responsible for a dozen other applications.
    - prmoustache 3y ago
      History has shown that application developers are very bad at releasing good deliverable without too much security holes in the packaged libraries or bad practices. And the sandboxing in flatpak is actually meant to protect users from harm done by clueless devs but it fails because devs can actually build non sandboxed flatpaks and they will do it because they don't care

calvinmorrison 3y ago

> The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. You know, that was never a problem when we had to package the other 500000 packages available in debian, just when users want seemingly popular packages updated more than once per decade. Firefox for starters.

JustSomeNobody 3y ago

> The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. That's ... kind of the job of a distro maintainer.

wander_homer 3y ago
Can you name one distribution which isn't severely understaffed?

JohnFen 3y ago

> The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. But isn't that the primary job of a distro?

zorr 3y ago
For base packages like desktop environments, tools, libraries, popular applications, etc, yes. But I don't think they should be responsible for every end-user third party application. It's a massive waste of time for everyone involved.
- JohnFen 3y ago
  I think they should be responsible for the packages in their package manager. That's the main thing that distros do. For software that they can't do this with, or that isn't worth their time, they just omit it from the package manager.

CoolCold 3y ago

I feel one day you will make step further and join me on Windows desktop path:)

tpoacher 3y ago

> And application developers have to essentially wait for each distro to repackage their app before it becomes available on that distro. Nonsense. Developers can do their thing, and distro maintainers can do theirs. The two have very different priorities and goals. I'm perfectly happy downloading the latest version of hip package X directly from the developer's website while relying on distro packages for all the boring, stable stuff. The whole "it's either all hip or all boring" is a false dichotomy.