6 ms·

Obviously both FlatPack and Snap have failed. Everybody hares them for many serious reasons. Yet there are awesome ideas behind. The Mac way of installing apps

Obviously both FlatPack and Snap have failed. Everybody hares them for many serious reasons. Yet there are awesome ideas behind. The Mac way of installing apps (by just putting the packages into a dedicated directory) is cool and intuitive, removing a lot of entities a user has to understand. Sand-boxing and being able to fine-tune the interactions with the host system and the Internet an app is allowed to perform is a feature absurd to be lacking. Do we need to invent a new format, taking FlatPack and Snap mistakes in account to just get all of that, implemented a working and easily usable way?

gibspaulding 6y ago
Situation: There are 14 competing standards...
- qwerty456127 6y ago
  Obviously. Buе this principle should not be followed fanatically. In the real world there are cases when a new standard can be introduced for good and take over. You just have to thing twice before inventing a wheel - to make sure it's going to be sooooo much better that it's worth it. In this actual situation we have ther isn't going to be "14 standards" because there is no standard (for packages of this kind) so far, only a number of candidates. The first one to be good enough will become the first standard.
3np 6y ago
I'm thinking that good standard practices and abstractions for SELinux and, optionally, per-application users would go a long way to solve these problems.
Santosh83 6y ago
No amount of inventing new formats and technologies will solve any major problem under Linux because the ecosystem is not developed by a single vendor. Any solution will not be uniformly adopted and there will be multiple competing solutions, lacking various levels of polish. Also the money under Linux is with servers, so unless that changes, the desktop landscape is never going to approach MacOS or iOS cohesiveness. Too many ideas, too many projects and efforts, too little top-level organisation and too little time or monetary interest for consumer desktop solutions, especially by the largest players who're all focused on the server and cloud and any benefit for the desktop is incidental.
- Erlich_Bachman 6y ago
  That's not very useful way of thinking. .deb packages format for example are quite uniformly established and provide a lot of interfunctionality on many different systems. Of course you are going to find other obscure systems and even big other ecosystems (RedHat obviously, and derivatives), but the format we are looking for doesn't have to be the single one either. It just has to work well enough and be somewhat universal. .Deb-level of universality would suffice just fine.
  - curt15 6y ago
    .deb is a format in the same way that .tar.gz is a format. If Fedora or Arch used .deb the problem would no better because each distro has its own package names, its own package versions, and its own downstream patches.
- curt15 6y ago
  Another way of saying this is that flatpak and snap try to solve what's ultimately a social or policy problem by technical means. Building an abstraction layer like flatpak does necessarily entails a lot of complexity for at best a 90-percent solution; for instance, you still have to worry about what version of flatpak or xdg-desktop-portal each distribution has.
- diffeomorphism 6y ago
  Speaking as a user, not a dev, I don't really understand what you are referring to. There are "multiple" solutions, namely 2 (two). Both of them work on all distros, so I could not care less which one you pick. Same for desktops, again there are two: gtk-whatever and qt-whatever. All software works on both of them, so again I don't care. Same for installing software. Installing Wolfram Mathematica is literally downloading one file, clicking on it and pressing Enter a few times. If anything iOS and its appstore showed that the repo model is great and there is a reason why microsoft developed/copied "winget".
  - salawat 6y ago
    As a user, you're missing details, and completely misunderstand several abstractions. For instance, gtk and qt are not desktops. They're ui toolkits. Bunches of widgets that can be composed to cobble together a UI. That's completely separate from the topic under discussion, which is mode of application delivery. FlatPak involves using namespacing and containers to "spin up" a virtual system with only visibility into those slices of the overall host needed to run the program. This is good because it at least keeps unfamiliar software constrained somewhere predictable, but poor because often it won't use OS host libraries, which are generally kept the most up to date, and worst of all, enforces a complexity and debuggability tax where one has to have an intimate understanding of what is going on "in the box" if something goes wrong. Other ways mentioned are the distro model, whereby distributions maintain repository ecosystems and make decisions with regard to FHS compliance, system tooling, update pipeline, etc..., and use those to support their user base. There is the original "compile and stage it yourself" crowd, who basically concentrate on reproducible build capabilities, but tend to lack in automatic dependency resolution. There's the Mac way, which isn't terrible. It tracks and designates places for libraries, Frameworks, and Applications, and has a lot of automated and well integrated ui-tooling which makes the user experience of software install easy, but it's just another paradigm you have to track when trying to write portable software. There's static linking, which delivers executables that are entirely self-contained, but tend to be bigger memory footprint-wise, each have an upgrade path separate from every other executable, and benefit not at all from dynamic linked libraries on the host system. Then finally, there is dynamically linked executables. They're small, commonly reused code is loaded once in memory you have the additional complexity of the linker to be aware of, but you can update the entire system's audience of a particular library at the same time... Which can be a double-edged sword given how the maintainer scripts the install or sets up their system/build environment. Personally, I just sidestep the issue myself by digging into and learning about software I use on a regular basis with disassembly tools, and treat all of my systems the way a good farmer treats their livestock. Distant reverence, but with a careful eye as to whether there is something wrong, and a hard fought for willingness to kill something and start from scratch. It's the only way I've found to be truly safe and resilient in an environment where everyone optimizes for their own particular definition of convenience. (My definition of convenience is a minimum difficulty in troubleshooting what might be wrong, so I favor fewer abstractions as that entails less Tower of Babel to wade through). Full disclosure: my approach generally would classify me as a bit of a curmudgeon in the industry as I still approach computers as being analogs of physical machines. There is a healthy corpus that revels in abstraction, but I'm not really one of them. I like to have a ballpark understanding of what the artfully arranged beach sand is doing. Adding more abstractions or having the computer do things itself is generally not something I strive toward as it almost always comes with an unacceptable increase in the overall complexity inherent to navigating the Gulf between how I and everyone else thinks the system works and how it actually does. More than anything else, in my experience, keeping that Gulf small leads to better overall satisfaction from a lay User. YMMV.
cheph 6y ago
How has FlatPak failed? > Sand-boxing and being able to fine-tune the interactions with the host system and the Internet an app is allowed to perform is a feature absurd to be lacking. Are these features lacking? I mean I can open flatseal and go disable Geeqie access to network and filesystem, so not sure how it is lacking - maybe I'm missing something. Of course if I disable Geeqie access to the host FS it kind of defeats the purpose of the app, but at least I guess you can technically say it failed in that for Geeqie to operate as I expect it to, it needs access to the host fs. EDIT: Seriously though, I am not sure how most of Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity or VLC will be useful to me or anybody else without host fs access. Where the heck do you keep your stuff if not on your fs? If you want to go fiddle with the specific directories that option is available to you in flatseal. And I just had a look at some other apps like Bitwarden, Teams and Spotify, and there the permissions is much more constrained, for example none of those have blanket access to the host fs or home directory. Spotify for example is limited to xdg-music and xdg-pictures. Another EDIT: flatpak also does support blacklisting of directories, see nofilesystem in https://docs.flatpak.org/en/latest/flatpak-command-reference.html https://docs.flatpak.org/en/latest/flatpak-command-reference... I think support for this is lacking in flatseal currently but I'm sure it is coming.
- qwerty456127 6y ago
  > Are these features lacking? I mean they are lacking if we don't use Flatpack or an alternative so we have to either use it or invent something better. > Seriously though, I am not sure how most of Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity or VLC will be useful to me or anybody else without host fs access. I don't need any of these to access anything outside a specific directory (or a small selection of such, but I don't need them to access the full home dir, let alone the full root fs, even for reading). Hopefully flatseal can do this.
  - cheph 6y ago
    > Are these features lacking? Well, as I said I see them in flatseal so either flatseal is misleading or the features are there, and I have no reason to think flatseal is trying to deceive me so I assume they are there. > I don't need any of these to access anything outside a specific directory (or a small selection of such, but I don't need them to access the full home dir, let alone the full root fs, even for reading). Fire up flatseal and change the permissions to what you want it. I'm sure you can also petition for xdg-code directory or something and then keep all your code there and request the packages be changed to default only work under there but I suspect most people would not be so happy with this. I am not sure how you expect the package maintainers to know where exactly on your FS you keep your code, I also don't keep mine in my home directory. And maybe a blacklist would make sense, but if all that is needed is a blacklist then I would harldy say that flatpak failed because it is not really that difficult to fix that deficiency. EDIT: Actually blacklisting is supported, see --nofilesystem in https://docs.flatpak.org/en/latest/flatpak-command-reference.html https://docs.flatpak.org/en/latest/flatpak-command-reference... So really everything is there, maybe everything is not available in a nice neat UI, maybe the UX is not what it should be, but the core underlying system is not "lacking" these capabilities AFAICT.
xorcist 6y ago
Is that the Mac way? This is how you run a third party Firefox binary package downloaded from Mozilla: tar xJf firefox-x.tar.bz2 ; cd firefox ; ./firefox Most third-party commercial applications (CAD software etc.) is similar. Obviously there is room for improvement here, for some basic sandboxing (chroot, dedicated uid and so on) and desktop integration (give the user an icon to click on, links to other applications). It's just that Snap (and probably Flatpak too) just isn't it. Much too heavyweight and gave the users other things to worry about (disk space, updates, new types of package repositories). Something more fit for Linux culture would probably be closer to a set of best practices (this is what the executable is called, this is where libraries are put, there should be an icon here in this format), and let a thin wrapper handle it all.
- kzrdude 6y ago
  That simple way is ok but it misses all the small details of the Mac os install - a canonical place to copy the installed program, a nice icon to launch it with, file associations and so on
- qwerty456127 6y ago
  No. The Mac way is download the app file disk image, click to mount it, drag the app file from there to the Applications directory, click to unmount the image the way you unmount USB flash drives. Perhaps I would also suggest removing the disk image part to further simplify the procedure. A user should not be forced to enter any terminal commands or even understand what an archive (or an executable installer) is. We must take "stupid" users in account if we want to conquer the desktop market as they are the majority we have to conquer.
  - viraptor 6y ago
    Parent showed the general process. The implementation can change. If you're in any recent Linux desktop, you can click on the archive and it will open in file explorer so you can copy the app anywhere. No commandline required.
  - toxican 6y ago
swiley 6y ago
Why do applications have to be installed from strangers? If you're unfamiliar with computers then you should only use things sandboxed as heavily as web pages or native apps that have been carefully reviewed by operating system maintainers. If you know enough to make a useful decision on the safety of an app than you can probably build it yourself from github. This practice of flinging binaries around is only useful for "software markets" and almost always seems to end up distributing the most pathological garbage possible.
- AnIdiotOnTheNet 6y ago
  Holy shit I hate this opinion. The best thing about personal computing is being able to build software and just pass it around easily. Having to rely on a third party to be able to install software is awful.
  - swiley 6y ago
    I'm absolutely not suggesting you rely on a third party. It's very easy and preferable to pass around source code, and it's (by design) very easy to build GNU/Linux apps from the source. Distributing binaries will absolutely bring about calls to lock computing down to 3rd party distributors because the kind of people that can't handle typing `./configure` are the same kind that will pull random maleware off of google. No good can come from installing closed software anyway.
    - AnIdiotOnTheNet 6y ago
      > I'm absolutely not suggesting you rely on a third party. It's very easy and preferable to pass around source code, and it's (by design) very easy to build GNU/Linux apps from the source. Yeah, it is so easy that no one ever uses containers to ensure a consistent and working build environment for software! Oh wait, yes they do.
      - swiley 6y ago
        If your application is that complex then yes you probably should be working with it in a container. There are decades of very good desktop applications that are simple and easy to build. Flatpack will just encourage things like slack.
AnIdiotOnTheNet 6y ago
> The Mac way of installing apps (by just putting the packages into a dedicated directory) is cool and intuitive 1) They don't need to be put in a special directory to work. 2) AppImage is the most prevalent implementation of this concept in Linux (and it is indeed great).
- qwerty456127 6y ago
  > They don't need to be put in a special directory to work. I know but AFIK that's the way that's meant to be done. > AppImage is the most prevalent implementation of this concept in Linux (and it is indeed great). Why don't we give FlatPack and Snap up to just use AppImage then? Chances are AppImage also has some cons and is inferior to Flat pack in at least some ways.
  - srtjstjsj 6y ago
    Anarchy. Steve Jobs / Tike Cook can declare one package format for Mac. No one can do that for Linux. With a single distro leadership can sometimes do it, but there isn't enough funding to solve problems within a single distro.
  - AnIdiotOnTheNet 6y ago
    In theory Flatpak allows for sharing of dependencies and has sandboxing built in. This comes at the cost of needing special tooling, a repo, and non-portable (portable here meaning you can put the files wherever you want) applications. In practice you're probably better off using Firejail or the like on AppImage if you want the sandboxing anyway, because of things like the issues noted in the article. Snap is like Flatpak but even worse because it is entirely controlled by canonical.
    - deleted 6y ago
      [deleted]
stuaxo 6y ago
Disagree. flatpaks provide apps that weren't packaged before. They provide easy an easy way to install apps that are bleeding edge and may have used newer versions of system libraries.
pjfin123 6y ago
How has Snap failed? Snap lets you install apps like Spotify easily on linux and in a security sandbox. Also snap doesn't have the main issue listed in this article of every app needing filesystem access. Snap has the personal-file interface which you need explicit permission to upload a snap to the Snap Store that accesses this interface: https://snapcraft.io/docs/personal-files-interface https://snapcraft.io/docs/personal-files-interface . Source: working on a open source snap applications (without the personal-file interface despite being able to install packages into the sandboxed $SNAP_USER_DATA directory): https://github.com/argosopentech/argos-translate https://github.com/argosopentech/argos-translate
- vbernat 6y ago
  Flatpak has portals for the same purpose. Unfortunately, many apps don't support portals yet. The Flatpak for Spotify does not allow access to home, only to the music directory (read-only). So, it's running in a proper sandbox too.
  - MrDresden 6y ago
    I don't use Spotify, but have you tried using Flatseal[0], to modify the folder access of the application? [0]: https://flathub.org/apps/details/com.github.tchx84.Flatseal https://flathub.org/apps/details/com.github.tchx84.Flatseal
Ericson2314 6y ago
The awesome idea behind is Nix. Please, everyone just go use Nix.
- aszlig 6y ago
  That's easier said than done, since I think Nix has a somewhat steep learning curve. However, what I'm missing in most comments here is that - if I'm not mistaken - Flatpak and most others are essentially tailored towards distributing binaries, which is at least my personal gripe with them. The reason is that especially with Nix I'm used to ad-hoc `.override`/`.overrideAttrs` and patch software in ways I'd like them to behave rather than being degraded to being the sole user of a software not supposed to be modified. Flatpak, Snap and even Docker go the opposite route, which essentially degrades FOSS to essentially proprietary software, if even upstream would just point you towards "just use the Flatpak"™. Others here also have suggested that it would be a good way to only distribute proprietary software, but as a Nix user who's packaging and patching (well, and reverse engineering) proprietary software I'd even disagree on that, because patching the environment and the entire dependency graph is something very useful which you'll lose with Flatpak/Snap.

gibspaulding 6y ago

Situation: There are 14 competing standards...

qwerty456127 6y ago
Obviously. Buе this principle should not be followed fanatically. In the real world there are cases when a new standard can be introduced for good and take over. You just have to thing twice before inventing a wheel - to make sure it's going to be sooooo much better that it's worth it. In this actual situation we have ther isn't going to be "14 standards" because there is no standard (for packages of this kind) so far, only a number of candidates. The first one to be good enough will become the first standard.

3np 6y ago

I'm thinking that good standard practices and abstractions for SELinux and, optionally, per-application users would go a long way to solve these problems.

Santosh83 6y ago

No amount of inventing new formats and technologies will solve any major problem under Linux because the ecosystem is not developed by a single vendor. Any solution will not be uniformly adopted and there will be multiple competing solutions, lacking various levels of polish. Also the money under Linux is with servers, so unless that changes, the desktop landscape is never going to approach MacOS or iOS cohesiveness. Too many ideas, too many projects and efforts, too little top-level organisation and too little time or monetary interest for consumer desktop solutions, especially by the largest players who're all focused on the server and cloud and any benefit for the desktop is incidental.

Erlich_Bachman 6y ago
That's not very useful way of thinking. .deb packages format for example are quite uniformly established and provide a lot of interfunctionality on many different systems. Of course you are going to find other obscure systems and even big other ecosystems (RedHat obviously, and derivatives), but the format we are looking for doesn't have to be the single one either. It just has to work well enough and be somewhat universal. .Deb-level of universality would suffice just fine.
- curt15 6y ago
  .deb is a format in the same way that .tar.gz is a format. If Fedora or Arch used .deb the problem would no better because each distro has its own package names, its own package versions, and its own downstream patches.
curt15 6y ago
Another way of saying this is that flatpak and snap try to solve what's ultimately a social or policy problem by technical means. Building an abstraction layer like flatpak does necessarily entails a lot of complexity for at best a 90-percent solution; for instance, you still have to worry about what version of flatpak or xdg-desktop-portal each distribution has.
diffeomorphism 6y ago
Speaking as a user, not a dev, I don't really understand what you are referring to. There are "multiple" solutions, namely 2 (two). Both of them work on all distros, so I could not care less which one you pick. Same for desktops, again there are two: gtk-whatever and qt-whatever. All software works on both of them, so again I don't care. Same for installing software. Installing Wolfram Mathematica is literally downloading one file, clicking on it and pressing Enter a few times. If anything iOS and its appstore showed that the repo model is great and there is a reason why microsoft developed/copied "winget".
- salawat 6y ago
  As a user, you're missing details, and completely misunderstand several abstractions. For instance, gtk and qt are not desktops. They're ui toolkits. Bunches of widgets that can be composed to cobble together a UI. That's completely separate from the topic under discussion, which is mode of application delivery. FlatPak involves using namespacing and containers to "spin up" a virtual system with only visibility into those slices of the overall host needed to run the program. This is good because it at least keeps unfamiliar software constrained somewhere predictable, but poor because often it won't use OS host libraries, which are generally kept the most up to date, and worst of all, enforces a complexity and debuggability tax where one has to have an intimate understanding of what is going on "in the box" if something goes wrong. Other ways mentioned are the distro model, whereby distributions maintain repository ecosystems and make decisions with regard to FHS compliance, system tooling, update pipeline, etc..., and use those to support their user base. There is the original "compile and stage it yourself" crowd, who basically concentrate on reproducible build capabilities, but tend to lack in automatic dependency resolution. There's the Mac way, which isn't terrible. It tracks and designates places for libraries, Frameworks, and Applications, and has a lot of automated and well integrated ui-tooling which makes the user experience of software install easy, but it's just another paradigm you have to track when trying to write portable software. There's static linking, which delivers executables that are entirely self-contained, but tend to be bigger memory footprint-wise, each have an upgrade path separate from every other executable, and benefit not at all from dynamic linked libraries on the host system. Then finally, there is dynamically linked executables. They're small, commonly reused code is loaded once in memory you have the additional complexity of the linker to be aware of, but you can update the entire system's audience of a particular library at the same time... Which can be a double-edged sword given how the maintainer scripts the install or sets up their system/build environment. Personally, I just sidestep the issue myself by digging into and learning about software I use on a regular basis with disassembly tools, and treat all of my systems the way a good farmer treats their livestock. Distant reverence, but with a careful eye as to whether there is something wrong, and a hard fought for willingness to kill something and start from scratch. It's the only way I've found to be truly safe and resilient in an environment where everyone optimizes for their own particular definition of convenience. (My definition of convenience is a minimum difficulty in troubleshooting what might be wrong, so I favor fewer abstractions as that entails less Tower of Babel to wade through). Full disclosure: my approach generally would classify me as a bit of a curmudgeon in the industry as I still approach computers as being analogs of physical machines. There is a healthy corpus that revels in abstraction, but I'm not really one of them. I like to have a ballpark understanding of what the artfully arranged beach sand is doing. Adding more abstractions or having the computer do things itself is generally not something I strive toward as it almost always comes with an unacceptable increase in the overall complexity inherent to navigating the Gulf between how I and everyone else thinks the system works and how it actually does. More than anything else, in my experience, keeping that Gulf small leads to better overall satisfaction from a lay User. YMMV.

cheph 6y ago

How has FlatPak failed? > Sand-boxing and being able to fine-tune the interactions with the host system and the Internet an app is allowed to perform is a feature absurd to be lacking. Are these features lacking? I mean I can open flatseal and go disable Geeqie access to network and filesystem, so not sure how it is lacking - maybe I'm missing something. Of course if I disable Geeqie access to the host FS it kind of defeats the purpose of the app, but at least I guess you can technically say it failed in that for Geeqie to operate as I expect it to, it needs access to the host fs. EDIT: Seriously though, I am not sure how most of Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity or VLC will be useful to me or anybody else without host fs access. Where the heck do you keep your stuff if not on your fs? If you want to go fiddle with the specific directories that option is available to you in flatseal. And I just had a look at some other apps like Bitwarden, Teams and Spotify, and there the permissions is much more constrained, for example none of those have blanket access to the host fs or home directory. Spotify for example is limited to xdg-music and xdg-pictures. Another EDIT: flatpak also does support blacklisting of directories, see nofilesystem in https://docs.flatpak.org/en/latest/flatpak-command-reference.html https://docs.flatpak.org/en/latest/flatpak-command-reference... I think support for this is lacking in flatseal currently but I'm sure it is coming.

qwerty456127 6y ago
> Are these features lacking? I mean they are lacking if we don't use Flatpack or an alternative so we have to either use it or invent something better. > Seriously though, I am not sure how most of Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity or VLC will be useful to me or anybody else without host fs access. I don't need any of these to access anything outside a specific directory (or a small selection of such, but I don't need them to access the full home dir, let alone the full root fs, even for reading). Hopefully flatseal can do this.
- cheph 6y ago
  > Are these features lacking? Well, as I said I see them in flatseal so either flatseal is misleading or the features are there, and I have no reason to think flatseal is trying to deceive me so I assume they are there. > I don't need any of these to access anything outside a specific directory (or a small selection of such, but I don't need them to access the full home dir, let alone the full root fs, even for reading). Fire up flatseal and change the permissions to what you want it. I'm sure you can also petition for xdg-code directory or something and then keep all your code there and request the packages be changed to default only work under there but I suspect most people would not be so happy with this. I am not sure how you expect the package maintainers to know where exactly on your FS you keep your code, I also don't keep mine in my home directory. And maybe a blacklist would make sense, but if all that is needed is a blacklist then I would harldy say that flatpak failed because it is not really that difficult to fix that deficiency. EDIT: Actually blacklisting is supported, see --nofilesystem in https://docs.flatpak.org/en/latest/flatpak-command-reference.html https://docs.flatpak.org/en/latest/flatpak-command-reference... So really everything is there, maybe everything is not available in a nice neat UI, maybe the UX is not what it should be, but the core underlying system is not "lacking" these capabilities AFAICT.

xorcist 6y ago

Is that the Mac way? This is how you run a third party Firefox binary package downloaded from Mozilla: tar xJf firefox-x.tar.bz2 ; cd firefox ; ./firefox Most third-party commercial applications (CAD software etc.) is similar. Obviously there is room for improvement here, for some basic sandboxing (chroot, dedicated uid and so on) and desktop integration (give the user an icon to click on, links to other applications). It's just that Snap (and probably Flatpak too) just isn't it. Much too heavyweight and gave the users other things to worry about (disk space, updates, new types of package repositories). Something more fit for Linux culture would probably be closer to a set of best practices (this is what the executable is called, this is where libraries are put, there should be an icon here in this format), and let a thin wrapper handle it all.

kzrdude 6y ago
That simple way is ok but it misses all the small details of the Mac os install - a canonical place to copy the installed program, a nice icon to launch it with, file associations and so on
qwerty456127 6y ago
No. The Mac way is download the app file disk image, click to mount it, drag the app file from there to the Applications directory, click to unmount the image the way you unmount USB flash drives. Perhaps I would also suggest removing the disk image part to further simplify the procedure. A user should not be forced to enter any terminal commands or even understand what an archive (or an executable installer) is. We must take "stupid" users in account if we want to conquer the desktop market as they are the majority we have to conquer.
- viraptor 6y ago
  Parent showed the general process. The implementation can change. If you're in any recent Linux desktop, you can click on the archive and it will open in file explorer so you can copy the app anywhere. No commandline required.
- toxican 6y ago

swiley 6y ago

Why do applications have to be installed from strangers? If you're unfamiliar with computers then you should only use things sandboxed as heavily as web pages or native apps that have been carefully reviewed by operating system maintainers. If you know enough to make a useful decision on the safety of an app than you can probably build it yourself from github. This practice of flinging binaries around is only useful for "software markets" and almost always seems to end up distributing the most pathological garbage possible.

AnIdiotOnTheNet 6y ago
Holy shit I hate this opinion. The best thing about personal computing is being able to build software and just pass it around easily. Having to rely on a third party to be able to install software is awful.
- swiley 6y ago
  I'm absolutely not suggesting you rely on a third party. It's very easy and preferable to pass around source code, and it's (by design) very easy to build GNU/Linux apps from the source. Distributing binaries will absolutely bring about calls to lock computing down to 3rd party distributors because the kind of people that can't handle typing `./configure` are the same kind that will pull random maleware off of google. No good can come from installing closed software anyway.
  - AnIdiotOnTheNet 6y ago
    > I'm absolutely not suggesting you rely on a third party. It's very easy and preferable to pass around source code, and it's (by design) very easy to build GNU/Linux apps from the source. Yeah, it is so easy that no one ever uses containers to ensure a consistent and working build environment for software! Oh wait, yes they do.
    - swiley 6y ago
      If your application is that complex then yes you probably should be working with it in a container. There are decades of very good desktop applications that are simple and easy to build. Flatpack will just encourage things like slack.

AnIdiotOnTheNet 6y ago

> The Mac way of installing apps (by just putting the packages into a dedicated directory) is cool and intuitive 1) They don't need to be put in a special directory to work. 2) AppImage is the most prevalent implementation of this concept in Linux (and it is indeed great).

qwerty456127 6y ago
> They don't need to be put in a special directory to work. I know but AFIK that's the way that's meant to be done. > AppImage is the most prevalent implementation of this concept in Linux (and it is indeed great). Why don't we give FlatPack and Snap up to just use AppImage then? Chances are AppImage also has some cons and is inferior to Flat pack in at least some ways.
- srtjstjsj 6y ago
  Anarchy. Steve Jobs / Tike Cook can declare one package format for Mac. No one can do that for Linux. With a single distro leadership can sometimes do it, but there isn't enough funding to solve problems within a single distro.
- AnIdiotOnTheNet 6y ago
  In theory Flatpak allows for sharing of dependencies and has sandboxing built in. This comes at the cost of needing special tooling, a repo, and non-portable (portable here meaning you can put the files wherever you want) applications. In practice you're probably better off using Firejail or the like on AppImage if you want the sandboxing anyway, because of things like the issues noted in the article. Snap is like Flatpak but even worse because it is entirely controlled by canonical.
  - deleted 6y ago
    [deleted]

stuaxo 6y ago

Disagree. flatpaks provide apps that weren't packaged before. They provide easy an easy way to install apps that are bleeding edge and may have used newer versions of system libraries.

pjfin123 6y ago

How has Snap failed? Snap lets you install apps like Spotify easily on linux and in a security sandbox. Also snap doesn't have the main issue listed in this article of every app needing filesystem access. Snap has the personal-file interface which you need explicit permission to upload a snap to the Snap Store that accesses this interface: https://snapcraft.io/docs/personal-files-interface https://snapcraft.io/docs/personal-files-interface . Source: working on a open source snap applications (without the personal-file interface despite being able to install packages into the sandboxed $SNAP_USER_DATA directory): https://github.com/argosopentech/argos-translate https://github.com/argosopentech/argos-translate

vbernat 6y ago
Flatpak has portals for the same purpose. Unfortunately, many apps don't support portals yet. The Flatpak for Spotify does not allow access to home, only to the music directory (read-only). So, it's running in a proper sandbox too.
- MrDresden 6y ago
  I don't use Spotify, but have you tried using Flatseal[0], to modify the folder access of the application? [0]: https://flathub.org/apps/details/com.github.tchx84.Flatseal https://flathub.org/apps/details/com.github.tchx84.Flatseal

Ericson2314 6y ago

The awesome idea behind is Nix. Please, everyone just go use Nix.

aszlig 6y ago
That's easier said than done, since I think Nix has a somewhat steep learning curve. However, what I'm missing in most comments here is that - if I'm not mistaken - Flatpak and most others are essentially tailored towards distributing binaries, which is at least my personal gripe with them. The reason is that especially with Nix I'm used to ad-hoc `.override`/`.overrideAttrs` and patch software in ways I'd like them to behave rather than being degraded to being the sole user of a software not supposed to be modified. Flatpak, Snap and even Docker go the opposite route, which essentially degrades FOSS to essentially proprietary software, if even upstream would just point you towards "just use the Flatpak"™. Others here also have suggested that it would be a good way to only distribute proprietary software, but as a Nix user who's packaging and patching (well, and reverse engineering) proprietary software I'd even disagree on that, because patching the environment and the entire dependency graph is something very useful which you'll lose with Flatpak/Snap.