9 ms·

I can see why Snap is like it is from Canonial's perspective - but from the User perspective it seems like FlatPaks[1] are much better and address the issues th

I can see why Snap is like it is from Canonial's perspective - but from the User perspective it seems like FlatPaks[1] are much better and address the issues that this article raises [1] https://flathub.org/home https://flathub.org/home (Disclaimer: I'm talking in a personal capacity but the company I work for in my day job now owns Red Hat - I don't work on Linux Operating Systems).

lawl 6y ago
> but from the User perspective it seems like FlatPaks[1] are much better and address the issues that this article raises This is interesting, because the last few days I was actually working on packaging an application of mine as a snap/flatpak. From my PoV, they both have their fair share of issues. Snaps enforce a sandbox, which I think is actually a good idea, because the desktop security model is somewhat broken. If your application cannot run as a sandboxed app, you need to be granted special permissions by canonical after manual review (my app needs this), where they also discuss if they can make a new permission in a safe way for your usecase that everyone can use afterwards. On one hand this sucks because I need to ask canonical for permission to publish something, and there's no certainty that I will get these permissions as a nobody for a new app nobody ever heard of before. On the other hand, I think I like that they're doing something about the desktop security model. The next problem is, if this is denied, how do I ship updates? Provide a self updater? Easy to write, but if everyone does that, we can just go full windows and abandon package managers. Tell people to just curl | bash? That's not more secure than a potentially shady snap. But I do have to praise canonical for being very helpful in IRC and the forums for helping me debug issues and file bugs against snap stuff. Now flatpak on the other hand, just feels kinda weird to me. It sandboxes things, but every application can pretty much grant itself access to everything. This is a completely different philosophy, but if you rely on everyone tightly sandboxing their applications without granting themselves permissions for sandbox escape, I think something like landlock[0] (when it lands) or pledge is much more suited for this, and baked into the application. Then there is this weird thing where flatpaks force a runtime on you. My application is a statically linked go binary. But flatpaks pretty much want to force me to add an entire freedesktop suite as a dependency, as you simply cannot choose no runtime. (Community-)Support for building flatpaks? Pretty much non-existant. So yeah, the entire linux upstream-packaging situation is still quite depressing honestly. And with the time and energy I have invested into this by now, I could have written a simple but sufficient self-updater about 10 times over. [0]: https://landlock.io/ https://landlock.io/
- d1plo1d 6y ago
  I'm in a similar boat with regards to launching a new, unknown product in the snap store. As an interim solution I'm planning to ask users to do use the beta flag: `snap install my-app --beta` which gets me around the secure sandbox requirements.
  - galgalesh 6y ago
    Did you mean devmode instead of beta? Just wanted to easy one worry of you: the age, popularity and maturity of your application has no influence on whether or not these permission requests are granted. The approval process is formally defined and mostly depends on what your application does exactly. You can find the specific processes in the docs at the bottom of this page: https://snapcraft.io/docs/permission-requests https://snapcraft.io/docs/permission-requests
- still_grokking 6y ago
  As a user I don't like neither Snaps (that for sure as this is Cannonical only) nor FlatPaks (as they seem conceptually a "80% solution" which combines the problems of package systems with the problems of self-contianed apps, but don't improve on anything). For me the only acceptable solution besides proper .debs are AppImages. AppImage doesn't try to "replace" the package management for desktop apps like the former two candidates. It tries to complement package systems for some special cases (like for example commercial software, or for the cases where the user "just wants to try something out" without "polluting" the whole system with a lot of dependencies). For my desktop needs AppImage is like "Docker, the good parts". A simple self contained format that runs everywhere without any further dependencies. Compared to that Snap and FlatPak are bloated annoyances.
  - lawl 6y ago
    I tend to agree with you, but I really like updating all my software with one click/command. So out of curiosity: My application is already self contained and statically linked, so no AppImage needed, but it behaves like one, you can just run download and run it everywhere. And so what you're describing will be for sure an option for those who like it (in fact currently it's the only option in alpha). How would you like to get updates for something like this? Visit the website yourself occasionally to check for updates? Have the application notify you a new version is available? Have an integrated updater so the binary can update itself?
toyg 6y ago
> the company I work for in my day job now owns Red Hat That's the longest spelling I've ever seen for a three-letter company.
- DoofusOfDeath 6y ago
  I assume then that you don't speak German?
yellowapple 6y ago
I feel like both Snappy and FlatPak are inferior to AppImage, which IMO is much easier to use (it's a self-contained executable) and doesn't rely on any fancy management daemons or what have you. Like, in terms of user experience it's about as close to the Windows-style "download this .exe and run it" approach as one could get, though it'd be interesting to see a macOS-style "put this .app in your ~/Applications" approach as well (which should be doable with a daemon watching such a folder and generating e.g. menu entries and such, as an optional component or perhaps a feature of the desktop environment itself).
ddevault 6y ago
Every attempt at "solving" this "problem", including Snap, Flatpak, and AppImage, are an absolutely awful regression in the state of Linux. I absolutely hate this trend. These tools solve problems for only two kinds of software: proprietary software, and software with suck reckless, runaway complexity that it can only run in one specific environment. I have no interest in either kind and I will give no quarter to "solutions" for their "problems". Criticism specifically regarding Flatpak: https://flatkill.org/ https://flatkill.org/
- abjKT26nO8 6y ago
  I mostly agree with you and I'm not going to get even near Snaps and Flatpaks. However, ignoring the aspect of software distribution, wouldn't you agree that the approach taken by the Linux desktop today is deficient security-wise? For example, I would like to be able to give mbsync (or Thunderbird or whatever) my IMAP password without giving it to any other program. So I don't want to store it in mbsync's config file in plain text. Neither will I use gnome-keyring (or any other keyring) because it doesn't have any kind of "program authorisation". Any program can just spawn a new "secret-tool" process and get my credentials from gnome-keyring. I've been thinking for a while about implementing a keyring which runs as a daemon with SUID of a dedicated user and checks which program sends requests to it, using /proc/pid/exe, but I'm not sure if it's a secure source of truth: how e.g. namespaces affect what's visible in /proc/pid/exe. I know you've been developing himitsu[1]. Have you thought about this problem in that context? [1]: https://git.sr.ht/~sircmpwn/himitsu https://git.sr.ht/~sircmpwn/himitsu
  - ddevault 6y ago
    I agree with you, but the solution would have been Plan 9 namespaces, not Linux containers. What we're working towards today is awful.
- ttgo 6y ago
  flatkill.org is clickbait, not written in good faith, and doesn't propose any solution. Moreover things like "it's obvious Red Hat developers working on flatpak do not care about security" is just unnecessary and toxic. Issues mentioned on flatkill are already fixed, will be fixed or doesn't depend on flatpak itself (like the UI / icon in the software app store). I don't like Flatpak either but I think we should elevate the debate to deeper architectural issues of flatpak that won't be fixed easily. Personally, I do not like the following in Flatpak : - no effort on full reproducibility like Nix&Guix - a big fat flat runtime rather than traditional fine grained dependencies (although OStree avoids duplication, but still very elegant) - you can't install extra pkg in the sandbox. So the quite overkill solution in RedHat's vision is to separate between Toolbox/Podman for devs vs Flatpak for users, rather than trying to make a single unified sandbox for everything. Of course everything breaks down when you try to code using a Flatpaked IDE, if you follow RedHat's vision you basically need to spawn a toolbox container from an unsandboxed flatpak instance of your IDE : https://github.com/flathub/com.visualstudio.code/issues/44 https://github.com/flathub/com.visualstudio.code/issues/44 So personally, I'm still waiting for a packaging system that is : - compatible with the idea of a declarative/immutable os (like nix, guix, silverblue) - tries to make everything reproducible (like guix) - sandboxed with runtime permission API (like Flatpak portals, IOS, Android) - sandbox can be augmented with packages so that you can code in your sandboxed IDE + add necessary dev packages inside a same sandbox without having to break it

lawl 6y ago

> but from the User perspective it seems like FlatPaks[1] are much better and address the issues that this article raises This is interesting, because the last few days I was actually working on packaging an application of mine as a snap/flatpak. From my PoV, they both have their fair share of issues. Snaps enforce a sandbox, which I think is actually a good idea, because the desktop security model is somewhat broken. If your application cannot run as a sandboxed app, you need to be granted special permissions by canonical after manual review (my app needs this), where they also discuss if they can make a new permission in a safe way for your usecase that everyone can use afterwards. On one hand this sucks because I need to ask canonical for permission to publish something, and there's no certainty that I will get these permissions as a nobody for a new app nobody ever heard of before. On the other hand, I think I like that they're doing something about the desktop security model. The next problem is, if this is denied, how do I ship updates? Provide a self updater? Easy to write, but if everyone does that, we can just go full windows and abandon package managers. Tell people to just curl | bash? That's not more secure than a potentially shady snap. But I do have to praise canonical for being very helpful in IRC and the forums for helping me debug issues and file bugs against snap stuff. Now flatpak on the other hand, just feels kinda weird to me. It sandboxes things, but every application can pretty much grant itself access to everything. This is a completely different philosophy, but if you rely on everyone tightly sandboxing their applications without granting themselves permissions for sandbox escape, I think something like landlock[0] (when it lands) or pledge is much more suited for this, and baked into the application. Then there is this weird thing where flatpaks force a runtime on you. My application is a statically linked go binary. But flatpaks pretty much want to force me to add an entire freedesktop suite as a dependency, as you simply cannot choose no runtime. (Community-)Support for building flatpaks? Pretty much non-existant. So yeah, the entire linux upstream-packaging situation is still quite depressing honestly. And with the time and energy I have invested into this by now, I could have written a simple but sufficient self-updater about 10 times over. [0]: https://landlock.io/ https://landlock.io/

d1plo1d 6y ago
I'm in a similar boat with regards to launching a new, unknown product in the snap store. As an interim solution I'm planning to ask users to do use the beta flag: `snap install my-app --beta` which gets me around the secure sandbox requirements.
- galgalesh 6y ago
  Did you mean devmode instead of beta? Just wanted to easy one worry of you: the age, popularity and maturity of your application has no influence on whether or not these permission requests are granted. The approval process is formally defined and mostly depends on what your application does exactly. You can find the specific processes in the docs at the bottom of this page: https://snapcraft.io/docs/permission-requests https://snapcraft.io/docs/permission-requests
still_grokking 6y ago
As a user I don't like neither Snaps (that for sure as this is Cannonical only) nor FlatPaks (as they seem conceptually a "80% solution" which combines the problems of package systems with the problems of self-contianed apps, but don't improve on anything). For me the only acceptable solution besides proper .debs are AppImages. AppImage doesn't try to "replace" the package management for desktop apps like the former two candidates. It tries to complement package systems for some special cases (like for example commercial software, or for the cases where the user "just wants to try something out" without "polluting" the whole system with a lot of dependencies). For my desktop needs AppImage is like "Docker, the good parts". A simple self contained format that runs everywhere without any further dependencies. Compared to that Snap and FlatPak are bloated annoyances.
- lawl 6y ago
  I tend to agree with you, but I really like updating all my software with one click/command. So out of curiosity: My application is already self contained and statically linked, so no AppImage needed, but it behaves like one, you can just run download and run it everywhere. And so what you're describing will be for sure an option for those who like it (in fact currently it's the only option in alpha). How would you like to get updates for something like this? Visit the website yourself occasionally to check for updates? Have the application notify you a new version is available? Have an integrated updater so the binary can update itself?

toyg 6y ago

> the company I work for in my day job now owns Red Hat That's the longest spelling I've ever seen for a three-letter company.

DoofusOfDeath 6y ago
I assume then that you don't speak German?

yellowapple 6y ago

I feel like both Snappy and FlatPak are inferior to AppImage, which IMO is much easier to use (it's a self-contained executable) and doesn't rely on any fancy management daemons or what have you. Like, in terms of user experience it's about as close to the Windows-style "download this .exe and run it" approach as one could get, though it'd be interesting to see a macOS-style "put this .app in your ~/Applications" approach as well (which should be doable with a daemon watching such a folder and generating e.g. menu entries and such, as an optional component or perhaps a feature of the desktop environment itself).

ddevault 6y ago

Every attempt at "solving" this "problem", including Snap, Flatpak, and AppImage, are an absolutely awful regression in the state of Linux. I absolutely hate this trend. These tools solve problems for only two kinds of software: proprietary software, and software with suck reckless, runaway complexity that it can only run in one specific environment. I have no interest in either kind and I will give no quarter to "solutions" for their "problems". Criticism specifically regarding Flatpak: https://flatkill.org/ https://flatkill.org/

abjKT26nO8 6y ago
I mostly agree with you and I'm not going to get even near Snaps and Flatpaks. However, ignoring the aspect of software distribution, wouldn't you agree that the approach taken by the Linux desktop today is deficient security-wise? For example, I would like to be able to give mbsync (or Thunderbird or whatever) my IMAP password without giving it to any other program. So I don't want to store it in mbsync's config file in plain text. Neither will I use gnome-keyring (or any other keyring) because it doesn't have any kind of "program authorisation". Any program can just spawn a new "secret-tool" process and get my credentials from gnome-keyring. I've been thinking for a while about implementing a keyring which runs as a daemon with SUID of a dedicated user and checks which program sends requests to it, using /proc/pid/exe, but I'm not sure if it's a secure source of truth: how e.g. namespaces affect what's visible in /proc/pid/exe. I know you've been developing himitsu[1]. Have you thought about this problem in that context? [1]: https://git.sr.ht/~sircmpwn/himitsu https://git.sr.ht/~sircmpwn/himitsu
- ddevault 6y ago
  I agree with you, but the solution would have been Plan 9 namespaces, not Linux containers. What we're working towards today is awful.
ttgo 6y ago
flatkill.org is clickbait, not written in good faith, and doesn't propose any solution. Moreover things like "it's obvious Red Hat developers working on flatpak do not care about security" is just unnecessary and toxic. Issues mentioned on flatkill are already fixed, will be fixed or doesn't depend on flatpak itself (like the UI / icon in the software app store). I don't like Flatpak either but I think we should elevate the debate to deeper architectural issues of flatpak that won't be fixed easily. Personally, I do not like the following in Flatpak : - no effort on full reproducibility like Nix&Guix - a big fat flat runtime rather than traditional fine grained dependencies (although OStree avoids duplication, but still very elegant) - you can't install extra pkg in the sandbox. So the quite overkill solution in RedHat's vision is to separate between Toolbox/Podman for devs vs Flatpak for users, rather than trying to make a single unified sandbox for everything. Of course everything breaks down when you try to code using a Flatpaked IDE, if you follow RedHat's vision you basically need to spawn a toolbox container from an unsandboxed flatpak instance of your IDE : https://github.com/flathub/com.visualstudio.code/issues/44 https://github.com/flathub/com.visualstudio.code/issues/44 So personally, I'm still waiting for a packaging system that is : - compatible with the idea of a declarative/immutable os (like nix, guix, silverblue) - tries to make everything reproducible (like guix) - sandboxed with runtime permission API (like Flatpak portals, IOS, Android) - sandbox can be augmented with packages so that you can code in your sandboxed IDE + add necessary dev packages inside a same sandbox without having to break it