33 ms·

Flatpak Is Not the Future

• icarusmad 5y ago
  Colour me surprised that Canonical and RedHat funded initiatives cause bad things to happen in the desktop space.
• kiryin 5y ago
  I dunno. I had my doubts for the longest time but recently I've started, little by little, placing my bets on Flatpak. Snap can go to hell, for reasons exhaustively discussed here and elsewhere, but Flatpak is reasonably solid, open and performant technology that fits the problem it's trying to solve. I wouldn't mind if it takes over the distribution of big, GUI desktop apps on linux.
  • 1_player 5y ago
    The fact that Valve ships the Steam Deck with a read only root managed by ostree and user apps installable via Flatpak to me shows the direction of future Linux desktop, and I welcome it wholeheartedly. I am done with distro managed packages for desktop apps, custom patches and the impossibility to ship closed source software on Linux because it's a mess. Flatpak in my book rocks, and it's ahead of macOS DMG files and light years ahead of the Windows .exe downloaded from the Internet strategy.
• la6471 5y ago
  So Linux desktop is dead and MS wins it after all?
  • AnIdiotOnTheNet 5y ago
    "Why do people continue to not use our glorious FOSS Desktop solution that can't even handle simple application management without a hundred different tools?" People who desire to see more widespread Linux Desktop usage will some day have to come to terms with the original conception of the phrase "The customer is always right". If you continue to ignore what people want, don't be surprised when they don't show up.
  • pjmlp 5y ago
    It hardly had a chance thanks fragmentation and hard core beliefs in compiling everything from source, up to around 2005 I was still a believer, nowadays I don't care.
• tonetheman 5y ago
  End users do not care about this. If the download works then they are happy. A non-flatpak example is Electron. No one cares how big it is. It works. I download huge games from Steam all the time and have never looked at the size of a game even a single time... in years. Disk space is still cheap on end users machines. As long as the calculator works I do not care how much disk space it takes up.
  • odc 5y ago
    > No one cares how big it is. A lot of people care, especially Linux users. > Disk space is still cheap on end users machines. Not cheap for everyone.
  • southerntofu 5y ago
    > No one cares how big it is. As someone who's helped many friends/neighbors struggling with limited disk space (whether on desktop or Android), i don't think this is true at all. I mean, end-users are usually not conscious what a reasonable size is for an app and will often uninstall one app to install another one instead of complaining of app bloat. They're still very much suffering the problem and care for it.
• hauntedestimate 5y ago
  Snaps and Flatpaks are bloated, slow, and a downgrade on user experience at all levels. I use linux because it is lean, fast and has great package managment (apt). I'd rather go back to using Windows than use Flatpaks or Snaps.
• Edwar 5y ago
  https://www.garagebandapp.net/This https://www.garagebandapp.net/This is a great post. I like this topic. I found many interesting things from this site. Thanks for posting this again
• kalium-xyz 5y ago
  Flaptak? I'm going to call flatpak from that now. OP might want to edit this.
  • Thin_icE 5y ago
    Thank you for the heads up!
• xvilka 5y ago
  Right! Time to pushback against these developers who uses Flatpaks, Appimages, Snaps, Electron, etc. We are no longer in the world of doubling performance and memory size. Even more, nowadays people are conscious of the power usage. Time to fight the bloat!
  • 0x0nyandesu 5y ago
    Agreed
  • deleted 5y ago
    [deleted]
  • OneTimePetes 5y ago
    Should have performance indicators with every app - the kids who grew up on the performancelandfill slopes of the Mount Moore would have a hard time explaining away there whatsapp clone needing the same % as a major application. Yeeh, who enter the plateau, abandon all hope you will get away with leaky abstractions. Wish the lazy bloat-load was build as architectural pattern into apps. It only installs when you actually use it.
  • exikyut 5y ago
    Doubling performance, no. But doubling memory size... kinda. 8-16GB is kind of the baseline now. Laptops with 64GB are increasingly common in certain niches. This being said, I do see these systems that basically just double down on adding layers for layers' sake as more disruptive than systemd.
  • cardanome 5y ago
    Higher memory consumption as a trade off for developer convenience might be questionable in many cases but here it is to increase USER convenience. What are developers supposed to ship their apps with? Make packages for every Linux distribution under the sun? Flaktpaks and Appimages solve a real problem. The current alternative is NOT being able to use the specific software at all because you don't have the right version of Ubuntu. Maybe Guix/Nix are solutions for some of the pain points of traditional package management. And yes, libraries really need to focus on backwards compatibility. In the meantime, AppImage/Flatpack gets the job done. I am not out of luck when my distro does not offer the right package with the right version.
• ddtaylor 5y ago
  > Flatpak and Snap apologists claim that some security is better than nothing. This is not true. Oh no we're all doomed.
• cunidev 5y ago
  To be fair, as a daily user and (to some extent) app developer, in my experience Flatpaks have solved the problem of library fragmentation and app distribution on Linux. While my experience on Snaps was mostly negative (due to bugs, virtual "loop disks" per every app affecting the system performance, etc.), I found that Flatpak finally lets me install essentially any app on any distro. For example, the Elementary OS "AppCenter" apps are now available in any other distribution, thanks to the Flatpak remote. Testing daily GNOME apps has become as easy as installing their Flatpak reference, and letting them update automatically. Regarding memory, storage and power consumption: - The base runtimes (which are the heaviest bit) are downloaded only once per system, e.g., one for the KDE Plasma ecosystem, one for Elementary, and so on. The first app you install will pull them, so I do not see it as much more bloaty than having an enormous bundle of system-wide dependencies (e.g. if you install a KDE app in a primarily GNOME environment) as would happen otherwise. - Memory and CPU-wise, Flatpaks are very light containers (which do not require loop disks, or anything else) which should have almost no overhead. I never witnessed any loss of performance, at least. - Bug and crash-wise, I experienced a tremendously stable and "flat" experience on Flatpaks. That is, if there is a bug in one app on one distribution, the bug will exist on all, or vice versa. This is not as common as it should be in containerized app install tools, and makes debugging overall much easier. The only drawback are updates taking longer than on other platforms, probably because compressed deltas are not yet available unlike in other major package managers. With this, I don't want to describe Flatpak as a panacea in everything, but at least for GUI apps, it solved a lot of distribution fragmentation issues in my case.
  • user0123895264 5y ago
    I might be imagining it, and there might be another cause, but I stopped using Elementary after the latest release after many things moved to Flatpaks because I kept running out of memory. (On Endeavour/Arch, installing everything natively, I no longer have the problem.)
    • kirbyfan64sos 5y ago
      If I had to guess, the update might have just introduced a memory leak somewhere else in the system?
• ddtaylor 5y ago
  The article bashes Flatpak portals as complex but otherwise doesn't make any solid arguments against them. That's important because it's easily the most important remaining problem to solve to get an effective sandbox. I actually like that for apps that have no business reading any files on my system they simply cannot do so. Sure, you can point to apps like GIMP and such that have chosen to give access to the file system by default to make it easier for users while portals get polished. If that bothers you then simply use Flatseal to change those permissions. Meanwhile apps like Spotify are entirely restricted from accessing any of my filesystem. Likewise Discord can only access files from a specific directory or a youtube-dl style tool like VideoDownloader also cannot access any of my files and always includes the latest version of ffmpeg and youtube-dl regardless of distro politics.
  • yyyk 5y ago
    The article's main opposition is to containerization and not portals - the author would like having an API for portals (a stable libportal?), but likes that approach overall. The problem is that we still need a solution to stop hacked apps from calling fopen() on unrelated files. The article ignores how bad the native runtime security solutions are - SELinux is nigh unusable, no distro has many apparmor profiles, etc. Flatpak and snap use containerization because Linux's security modules aren't common across distros and aren't very usable.
    • Iolaum 5y ago
      It took android years and billions of dollars to get to the state it is at. Flatpaks and portals are moving towards that direction (according to my non expert opinion). All this friction and complaints, is just normal for such a big transition in how desktop apps should be written. I remember android devs going up in arms when there were significant API changes in past android versions. The situation for linux looks similar to me (aside from the fact the ecosystem doesn't have money to throw at the problem).
      • zdragnar 5y ago
        The annoying thing with android is that- even in the J2ME days, blackberry had a more sophisticated, fine grained per-app permission system that was easy to find and adjust at any time. Android and iOS have been playing catchup ever since... Linux I at least will cut some slack, given its age and origins, though it would really have been nice had they addressed security by now. The situation can only get worse, but sooner or later something will happen that will encourage breaking backwards compatibility, I hope. All that said, I praise the sun every day that I'm not writing BB apps or j2me anymore, so there's that at least.
• mike_hock 5y ago
  To be fair most of that is a result of an ecosystem of idiots and not of the fundamental design itself. It has a namespacing feature, so f-ck'n use it. Instead, they intentionally produce collisions. Providing and sharing common runtimes could have worked pretty well if developers actually used a small set of common runtimes instead of picking from one of a gazillion slightly different rebuilds. As a replacement for "native" package management? No. Flatpak makes sense if you have a small number (< 5) packages that you want to run from upstream so you can always have the latest version while continuing to use your distro's native packages for everything else. Unfortunately (and ironically) it's ill-suited for games, which need to have the latest GPU drivers available, which is antithetical to the whole idea of a stable, universal base system.
  • pjmlp 5y ago
    Game consoles are a stable universal base system, hence why game studios prefer them to regular home computers.
  • kirbyfan64sos 5y ago
    > if developers actually used a small set of common runtimes instead of picking from one of a gazillion slightly different rebuilds All the runtimes on Flathub are built on top of the standard fd.o runtime, so the OSTree-level dedup should generally work for them. > Unfortunately (and ironically) it's ill-suited for games, which need to have the latest GPU drivers available, which is antithetical to the whole idea of a stable, universal base system. I believe there's an extension available for the latest Mesa builds, so you can opt for the bleeding edge and then just remove the extension if things break.
  • dylan-m 5y ago
    > As a replacement for "native" package management? No. Flatpak makes sense if you have a small number (< 5) packages that you want to run from upstream so you can always have the latest version while continuing to use your distro's native packages for everything else. There are several "Linux" operating systems that use an immutable base image: Fedora Silverblue, Endless OS, purportedly Steam OS 3. The idea here is the distro packages are great for composing your base system, but once that is done, the entire `/usr` filesystem is frozen. You can upgrade it or roll it back atomically, and in some cases you can do some magic to apply smaller changes (Silverblue has a nice implementation with `rpm-ostree`), but distro packages are intentionally not a typical end user thing. In this kind of OS, the best way to install apps is using something like Flatpak. And that's very much what Flatpak is designed for. So… $ flatpak list --app | wc -l 94 And it works well :)
• Joker_vD 5y ago
  If you are a Linux distribution maintainer, please understand what all of these solutions are trying to accomplish. All your hard work in building your software repository, maintaining your libraries, testing countless system configurations, designing a consistent user experience… they are trying to throw all of that away. Every single one of these runtime packaging mechanisms is trying to subvert the operating system, replacing as much as they can with their own. Why would you support this? Uh, because User Freedom™? Or are we supposed to consume Linux applications exclusively via the maintainer-supplied packages? Also, is this part: "testing countless system configurations, designing a consistent user experience", ― something that actually happens? Given the example in this very article about Fedora going to auto-convert all its rpm packages to Flatpak it sounds, as the youth says nowadays, "kinda sus".
• PaulHoule 5y ago
  Nice to see some effort to stop the Docker insanity. It’s a great way to download 2GB on a slow interest so you can use a 200kb piece of software.
• Edwar 5y ago
  Thanks for sharing such a helpful instruction, really appreciate for your article. https://www.garagebandapp.net/ https://www.garagebandapp.net/
  • exikyut 5y ago
    Put me in the screenshot sideways! (For clarification, this is bot spam, and in a couple minutes this will be [dead] and unrepliable. So... hi, world, while I can. :P)
• sandGorgon 5y ago
  The short (but polite) rebuttal to this is - OSX. DMG files are similar sized and proven to be very successful. For e.g. - firefox (https://www.mozilla.org/en-US/firefox/all/#product-desktop-release https://www.mozilla.org/en-US/firefox/all/#product-desktop-r...). Win64 installer is 50mb. MacOS installer is 130mb. Linux 64-bit is 70mb. Same is the case with Chrome - https://chromeenterprise.google/intl/en_US/browser/download/#mac-tab https://chromeenterprise.google/intl/en_US/browser/download/... . Windows MSI is 79mb. OSX PKG for the same is 195mb. So by that measure - OSX has already lost right ? The entire package-everything-together has won in probably one of the largest OS ecosystem that exists today. Size does not matter... mom-proof experience does matter. >How much progress could we make if Steam deprecated their runtimes, abandoned containerization for new games, and let all new games just use the native system libraries? How loudly do you think gamers would complain if a distribution upgrade broke their favourite game? This OTOH does not exist. Linux gamers are 1% of either the gaming market or the desktop computing market. All gamers either dual boot windows...or android. Even for those who game on Linux, they do it on an abstraction layer like Wine. Which is what Valve maintains - https://github.com/ValveSoftware/wine https://github.com/ValveSoftware/wine and https://github.com/ValveSoftware/Proton https://github.com/ValveSoftware/Proton Valve only needs to maintain wine & proton for a distribution. The games themselves ? well, they are windows only. Nobody compiles for Linux.
  • hules 5y ago
    Firefox is larger on macOS because it contains 2 archs (x86_64 and arm64), not because it bundles of full runtime -- also the compression algo of dmg files is typically quite bad (zlib or bzip2), which is not helping.
    • argsnd 5y ago
      I didn’t think that binaries would take up so much space, but Firefox 83 (the last x86-only release) is 73MB vs Firefox 84 (the first universal release) which is 126MB. Wow, I guess that makes sense then.
      • Gigachad 5y ago
• edent 5y ago
  I agree with all of this and... I just don't care. I download a Flatpak from the Pop OS store and it works. It installs only in my profile, so another user on the same machine doesn't have access. You can't do that with a .deb! I've never got into dependency hell where I need to apt-get a specific version of a library from a dodgy PPA. If I uninstall it, Flatpak doesn't leave acres of cruft strewn around my disk. I don't see how randomly installing a Flatpak is any worse for security than compiling the source myself. The permission model on Linux is far worse than Android - so I just hope for the best anyway. Snaps never worked right for me - and seemed to frequently break. But all my Flatpaks have run fine and at full speed. Does it take up more disk space? Sure. But that's a trade-off I'm willing to make in order to just download and run with no extra work. Sure, there are some efficiency and security gains to be made. But I'm much happier with a Flatpak world than the alternative.
  • capableweb 5y ago
    > You can't do that with a .deb! Pretty sure you can by doing "dpkg --root=$HOME -i mypackage.deb" or something like that, long time ago I used dpkg, but it should be possible with some flag. Otherwise I agree, Flatpak is a breath of fresh air!
    • johnchristopher 5y ago
      Where does that put the Deb files ? edit: should have written "where does dpkg put the files of the package ?" or "where does that put the Deb's files ?", sorry.
      • capableweb 5y ago
        The .deb file should remain where it was when you downloaded it, dpkg just installs the contents of the .deb file.
        • johnchristopher 5y ago
          Where is the contents of the .deb files put?
• necovek 5y ago
  The most important takeaway from this is, to me, the need to separate sandboxing from dependency management. However, as can be seen with AppImage, which seems to be strictly focused on dependency management, that results in bloat. It would be great if we could have a sandboxing solution that ignores the dependency management altogether. The problem is not with Flatpak or Snaps (or Docker). The problem is that the fragmentation in the actual, live-deployed Linux system runtime is huge. At one point, I know Canonical suggested a common, shared baseline for all LTS editions of all distributions at some point, but there was no interest from Red Hat in particular (the other "largest" player). It's not too surprising, since Red Hat is the biggest contributor to the base GNU/Linux system, so it can decide how it deals with it and push it onto others. Backwards compatibility is hard in software in general, but I think simple extensions of tools like apt and apt archives (like Launchpad PPAs) would have allowed binary distribution of software in an already familiar way where dependency management is not a solved problem per se, but has all the familiar gotchas. As for app stores, that's surely an effort to extract some profits, but it's also what big customers are asking for for their IoT solutions.
  • AnIdiotOnTheNet 5y ago
    > Backwards compatibility is hard in software in general I disagree. Pretty much every desktop OS in the world manages to get quite a lot of backwards compatibility without a whole lot of trouble, except for Linux Desktop. That suggests the problem isn't hard, it's just that the culture of Linux Desktop is incompatible with the concept.
    • southerntofu 5y ago
      > Pretty much every desktop OS in the world manages to get quite a lot of backwards compatibility without a whole lot of trouble, except for Linux Desktop. That's not at all my experience with Windows or MacOS. Sure some older apps work fine, but certainly not all of them.
      • AnIdiotOnTheNet 5y ago
        The vast majority of them do, in my experience. Especially if you take into consideration how badly it doesn't work in Linux Desktop. You cannot usually even run a binary compiled for the previous version of your distro on the latest one!
• esarbe 5y ago
  Don't know what to think about this blog post; it's not a very coherent critique, since it throws together various issues of user-packaging-formats that mostly specific to only one of the formats. And these don't seem to be 'inherent' in their design. Well, one is. Let's go through some of the issues: > Size My /var/lib/flatpak is 13 GB in size. That's a lot of space. On the other hand; that's about one game with content and textures, so I'm not sure that is too much of an issue. With more and more applications agreeing on the base systems, I expect this to get smaller > Memory Usage, Startup times Snap is ungodly slow at starting up applications and that's broken and that is a fundamental design flaw. This issue, however, is not at hand with Flatpak; it doesn't have a startup problem. Neither Flatpak nor Snap have increased memory usage because of containerization. > Drivers Yes, Nvidia sucks. Do you hear, Nvidia? Mainline your driver already. > Security > "Flatpack and Snap apologists claim that some security is better than nothing. This is not true." That's debatable. The same argument was made against seatbelts, child-proof pill bottles or guard-rails on cliff streets and I don't think it holds up. Even if seatbelts don't protect you from any harm, they protect you against some harm. Currently, Linux desktop software offers no security against malicious code. The only protection the 'traditional' Linux desktop offers against malicious code is user separation, which is no protection at all. Before full security can be offered, applications need to be migrated to safer practices. > Permissions and Portals This doesn't seem to be a critique of any user-packaging-format but rather of how GTK implements interactions with Portals. > Identifier Clashes That's a problem that arises from Flatpaks decentralized nature; everyone can create a repo and add packages of any names there. I agree that it would be nice to not have these clashes. Notice that this is not an issue with Snaps, since with Snaps there's a central authority assigning the identifiers. > Complexity Some of the complexity cannot be avoided. Either for backward compatibility or for security. I pretty much doubt that Flatpak this will be reason that civilization collapses. (That would be shortsighted greed and NIMBYism) > All of these app packaging systems require the user have some service installed on their PC before any packages can be installed All app packaging systems require at least some installed component. There's no way you can make a software run on all systems without requiring at least some infrastructure. Do you want your 64-bit AppImage to install everywhere? To bad! it requires 64-bit glib to be installed. > App stores > [...] This is the reason Ubuntu wants everyone to use Snap [...] This seems to limited to Snap. Again, not a fundamental design issue. > Backward compatibility > Forcing Distributions to Maintain Compatibility > I believe this is partly due to a militant position on free software. This sounds like he wants to dictate FOSS developers how to develop their software? See, I understand your frustration - but that's not how FOSS works. You cannot force anyone to spend time on stuff they don't want to do. There's some valid criticism in there, but it just reads like an angry rant. I think the author could do better by making individual articles about the shortcomings of both Snap and Flatpak, instead of just lumping them together. Snap and Flatpak are just too different. In the end, Flatpak is the future. No one is going to package their software for the nth minor distribution and I rather have a slightly (size)-inefficient system of packaging software rather than not have access to that software. Distributions have started to recognize that they cannot package everything and have started to reduce focus to a smaller set of core packages that work well together.
• anothernewdude 5y ago
  Snap certainly isn't. But flatpak might be
• riidom 5y ago
  From my subjective (user) point of view, flatpak is pretty fine. Yes, I do get annoyed whenever I run flatpak update and see 5-10 updates to drivers or runtimes in the range of ~100MB each. But I also want applications to be "just working". What kinda annoys me though is that file dialogs open in the background. Now I am used to check for it, but when the main window is still in front, yet blocked, because focus is in the file dialog modal, that can get confusing for a moment. AppImage is ok for me too, the application needs to be "complex" enough to justify the download size though. Precisely what the KCalc example from the article does not do. I didn't even know there is a daemon thingy that auto-integrates them, usually I put them in a folder, grab an icon somewhere and place it next to it with same name, then add an entry in OS manually, so it appears in app starter, can be placed on task bar, etc. It's just a few clicks and if I ever get annoyed by it because I find myself doing it several times a day, I should ask myself if I am maybe just installing way too much stuff? :) Edit: Wanted to mention there is an application called "FlatSeal" that lets you view and (to a degree) edit permissions of Ftatpak Apps. https://github.com/tchx84/flatseal https://github.com/tchx84/flatseal (I use it for spectating only on occasion, because too much fiddling will probably break the app at some point).
  • kirbyfan64sos 5y ago
    The file dialog issue is fixed in xdg-desktop-portal-gtk 1.10: https://github.com/flatpak/xdg-desktop-portal-gtk/pull/347 https://github.com/flatpak/xdg-desktop-portal-gtk/pull/347
  • southerntofu 5y ago
    > usually I put them in a folder, grab an icon somewhere and place it next to it with same name, then add an entry in OS manually I'm also familiar with this approach, but that's unfortunately something i can't easily teach my friends. AppImageLauncher is arguably more user-friendly, and i wish it were more commonly distributed as a distro default.
  • wander_homer 5y ago
    > From my subjective (user) point of view, flatpak is pretty fine. Yes, I do get annoyed whenever I run flatpak update and see 5-10 updates to drivers or runtimes in the range of ~100MB each. But I also want applications to be "just working". For most updates those download sizes are not really representative for the actual update size. For example right now I had two updates available with a total size of 336.5 MB + 275.2 MB. However `flatpak update` actually only had to fetch 17.4 kB + 4.4 kB and was done in a few seconds.
• anothernewdude 5y ago
  > If I ship an app for Windows I don’t have to include the entire Win32 or .NET runtimes with my app. I just use what’s already on the user’s system. No, you just trigger the download on install to get the 15th version of the runtime
• spaniard89277 5y ago
  I don't know about others, but I use snap basically for apps that are not in the repository, and I can avoid the PPA mess. Currently the only app in my laptop with snap is Brave. I remember when I wrote the apt install brave, there was a line in the console suggestig to use snap. So for me, as long is anecdotal, it's fine. I agree with the author, it's too much bloat, it doesn't matter that disk space is cheap.
• mrweasel 5y ago
  My main complaint about solutions, like Flatpak or Snap, is that they add another package manager. Now I have to manage two sets of packages. The baseline tools, like all the GNU standard Unix tools, and other command line tools are still managed by DNF, APT, whatever, and then another set of apps are managed by Snap. It's pretty confusing, especially if you never use the "app stores" otherwise. You quickly end up with: apt install <some command line tool> and apt install gimp, but now that's a different Gimp than the one in App Store. You also can't really remove Gimp from apt, because it's weird that apt can't install everything. I haven't really used Flatpaks, but Snaps is confusing (to me at least), because it's doesn't actually replace APT and pollute the output of "df" and "mount". I'm also concerned that some packages will never be updated, or stuck on a library with security issues. Perhaps that me, but I'd rather that that one application breaks.
  • pfranz 5y ago
    You should point the finger at package managers. They never really addressed needs outside of system administration (to be fair, that's the problem they were trying to solve). Scripting languages came up with their own package system because package managers didn't fit their needs, I often found myself building from source and installing into my homedir because package managers wouldn't accommodate, industries (like the one I work in) came up with their own package management outside of the OS. Nix/Guix seems like the only one that's trying something different enough to address some of those other use-cases, but the cat's out of the bag for most people.
    • southerntofu 5y ago
      > Nix/Guix seems like the only one that's trying something different enough to address some of those other use-cases, but the cat's out of the bag for most people. Maybe that's because nix and guix don't interop despite having rather similar principles, and because we mostly don't have GUI for it (like GNOME Software has integration for flatpak) nor desktop integration (like AppImageLauncher). Are you aware of work being done in this space?
      • 5y ago
• zimbatm 5y ago
  There is a deep trend happening in software development. As the number of dependencies for building an application grows, it becomes exponentially harder to shake the tree. This used to be the role of Linux distributions, they were acting as a push-back force, asking projects to support multiple versions of C libraries. This was acceptable because there is not C package manager. Now that each language has their own package manager, the role of distributions have faded. They are even viewed as a form of nuisance by some developers. It's easier to support one fixed set of dependencies and not have to worry about backward-compatibility. This is something all distributions have been struggling with for a while now, especially with NodeJS. This trend is happening on all platforms, but is more pronounced in Linux because of the diversity of the system libraries ecosystem. On Windows and macOS, there are some SDKs the application can lean on. On Linux, the only stable "SDK" is the Linux kernel API.
  • vetinari 5y ago
    > On Windows and macOS, there are some SDKs the application can lean on. On Linux, the only stable "SDK" is the Linux kernel API. Now, with Flatpak, each runtime is an SDK on its own. However, unlike Windows and macOS, specific runtime is not being bound to a specific OS release, but to the app requirement.
    • zimbatm 5y ago
      That's right, it makes the problem worse. The first time I noticed that trend was on macOS, where applications bundle most of their libraries, and binaries compiled for multiple architectures. Then we had Electron apps that ship with their own full copy of a browser and dependent libraries. When NPM was designed, they observed that resolving colliding versions of the same dependency was sometimes difficult. Their answer was to remove that restriction and allow multiple versions of the same library in a project. Nowadays, it's not uncommon to have 1000+ dependencies in a simple hello world npm project. Our industry is moving away from that feedback force that was forcing developers to agree on interfaces and release stable APIs.
      • mschuster91 5y ago
• trollied 5y ago
  My experience with these is terrible. I install a JetBrains IDE via a package. I spent a very long time trying to debug a CMake problem that I assumed was my inexperience with CMake. After attacking various processes with strace, it dawned on me that the problems were caused by the IDE not being able to see files in /usr/local. A sandboxed dev environment! Lost for words... A relatively inexperienced dev would have a terrible time with such a thing - it couldn't even see dev headers & libs installed with apt.
  • Const-me 5y ago
    Very similar experience with .NET runtime on Linux. Microsoft ships .NET runtime as a Snap package https://docs.microsoft.com/en-us/dotnet/core/install/linux https://docs.microsoft.com/en-us/dotnet/core/install/linux One time I didn’t paid attention, installed Snap package instead of the native binaries, and then I spent several hours debugging “access denied” status returned by mq_open https://man7.org/linux/man-pages/man3/mq_open.3.html https://man7.org/linux/man-pages/man3/mq_open.3.html kernel API in my program which only happened when called from a C# program, but not C++ program running under the same user account.
  • bennyp101 5y ago
    Yea, a while back I tried out a flatpak for filezilla, but because it was sandboxed I couldn't set the default editor to anything on my actual machine, so uninstalled that and went with a deb which worked just fine
  • tored 5y ago
    This is the biggest problem with these containers at the moment, you don't get any feedback what permissions are missing, first you need to understand this is a permission problem with the container itself and then to understand what permissions are missing and then apply them correctly. For flatpak there is an api you can use to change permissions but for snap what I can remember that is not something you, the user, can change, that is up to the maintainer to enable them. Applications like an IDE uses a lot of different resources so I gave up on using that as a flatpak, luckily Jetbrains ships their IDEs as tar.gz binary package you can use instead. Flatpak works best when the application is very self contained, like Spotify, it streams music from an internet service, it doesn't require any special permissions. I used Bitwarden as a flatpak, it had limited file access with one granted directory (Downloads), I was going to download an attachment from the Bitwarden application, the file saving dialog started one directory up from Downloads, you had to pick and open the Downloads directory first before saving, however I managed to save my attachment in that starting location outside of Downloads, some void directory that I never found.
• xet7 5y ago
  It seems that Flatpak, Snap and AppImage are the present and future of packages that work on multiple distros. There are no other new alternatives in the article.
  • southerntofu 5y ago
    You may be interested to check out nix/guix. They're certainly not perfect either, but they represent a radically-different paradigm which can be worth researching.
• viraptor 5y ago
  > If I ship an app for Windows I don’t have to include the entire Win32 or .NET runtimes with my app. That's not the case anymore. If you're aiming higher than .net framework 4.x, you have the option of either self-contained package (your app + .net core - min 70MB - appimage approach), or framework dependent (requires .net version at installation - flatpak approach). I find the "things are not shared" section a bit weird though. Yes, not everything uses the same base and that's sad. But I've got 8 flatpak apps and 7 of them do share the runtime. We'll never get 100% unified and deduplicated approach here - in the same way we'll never unify Gtk/qt/tk/wx/... > Flatpak allows apps to declare that they need full access to your filesystem or your home folder, yet graphical software stores still claim such apps are sandboxed. Yes, distros really need to start talking about permissions / capabilities rather than some generic "sandbox". Some apps need to effectively read the whole disk. But maybe they don't need to write to home. Or maybe they don't need internet access. We'll have to get mobile-phone-like permission descriptions at some point, because a single label just doesn't describe the reality.
  • legulere 5y ago
    Even with .net framework 4.x you need to bring the framework with you, if you want to use the newest frameworks, as your customers might not have the most current version installed.
    • alkonaut 5y ago
      The point as formulated still stands though. You don't have to because you can always guarantee that your end users will have a Win32 runtima and a .NET runtime. There is a choice, and it's between using a later framework, and relying on the OS one.
      • pjmlp 5y ago
        The choice being stuck with what a specific Windows version has available and using OS APIs directly instead of C ones, e.g. ZeroMemory() instead of memset(), as the C runtime library isn't part of the OS.
• ikt 5y ago
  Snap startup speeds have increased considerably since https://ubuntu.com/blog/why-lzo-was-chosen-as-the-new-compression-method https://ubuntu.com/blog/why-lzo-was-chosen-as-the-new-compre... Spotify and telegram open up pretty much instantly for me. Ubuntu 20.04
  • southerntofu 5y ago
    I think the author's point was that snapd requires mounting apps at boot time which can take a while. That's a tradeoff i'm personally not willing to make, as someone who starts and stops machines several times per day.
• yyyk 5y ago
  >They should... Build a fine-grained user-interactive runtime permission system that requires the app to make Flatpak-specific API calls to activate permission dialogs What the article wants is useless without fixing Linux's security modules. Very few people know how to use SELinux or AppArmor, there's no standardization between distros and apparently even RedHat has given up. Flatpak and Snap do containerization because they have no good alternative. P.S. >If I ship an app for Windows I don’t have to include the entire Win32 or .NET runtimes with my app. Note that Microsoft has been moving away from that with .NET Core/.NET. The new runtime does not come with the OS. It's still possible to create a package and have .NET installed separately, but as far as I can tell, most people prefer to package with the runtime.
• smallerfish 5y ago
  I agree that the implementation is lacking. Snap has the abysmally named "--classic" parameter to allow installs to "run without confinement". Flatpak can request permission changes at install time (albeit declaring them), where users are likely to just click OK/OK/OK. The sandboxing needs to be tightened up. Flathub is a strange beast. There's no mention of security on their wiki. They stopped publishing minutes (or moved them elsewhere?) in 2017 (https://github.com/flathub/flathub/wiki https://github.com/flathub/flathub/wiki). They have a buildbot for automated updates from developers, but they accept binaries anyway (e.g. https://github.com/flathub/us.zoom.Zoom/blob/master/us.zoom.Zoom.json https://github.com/flathub/us.zoom.Zoom/blob/master/us.zoom....), so what's the point? It appears to be a fairly amateur effort, and yet is at the center of the infrastructure Red Hat and Gnome are pushing. I'd love to see some white hat activity targeted at compromising it, to demonstrate the shaky foundations. But on the other hand, it's nice that I can run Zoom sandboxed (apparently - it's not obvious what the granted permissions are: https://www.flathub.org/apps/details/us.zoom.Zoom https://www.flathub.org/apps/details/us.zoom.Zoom). It's nice that Jetbrains and Zoom have a way to publish apps that can run on all distros. It's nice that I could rollback a version of IntelliJ that was buggy with a single snap command that took 5 seconds. The goals are good. I wish Linus took more of a BDFL approach to the desktop occasionally. Ubuntu & Red Hat need to sit down in a room and have a constructive conversation to converge Snap and Flatpak into something new, deprecating the infrastructure built to date, and fixing some of the glaring problems. There's room for both to make money without further diverging the ecosystem.
  • IiydAbITMvJkqKf 5y ago
    the flatpak sandbox UX is bleak. right now, you have to check the JSON file you linked to check how much access a flatpak program gets. i disagree with the --own-name and --talk-name flags (i think this is for screensharing; zoom should use the screensharing portal instead. letting zoom talk to gnome shell directly could be bad.). --socket=x11 is a massive hole in the sandbox, since x11 does not have a security model - any client can observe and manipulate any other client. for x11, a viable solution would be running flatpak apps in xephyr, but flatpak doesn't do that. long-term, wayland is a better solution.
• marcodiego 5y ago
  Don't know if it is the future, but has been making my present much better. I can finally have a stable distro with released yesterday packages. As a test I tried installing GIMP on raspberry pi, a x86 bits ubuntu 18.04 machine a x64 bits ubuntu 16.04 machine and x86 bits ubuntu 20.04. Three architectures, 4 distros, 4 machines: 1 command, the same software. It took a bit long to install on the raspi but it worked. Flatpaks, snaps and appimages finally blurs the lines between distros. If there are problems, they should be improved, not abandoned.
• oleg_antonyan 5y ago
  As Linux user and app developer (shameless plug https://github.com/olegantonyan/mpz/ https://github.com/olegantonyan/mpz/) I deliberately avoid snap/flatpak/appimage/etc. Instead, I suffer with Open Build Service https://build.opensuse.org/ https://build.opensuse.org/. It's kind of cool, free and can build for multiple distros, but making it actually do so is a pain. But I still prefer this over flatpak&co both as user and as developer. It just doesn't look like "the future of application distribution", https://nixos.org/ https://nixos.org/ does.
  • zohch 5y ago
    Why would you rather install some random rpm from someone you don't know as opposed to a flatpak?
    • oleg_antonyan 5y ago
      This works both ways: Why would you rather install some random flatpak from someone you don't know as opposed to a rpm? The trust is outside of the scope of package managers
      • zohch 5y ago
        Because installing an rpm allows you to run arbitrary code as root. Installing a flatpak does not. I mean there are many more reasons but that should be en.
        • oleg_antonyan 5y ago
          It's explained in the article, security section: b/c installing flatpak can also run arbitrary code as a user. And I won't argue that running malicious code as a user is always harmless. Regardless of root access if you're installing flatpak and its author want to pwn you - they can do it even without root access
          • cromka 5y ago
• bayesian_horse 5y ago
  Very valid points. But the average open source app developer or even a developer of a commercial application for linux just doesn't have the time, energy or money to keep installation instructions up to date and support those both with development time and by responding to issues.
• anotherhue 5y ago
  If you find these sort of problems interesting, I couldn't recommend checking out NixOS more. IMO it's the next generation solution.
  • bogwog 5y ago
    or GNU Guix
• panick21_ 5y ago
  > If you are a Linux distribution maintainer, please understand what all of these solutions are trying to accomplish. All your hard work in building your software repository, maintaining your libraries, testing countless system configurations, designing a consistent user experience… they are trying to throw all of that away. Every single one of these runtime packaging mechanisms is trying to subvert the operating system, replacing as much as they can with their own. Why would you support this? This sound like a luddite that is against machines. How about embrace the revolution and then you can save a huge amount of work and focus on other things. There are enough things distor people could focus on instead. I don't buy any of the technical arguments here and it sounds mostly like moralizing argument rather then anything else.
  • ltbarcly3 5y ago
    The whole point is that this is technically worse and only being used to try to bootstrap a walled garden where they (RedHat, Canonical for flatpack or snap) get paid a fee due to a monopoly on app distribution to their users. This is not 'the revolution' we should support. I encourage you to study the technical arguments until you understand them well enough that they become convincing.
    • panick21_ 5y ago
      > monopoly on app distribution to their users And the argument that it is a walled garden is simply nonsense. Its not monopoly any more then any default repository is. > I encourage you to study the technical arguments until you understand them well enough that they become convincing. I have been using flatpak since it came out and many other people in this thread have already pointed out the failure of the technical arguments, no need to do that again.
      • ltbarcly3 5y ago
        I guess Canonical, who makes 100% of their revenue on support contracts for open source software, doesn't release the snap server code in open source because... what's the reason you are going to come up with? What possible reason is there apart from making it difficult for anyone else to set up any repository at all? It's the same reason they bet big on Ubuntu on Phones. App stores are worth a ton of money, you contribute effectively nothing and collect 25% of other company's revenue purely because you can lock out any competing app store.
• faichai 5y ago
  Feel like we’ve really missed an intermediate solution based around tree-shaken statically compiled code. A lot of the goals achieved by docker et al could be met with some kind of multi-elf file format that is basically a collection of statically linked executables combined with a way to read built-in configuration files. Maybe this already exists / works.
  • southerntofu 5y ago
    Not exactly what you're suggesting, but nix/guix addresses most of the problems around dynamic linking.
• faho 5y ago
  > How much progress could we make if Steam deprecated their runtimes, abandoned containerization for new games, and let all new games just use the native system libraries? How loudly do you think gamers would complain if a distribution upgrade broke their favourite game? If the steam runtime didn't exist, most gamedevs would only target the most popular distro - probably the current Ubuntu LTS, and you would have to recreate the runtime on your distro of choice. And once there's a new Ubuntu release you would also have to recreate it there (or the game updates and now you'll have to recreate it on the now-old version). The choice isn't between steam runtime and a utopia, the choice is between the steam runtime and something much worse. Linux libraries simply aren't stable enough in API and ABI.
  • dxuh 5y ago
    And realistically if they could only target a single distro, they would likely not bother making Linux builds at all.
  • southerntofu 5y ago
    Yet the steam runtime could be maintained/distributed using a more robust and explicit mechanism such as guix or nix, don't you think?
    • bogwog 5y ago
      Guix is a great solution to this problem. It's a shame that there aren't any distributions based on it (afaik) besides the official GNU one, which is not very practical outside of a VM due to their aversion to anything proprietary.
• david_draco 5y ago
  Re security: This is probably best fixed by packaging apps with SELinux rules, which are enforced and cannot be disabled, plus responsive maintainers. There could be more than one app version to allow different SELinux rule strengths, per-app. Re disk space: no mention of Nix? That also solves updateability for security issues. Another solution is Gentoo's -- deliver the sources and recipes, (re)build as needed. That could also work in userspace. It would be nice to be able to 1) distribute Linux GUIs 2) let friends install them easily 3) have the friend edit the GUI app logic and run the modified version. AFAIK, this is currently only possible with apps based on interpreted languages (e.g., Python+GTK), but even there you'd need to guide your friend to install the required packages. Re "the state of software complexity in 2021": Ignore complex software, and just don't include it on your system. Start with a subset, and add only what you need. That's how OpenBSD remains manageable. If people want to extend, they can go ahead. But you don't have to fix the world.
  • kirbyfan64sos 5y ago
    Making LSM-based rules for desktop applications is relatively complex and inflexible (what if the user wants to grant access to a file for a short amount of time? Portals let you do that). Are you rebuilding policies on the fly?
    • southerntofu 5y ago
      Is there a reason SELinux/AppArmor policies couldn't be live edited for that kind of purpose? As it is it would require root, but wouldn't it be possible to extend security rules with user rules which could add restrictions but not lift system-wide restrictions? This (hypothetical) way we'd package eg. GIMP with a user profile restricting it to ~/Documents and /media/USERNAME, but you could then grant it additional permissions (eg. to ~/Pictures).
• The_rationalist 5y ago
  windowes exes/msi have solved this since the down of time, why can't linux replicate this?
• Damogran6 5y ago
  Sighs at the next 229Gb required update to Flight Simulator 2020
• jaclaz 5y ago
  This clearly shows how old I am (or have become), it is a (crappy) calculator: >Note that the app package itself is only 4.4 MB. Calc 98 is huge at 495 KB: http://www.calculator.org/download.html http://www.calculator.org/download.html Xcalc (RPN) is around 200-240 KB: http://www.tordivel.no/xcalc/ http://www.tordivel.no/xcalc/
• dxuh 5y ago
  I think this article is not providing adequate alternatives. Most programs link against quite a bit more than libstdc++ and you clearly can't expect users to install a bunch of packages to get their program running. Those extra libraries usually take up most of the space in a package. If you include all the shared libraries you need, apart from the system libraries in your distribution, you pretty much have an AppImage already, just as a tarball instead of a squashfs image. I think GOGs path is not horrible, but it is much less effective at making Linux a viable alternative as a gaming platform. They literally only support Ubuntu 16.04 and 18.04. It also struck me as odd, that the author was complaining about the complexity introduced by Proton. What is Valve supposed to do?
  • southerntofu 5y ago
    > you pretty much have an AppImage already That's not wrong, but AppImage is focused on the UX of the application as single file, which you can move/copy around and can be integrated with the desktop launcher, which i personally don't know of standard solutions for with a classic tarball. For example, Tor Browser is a classic tarball and works great, but the .desktop generation relies on some hacks rather than a properly-defined mechanism. > the author was complaining about the complexity introduced by Proton That's not what i understood from the article. I mean wine/proton makes sense on its own to run Windows apps, i think the author was criticizing that their specific approach relies on steam-specific runtimes instead of using system libraries.
• incrudible 5y ago
  I have had the least issues with AppImage. It does not fit every use case. It does not need to. If you can ship an AppImage, please consider doing so.
• freebuju 5y ago
  Flatpak is the future of Linux desktop applications for so many reasons, but among them it allows users not to be caught up in the dependancy mess that plagues Linux distributions. Some of the criticism here does not belong to Flatpak. E.g Fedora's weird duplication of repositories is exclusively a Fedora problem. Has absolutely nothing to do with Flatpak. Applications such as VLC and GIMP which 'ship' with access to whole filesystem permission is an eternal dilemma. Would you rather the authors ship without access to this permission and break app functionality ? Or let them ship with restrictive permission and allow users to manually enable respective permissions to regain function when the software breaks? It is easy to see the feasible decision here that works for all parties here. The permission on the different accessibility store however has confusing labels on sandboxing, I agree with the point that the store should make this as clear as possible. I think the bigger point the article misses is the ability to control these permissions at this level. Even if the software author ships 'dangerous' default permissions, the user can always revert this decision and sandbox it effectively if they so wish. Flatpak is a crucial needed fix for the Linux package distribution problems highlighted elaborately by this article but in my humble assessment, the benefits to this solution massively outweigh the nuances such as the one the author mentioned about package sizes.
  • jcelerier 5y ago
    > Applications such as VLC and GIMP which 'ship' with access to whole filesystem permission is an eternal dilemma. Would you rather the authors ship without access to this permission and break app functionality ? to give a data point, I work with a lot of artists who use Macs and none of them use mac app store apps because of endless issues when accessing the file system
  • smoldesu 5y ago
    Counterpoint: Flatpak doesn't really solve anything, and I have no reason to use a Flatpak'd version of a software when there's a native version in my system repos. A lot of people feel this way: they see it when Flatpak doesn't adopt their native system theme, they see it when they try opening a filepicker and it starts in some esoteric location, they see it when they want to edit files of a Flatpak'd app and need to spend the afternoon locating it's binary. There are so many papercuts, bugs, regressions and failures on Flatpak's behalf that I don't think anyone would really want to adopt it unless they were forced to. I speak only for myself, but I will never enable Flatpak on any of my devices. A lot of other Linux users share the sentiment.
• Zardoz84 5y ago
  And nobody talks about Slax modules. Too many years ago, they had some basic containerization (only at filesystem level). If it got some kind of dependency managment, it would be really great.
  • AnIdiotOnTheNet 5y ago
    As I recall, Slax used aufs-based filesystem overlays.
• mjg59 5y ago
  People have tried to provide a packaging format that would allow apps to declare their depencies in a distribution neutral manner[1]. It was, uh, not a huge success. Let's take an extreme example. If I build an app on Ubuntu and then try to run it against the system libraries on Alpine, it'll fail, because Alpine is built against a different libc. We can simply declare Alpine out of scope and only support glibc based distributions, but if we want good cross-distribution support we're still going to be limited to what's shipping in the oldest supported version of RHEL. So let's skip that problem by declaring LTS distros out of scope and only target things shipped in the last 3 years - and now apps can't target any functionality newer than 3 years old, or alternatively have to declare a complicated support matrix of distributions that they'll work with, which kind of misses the point of portability. In an ideal world distributions would provide a consistent runtime that had all the functionality apps needed, but we've spent the past 20 years failing to do that and there's no reason to believe we're suddenly going to get better at it now. The Flatpak approach of shipping runtimes isn't aesthetically pleasing, but it solves the problem in a way that's realistically achievable rather than one that's technically plausible but socially utterly impossible. Flatpak is a pragmatic solution for an imperfect world - just like most good engineering is. Edit to add: one of the other complexities is that dependencies aren't as easy to express as you'd like. You can't just declare a dependency on a library SONAME - the binary may rely on symbols that were introduced in later minor versions. But you then have to take into account that a distribution may have backported something that added that symbol to an older version, and the logical conclusion is that you have to expose every symbol you require in the dependencies and then have the distribution resolve those into appropriate binary package dependencies, and that metadata simply doesn't exist in every distribution. [1] http://refspecs.linux-foundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/packagefmt.html http://refspecs.linux-foundation.org/LSB_4.1.0/LSB-Core-gene...
  • renonce 5y ago
    > People have tried to provide a packaging format that would allow apps to declare their depencies in a distribution neutral manner[1]. It was, uh, not a huge success. Have you looked into Nix?
    • 5y ago
• mwcampbell 5y ago
  > The state of software development is downright miserable in 2021. This tired refrain shows an obscene lack of gratitude for all the things that just work. Yesterday evening I participated in a Twitter Space on gratitude for all the great things we have as software developers, and I will repost the recording here when it's available. Edit: My mistake; the recording was already posted: https://www.youtube.com/watch?v=U10SuAHV8kQ https://www.youtube.com/watch?v=U10SuAHV8kQ
• asoneth 5y ago
  A good illustration of why easy wins every time. In my experience, Flatpack and their ilk make it easier for end-users to install applications and for developers to distribute them. Alternatives may be orders of magnitude better from a performance, size, and/or complexity standpoint but until they're at least as easy for both end-users and developers they'll never reach critical mass.
• xtracto 5y ago
  Meh... i used to install tarballz, hunting for .so files, then RPMs hunting dealing with circular RPM dependencies, then DEBs dealing with unmet dependencies. As I age all that got boring. I hate Snaps because of how intrusive is with the system. Flatpak brings Linux to what OSX had like 10 years ago. It just works Regarding download size? Even I, living in a third world country, have an internet connection good enough to not care about download sizes... Regarding file redundancy. If that is much of a problem for anyone, I'm sure that could be dealt with at the file system layer: hash/detect duplicate files and compact them, then copy on write. Personally, HDD space hasn't been an issue for me on PC or laptops in a long time. Flatpak finally just work and we have the technology to make it usable. Moreover I argue that flatpak IS the future as those 2 previous points will become more irrelevant as time goes by.
• antihero 5y ago
  > This is uncompetitive with Windows on its face. If I ship an app for Windows I don’t have to include the entire Win32 or .NET runtimes with my app. I just use what’s already on the user’s system. What about the gargantuan WinSXS folder?
  • ectopod 5y ago
    This is legacy now. The latest .Net stuff (whatever they're calling it this week) bundles its dependencies, so it's no better than flatpak in that regard.
• lobstrosity420 5y ago
  Unfortunately, Flatpaks are the new SystemD. As in, a solid technology which solves real world problems but will face immense resistance from a community filled with splinter groups that have their own pet technology on the same niche, and will accept absolutely nothing else as an alternative. There is simply no path to standardization in this community other than big players like Red Hat and Canonical strong arming their pet technologies in, much to the disdain of everybody else. As for me I'll keep using Flatpaks as they work great and have wide support. Alternatives are either obnoxious to use (Nix and Guix) or lacking in basic functionality (Appimages).
  • goodpoint 5y ago
    SystemD is not harmful for distributions. Flatpak replaces high-granularity, properly managed dependencies and security updates with huge blobs.
    • lobstrosity420 5y ago
      Flatpaks are not meant to replace established package managers, but to act as a supplement to them. Flatapak's design decisions go to huge lengths to ensure they are a side-by-side system with default package managers e.g. the notion that Flatpak packages have a different XDG_CONFIG directory so as not to conflict with applications installed via the main package manager. Therefore the argument that they are harmful to distributions is absurd, as there is no aim to replace your precious "properly" managed dependencies and the option to never opt-in will be always available.
      • nickelpro 5y ago
        If flatpaks weren't in competition with packages repos they would serve no purpose. They are explicitly in competition with package repos. They exist so that app developers can get their work out to users without cooperating with downstream packagers.
        • lobstrosity420 5y ago
• bogwog 5y ago
  This gave me an idea: how about shipping an installer with an embedded appimage. The installer will check the system libraries for compatibility, and if compatible, it will install the application so that it uses the system libraries. If not compatible, it will install the appimage (and do the desktop integration stuff). I actually really like appimages for distributing games and small apps. The user experience is a lot like executables on Windows, where you can just download any exe from anywhere and expect it to just work. Sure, the large size can be a problem, but not every appimage will necessarily end up that huge. The lack of sandboxing isn't a big deal in my eyes because as the author mentioned with Flatpaks, most apps end up with too many permissions anyways. Proper sandboxing needs some kind of gate keeper/moderator to pressure developers into following the rules. This can be done with app stores, but the only working app store for Linux desktops is Steam, and that's only for games. (to be fair, KDE Discover works, but it's a very poor user experience)
  • lobstrosity420 5y ago
    In this scenario, what would be the point of deferring to the system libraries if you already shipped and made the user download the built in ones? As far as desktop integration goes, there is already a tool available that will setup the .desktop file for you when you first run an Appimage. >The lack of sandboxing isn't a big deal in my eyes It should be, executing random Appimages you've downloaded online is a huge security liability. >Proper sandboxing needs some kind of gate keeper/moderator to pressure developers into following the rules You make a good point in that a good moderation in the store is very important, but even lacking that you can still tweak the sandbox permissions yourself (very easily in fact with Flatseal) and it rocks to have that feature available to you.
    • bogwog 5y ago
      > In this scenario, what would be the point of deferring to the system libraries if you already shipped and made the user download the built in ones? Presumably you'd delete the installer after you finished installing the app, the same way people do on Windows. Also, the appimage could be compressed in the installer to reduce the size. I haven't worked out all the implementation details, but I'm sure it's doable in a user friendly way. > It should be, executing random Appimages you've downloaded online is a huge security liability. That's FUD, nobody is downloading and executing "random" software from the internet (if a trusted developer gives you malware, that's another story). Checksums and/or code signing can add peace of mind. Windows and MacOS have done just fine without any sandboxing whatsoever. I'm all for sandboxing, but if it isn't being implemented properly, it's just an extra layer of headache on the frustration cake that is Linux software distribution. > you can still tweak the sandbox permissions yourself You and I maybe, but the average user who just wants to install GIMP isn't going to understand why they'd want to do that. Why should I be suspicious of this app? Is the developer is shady? Who even is the developer? Is the distributor shady? Who even is the distributor? Is my wifi password not strong enough? etc
• hermitcrab 5y ago
  I write commercial applications in Qt/C++ for Windows and Mac. People do ask me about Linux versions. It would be relatively straightforward to port the code to Linux. But the mess of different distributions and libraries really puts me off. Is anyone here distributing a commercial Qt/C++ app on Linux? Are you using Flatpak or something else?
  • cromka 5y ago
    Just use AppImage. They can download it as-is from your website and simply run locally. No need to deal with distributions and their package managers. EDIT: if you use CMake, which I guess you do, you can integrated it using CPack and an external generator: https://github.com/AppImage/AppImageKit/issues/160#issuecomment-813069225 https://github.com/AppImage/AppImageKit/issues/160#issuecomm...
    • hermitcrab 5y ago
      I will put AppImage on my todo list to check out. Thanks. I still use qmake (old school!).
  • jcelerier 5y ago
    Vouching for AppImage too, I ship https://ossia.io https://ossia.io like that
    • hermitcrab 5y ago
      Ossia looks impressive. Does it use Qt or some other GUI library?
      • jcelerier 5y ago
        Yes, it uses Qt for the GUI. Thanks ^_^
        • hermitcrab 5y ago
          I am very out-of-the-loop on Linux. Your download page says: "Your system must have at least glibc-2.17, as well as X11, ALSA, libGL, librt, libdbus." What rough percentage of modern Linux computers would you say that covers? 99%, 90%, 50%?
• sdfghderwg 5y ago
  > I implore you, do not use these packaging tools. Don’t add their services to your Linux distributions, don’t use apps packaged this way, and don’t ship apps that use them. Mass containerization and alternate runtimes cannot possibly be the future of desktop apps on Linux. If this is really the direction it’s going, the future will be so shitty that we’ll all end up back on macOS or Windows. As a long time desktop user, I've dropped Ubuntu for Debian because of this. At some point in the past Ubuntu seemed like it was going all in on snaps. I don't know what they're doing now, but I don't care any more.
• LinAGKar 5y ago
  >Note that the app package itself is only 4.4 MB. The rest is all redundant libraries that are already on my system. The author promotes avoiding this redundancy by using the libraries on the host. But maybe we should go the other way, by having only the bare necessities to run the OS installed on the host, and install all applications as Flatpak. I agree with some things though. Different versions of the runtimes should share as much as possible, so as to consume as little space as possible, and libraries retaining backwards compatibility would help with this. And applications should target the regular Freedesktop/GNOME/KDE runtimes if possible, Fedora shouldn't be doing their own thing completely separate from Flathub. And we need to get applications to use portals and not allow them to declare file system access on install time.
  • Andrex 5y ago
    > But maybe we should go the other way, by having only the bare necessities to run the OS installed on the host, and install all applications as Flatpak. I believe this is the approach Endless OS and Gnome OS are using.
• smoldesu 5y ago
  I'll keep this short and sweet, because I could complain about Flatpaks for hours: If you distribute your software via Flatpak, you can forget about me ever using it. Every computer I own has Flatpak disabled, and I will use system repos until the day I die. Plan accordingly!
  • mikewhy 5y ago
    And you're totally free to do that. Maintainers should also be free to ignore support requests when people choose to use outdated versions of their software.
• comma_at 5y ago
  This is all good and true, but it's looking at the problem from the Linux distribution's perspective. The user wants a working application. Something like AppImage allows a small team to distribute a working package for every distro. Now imagine that team of 5, working on their app, packaging it for ubuntu, fedora, arch, rhel, ... It's just not possible. What would solve this issue? A common package manager and central repository, across all Linux distributions. Then the small team only needs to package and ship to one repository, in 1 format.
• thereddaikon 5y ago
  "Software has gotten so much slower and more bloated that operating systems no longer run acceptably on spinning rust." I'd argue they never did. Hard drives have always been slow and when they were the primary means of storage on the PC, people were always trying to find ways to speed things up. Now it takes seconds to boot rather than minutes. "Laptop manufacturers are switching to smaller flash drives to improve performance while preserving margins. Budget laptops circa 2015 shipped with 256 GB or larger mechanical drives. Now in 2021 they ship with 120 GB flash. " This is outdated information. I just checked Lenovo's store and while they do have a super low end machine at $200 with 64Gb of EMMC, their real budget model laptops start with a 256Gb SSD. The standard ThinkPad we order this year for users had a 1Tb SSD. Is it budget? No. But building towards the lowest common denominator is rarely worthwhile without good reason. "Chromebooks are even smaller as they push everything onto cloud storage. Smartphones are starting to run full-fledged Linux distributions. The Raspberry Pi 4 and 400 use an SD card as root device and have such fantastic performance that we’re on the verge of a revolution in low-cost computing. " Chromebooks and RPi's are not PCs. Yes, some enthusiasts use them that way but that is a niche and done by people who know what they are doing. They can easily enough avoid flatpacks. Linux is a big place and its versatility allows for designing distros around multiple use cases. Flatpack and Snaps are meant to make software distribution easier. Constraints such as storage are not a primary concern for most users. Most machines have enough. Their mere existence does not mean other methods of deploying software aren't available so if storage is a constraint, then simply don't use them. A lot of the arguments against Flatpack and Snap seem to be based around "it's not good for my usecase" ok. Then don't use it. "Each app with a new runtime adds another hundred megs or more of RAM usage. This adds up fast. Most computers don’t have enough RAM to run all their apps with alternate runtimes. The Raspberry Pi 400 has only 4 GB of RAM. Low-end Chromebooks have only 2 GB. Budget laptops tend to have 8 GB, mostly thanks to the bloat of Windows 10, but these app packaging solutions are catching up to it." My case in point. Still referencing niche machines. Most RPi's are used for a dedicated purpose. 99% of Chromebooks never exist Google's ecosystem for it. And their concept for what qualifies as a lot of memory is, I think, out of touch. 8GB is the base for an x86 PC. Not a Chromebook but a real PC. Many have 16 gigs and its not uncommon to see up to 32 in laptops and even more in workstations. "Why shouldn’t storage shrink anyway? Software should be getting more efficient, not less." My knee jerk response is "why?". My more thoughtful one is that efficiency can be measured in many ways. Resource usage becomes inefficient when the user determines it is. And everyone has a different idea of where that lies. Nobody is multitasking more than a couple of applications at any one time on a PC. Servers are different but Servers aren't an intended use case for Flatpack and Snaps. If I can run the software I want at acceptable performance then its resource consumption is efficient enough. But you know what Flatpacks are more efficient with? Time. I don't have to deal with dependencies. I just tell it to install and it works. Given how awful the application management experience is in Linux traditionally, I am willing to take the downsides for that massive upside. "Such an app can drop a malware executable anywhere in your home folder and add a line to your ~/.profile or a desktop entry to ~/.config/autostart/ to have it auto-started on your next login. Not only will it run outside of any container, it will even persist after the app is uninstalled." I think he has a point with security. Permissions can be vague and misleading. And they do have a supply chain attack vulnerability. But that's true of any software you get from the repository, store etc. If the official Fedora's official Flatpacks can have malware then so can their official Repo. His section about identifies clashes is not an inherent problem with Flatpack but rather a procedural problem with Fedora and Flathub. I think its weird he brought it up when he started the article saying he wouldn't include easily solvable issues. Yet here we are. "You would think that these packaging mechanisms would embrace simplicity if they want to attract software developers. In fact they are doing the opposite. " This is the efficiency problem again. Define simplicity. What is simple in one area is complex in another. The fact is nothing as complex as software on a computer can be simple everywhere. If it were it would be useless. So the question is not how to make it simple. It is where are you placing your complexity. Traditional package management places the complexity on the user while keeping the software simple. Flatpacks place the simplicity on the UX while making the software complex. None is inherently superior. Its all about design goals. "All of these app packaging systems require that the user have some service installed on their PC before any packages can be installed." And? All software has dependencies and a lot requires some kind of run time. Does he also consider all Java software problematic because they require a JVM first? What about all web based applications requiring a compliant browser? This is a non issue in context of how everything else works in the 21st century. "A major goal of most of these technologies is to support an “app store” experience: Docker Hub, Flathub, the Steam Store, Snapcraft, and AppImageHub (but not AppImageHub?) These technologies are all designed around this model because the owners want a cut of sales revenue or fees for enterprise distribution. (Flathub only says they don’t process payments at present. It’s coming.)" Conceptually there is no difference between an app store and repository. They are the same thing. App stores are just repos that are more user friendly. "This is very far from the traditional Windows experience of just downloading an installer, clicking Next a few times, and having your app installed with complete desktop integration. This is true freedom. There are no requirements, no other steps, no hoops to jump through to install an app. This is why the Windows Store and to some extent even the macOS App Store are failing. They can’t compete with the freedom their own platforms provide." I didn't expect him to advocate for the windows model. And I actually agree. Windows handles application management the best. However a lot of the criticisms he gives Flatpack would apply to windows too though. You are guaranteed to end up with multiple copies of certain dependencies because Microsoft's answer to dependency hell was to let developers ship their dependencies with their product and not have to care what everyone else had. This is extremely space inefficient and can make for ugly under the hood management but it works very well. The author misses that in his article because he just measures the size of an installer, often Windows software ships not as one file but as many and the install.exe merely orchestrates the process. Again, its all about where you place your complexity. In Windows world the complexity is rarely encountered. Apps get to bring their baggage with them and decide where it all goes. This means program files can get ugly and inconsistent and you may have to learn the behavior or individual software but it usually works the first time. "The Current State of Backwards Compatibility" I have news for you. Linux's biggest problem here isn't that new revisions break compatibility. Its that old versions can become unavailable. The repo model of software distribution lends itself to "link rot" Load up an older version of Ubuntu and it cant talk to the repos anymore. The servers are gone. And since until recently almost all software was distributed this way and managed by a package manager you effectively can't get software working in old Linux. Software preservation becomes monumental if not impossible. With older windows versions, if I have the install media whatever form it may take then I can install and use the software because it shipped with all of its dependencies included. No nebulous server required. DRM notwithstanding of course.
• apexalpha 5y ago
  As a linux user, but not a developer, I've always been surprised by the backlash against Flatpack and Snap. For me they work wonderfully. On Ubuntu I usually go for the Snap since it just works. Solving multiple dependency issues before I can use a tool always cost me time before. Now, not so much. Even AppImage is nice. The fact that most software is even available on Linux now is due to the fact that developers can create one app for Linux, in stead of multiple. Maybe I'm not familiar enough with GNU/Linux to see the drawbacks, but if it's just disk space I'll happily make that trade.
• isaiahg 5y ago
  I usually steer clear of these types of discussions because I find the arguments ultimately pointless in the end. The users pick the winner based on their experience regardless of the merits of the systems available. Also I'm certain I'll come out of this worse for wear, as is the experience whenever one crashes a heated debate among engineers arguing over which is the better standard. So I'm going to hastily step into this den of wolves and jump out again. The fundamental issue I find with all these distribution systems is that they always seem more designed to justify a computer science degree rather than solving the problem in a user friendly way. And that applies to debs and rpms as well. All the solutions seem so over-engineered to the point that only engineers have a hope to get any kind of consistent usable experience out of it. Certainly you can try to hide all that complexity behind a nice GUI with icons and layouts, but that only works so well until something goes wrong. And then the user is stuck juggling a broken system and waiting for a reply on a support forum that may never come. That also mirrors my views on why Linux has yet to break into the mainstream desktop market. But lets go even further, another fundamental issue. Sometimes it feels like these systems are working to justify a basic design choice of Linux that's overstayed its welcome. The idea to separate libraries and binaries was a fabulously beautiful engineering idea to fix a problem that stopped being an issue a decade ago. When your system has 32mb of storage, it makes sense, but less so when you can buy a 2tb solid state drive for $120 on Amazon. Counter to the argument in the article, storage is cheap and becoming cheaper at such a rate that continuing this philosophy will appear more odd by the day. And now we've officially come full circle and engineered it away with flatpak and appimage. In an ideal world, these perfect systems should work beautifully. But users aren't perfect and neither are developers. That's why I now value software not by the novelty of how it solves a problem but in how few parts it can do it. For all Elon Musk's personal issues, he was letter perfect about one thing. The best system is no system. The best process is no process. For every additional step of complexity you add when solving a problem, you gain three additional problems. 1. You have to maintain it across the half-lifes of developer interests. 2. You have to teach users and developers how to use it the right way, a nearly impossible task. 3. All the systems that rely on it become more complex, duplicating problems 1 and 2 ad nauseam. For me part of the answer was missed 12 years ago with AppImage. It works so well that I find myself breathing a sigh of relief whenever I find an application I want that uses it. That's because I know it'll just work. It's a testament to the usability of AppImages that it's still in use years later even without support from major distros. I think the linux community at large is at risk of missing something very good there. At least for user facing programs, it works wonderfully.
• siwatanejo 5y ago
  "There will still be occasional differences between distributions. These are things you can work around. It may be painful at first but it will be worth it: you will provide a much superior user experience by working around the issues with your users’ libraries rather than attempting to replace them." Sure, like it was happening 20 years ago, and we still had apps break ALL THE TIME when the user just upgraded to a new distro version or when she changed her distro. It's simply not scalable. It has already been tried. Sure, the flatpak world is not perfect, and I would never choose this option (maybe I like snap better), but it's a step in the right direction.
• boudin 5y ago
  There quite a few things I don't agree with in regard of this article. First, the suggestion that permission should be prompted when running the app, the app using some sort of API. This would mean that Linux app should become tightly coupled to Flatpak. I have no idea how it would be possible to convince all developers, distributions, vendor to adopt Flatpak. I think it would be largely ignored so an ineffective way to bring those change to the Linux ecosystem in the end. Then, I don't have the real answer, but prompting users with questions when they use the app is the worst approach to security. Being tech literate helps understanding what's happening, but people with less understanding answer those out of annoyance because they're trying to do something and, all of a sudden, the operating system gets in the way. The choice is not driven by security concerns but by frustration or urgency. I can't think of any operating system that found the right solution yet, but I do think that the Flatpak approach is by far the smartest. Just naturally give access to things by following user choices (just give access to the select file once the file is selected, just give access to the screen the user choose to share once the user choose to share it). No more stupid prompt that gets in the way of things. Speaking of runtimes, it's exactly the same problem. For Flatpak to be adopted, it would require all distribution to invest a lot in it. How would it work for Gentoo and its use flags for example? How to deal with different versions of dependencies? What would happen would likely be for distribution to build the equivalent of runtimes, but on their side, allowing to have several versions in parallel. So in the end, it would be a similar situation, but much more messy as each distribution would have to do the job. Is having those runtimes an actual problem or the solution that Flatpak came up with to the problem of fragmentation in distributions? In my opinion it's the second.
• awill 5y ago
  This article is full of either errors, or at least misleading statements. It comes across as trying to say something controversial to get attention. Just one obvious glaring issue with the article: >Note that the app package itself is only 4.4 MB. The rest is all redundant libraries that are already on my system Um, no. It's not redundant. Your system might get updated, replacing the needed libraries with backwards incompatible libraries, and then your app would break. I do agree with the general idea that not limiting possible runtimes to an approved list means essentially infinite runtimes, which can balloon disk space. I think you need choice to prevent stifling innovation. At least at first. But hopefully the community will end up doing the right thing here over time.
• danShumway 5y ago
  Lots of other debate (both pro and con) that I'm not going to get into. I like the effort going into Flatpak, but I don't like everything it's doing. Is Flatpak really secure, is it's permission system good, how does resource sharing work, whatever. I'm not going to comment on any of that in either direction. But I do want to call out this specific paragraph: > Apparently, developing client APIs for apps themselves is antithetical to Flatpak’s mission. They want the apps running on Flatpak to be unaware of Flatpak. They would rather modify the core libraries like GTK to integrate with Flatpak. So for example if you want to open a file, you don’t call a Flatpak API function to get a file or request permissions. Instead, you call for an ordinary GTK file open dialog and your Flatpak runtime’s GTK internally does the portal interaction with the Flatpak service (using all sorts of hacks to let you access the file “normally” and pretend you’re not sandboxed.) Heck client APIs. This is the correct way to do sandboxing, for two reasons: ---- First, this is not something that's immediately obvious, but over time with both phone platforms and on the web have been starting to learn that applications should not be able to change their behavior or monitor whether or not they are sandboxed. This closes an important hole in app security where application developers either change/block behavior, or try to "trick" users into granting unnecessary permissions. For a filesystem, an application should not be aware of whether it has access to every file, it shouldn't be aware of whether or not it's running on a temporary filesystem. And while it should be able to ask the user to grant it access to a directory, it should have no easily way of validating whether or not the user granted that permission -- it should just get a folder pointer back, regardless of whether that pointer is real, a different folder, or a virtual/temporary location. A lot of existing sandboxing doesn't follow this rule. The web is normally pretty good at sandboxing, but in this regard it's honestly pretty bad. We can't follow this ideal with everything, there are some permissions that are impossible to fake. But in general, we don't want to make things too easy for malicious developers. > If I want file access permissions on Android, I don’t just try to open a file with the Java File API and expect it to magically prompt the user. I have to call Android-specific APIs to request permissions first. iOS is the same. So why shouldn’t I be able to just call flatpak_request_permission(PERMISSION) and get a callback when the user approves or declines? In this regard, Android and iOS are wrong. Not as a matter of opinion, I will make a medium-to-high confidence claim that they are just flat-out approaching sandboxing security incorrectly. It's not their fault, I wouldn't have done a better job. This is something that we've become more aware of as we've seen how sandboxing has evolved, and as it's become more obvious how apps try to circumvent sandboxes. And this could be a longer conversation, yes there are tradeoffs, but the benefits of this approach far outweigh them, and I think in the future that more platforms (including iOS/Android) are likely to move towards seamless permissions that are hidden from applications themselves. Remember we sandbox applications in part because we don't trust developers. And while it's not the only reason for hiding user controls from apps, it is a good enough reason on its own. Don't give attackers unnecessary information if you can help it, this is security 101. And the author is right, this approach is genuinely more brittle because it requires building mocked/sandboxed API access rather than just throwing an error. But hey, sandboxing itself is more brittle. We deal with it for the UX/safety improvements. --- Second, for the reason that the author hints at: > Fedora is auto-converting all of their rpm apps to Flatpak. In order for this to work, they need the Flatpak permission system and Flatpak in general to require no app changes whatsoever. There are substantial advantages to having sandboxes that work with existing apps. This is always a give-and-take process, but in general we don't want to force updates of a large portion of user-facing apps. And we want them to be easy to get into Flatpak. The core libraries, user portals, distros themselves -- it is a pain to update them, but they have more eyes on them, they are more likely to be updated securely, and they have more resources available to them. I think it would be a mistake to shift that burden entirely onto application developers. Linux has a habit of doing this kind of thing sometimes, and it's a bad habit. We want Flatpak (or any sandboxing system) to be something that can be wrapped around applications without a lot of work. Ideally, a 3rd-party maintainer might even be able to bundle an app themselves. There is also a sort of future-proofing built into this, which is that there is no such thing as a sandboxing system that's secure from day 1. We've seen this pop up on the web, which (for all of its general criticism about expanding capabilities) still has a much smaller attack surface than most native apps. Web standard developers are very careful, but there are still breaking changes sometimes when new security measures/permissions need to be added. It would be very good if (as much as is possible), introducing additional new privileges and sandboxing capabilities to Flatpak did not require code updates for every single app using those capabilities that was built for an older version of Flatpak. If it's at all possible to avoid that scenario, avoiding it is the correct move to make. And finally, touching on burdens for maintainers again, different people may prefer different permission systems. If at all possible, we want to avoid forcing individual app developers to fragment their codebase and maintain different branches for different security sandboxes. Flatpak should run the "base" version of your app with little to no changes. This also benefits users, because fragmentation and forcing users to install multiple simultaneous sandboxes on their machine is heckin awful. So for all of those reasons, minimizing code changes for individual apps is a really good goal to have, even if it admittedly makes Flatpak more complicated and a bit harder on core platforms like GTK. ---- Other criticisms, whatever, I have some thoughts but it's not important for me to give them. But the sandboxing criticisms I see in this article betray (to me) a lack of understanding about what the current problems are with phone/web security and what the next "generation" of sandboxing problems are that we're going to face. And I think that Flatpak is at the very least approaching sandboxing through a more mature/modern lens than the one we were using X years ago in early smart phones.
• betwixthewires 5y ago
  So I love linux. Particularly, as a desktop system, I like Arch and derivatives of it, mainly for the pacman package manager and the Arch user repository. But I have trouble finding packages, and I hate to compile. So I use Debian instead. I would rather just use a distro that isn't ideal for me than start using flatpak and snap and all this other stuff. I really don't like how fragmented packaging is in the Linux world, but I will not use these prepackaged containers that have all dependencies included. They're worse.
• pdimitar 5y ago
  Flatpak very likely is not the future indeed but it seems like a good step towards it. Of all the arguments of the author I only agree with the RAM usage part. It's true that having containerized apps will lead to much more CPU L-cache trashing which can dramatically reduce performance if you are regularly starting and stopping programs. This is indeed a problem that needs solving. I can envision a NextFlatpak that keeps a global cache of versioned libraries (kind of like Apple does in macOS) so as to try and reduce RAM usage as much as possible. And I agree with the author on the startup time (which is also related to memory usage and CPU cache trashing). That too is a problem that needs solving. The rest of the arguments though, meh. Are you seriously arguing the case that we need to respect 120GB NVMe SSDs because they are "expensive"? Really? I spent 255 EUR (288 USD) on a 2TB NVMe SSD (and it has 3210 TBW of endurance, one of the very highest of all NVMe SSDs!) for a spare dev laptop and I am convinced most devs would have no trouble making that purchase any time they get the whim about it. And even people in my poor country, people who are mind-blown by their new 1300 EUR salary, can still plan financially well enough to afford a new iPhone 3-6 months later. So again, not convinced here. As much as NVMe SSDs are expensive per GB, they are still well within the grasp of most users who actually need them. As for security, it seems the author overstates the efforts of distro maintainers. They do an admirable job, this is well-known, but they really can't be everywhere so him praising them so much might be a bit misguided (as do other posters here). Flatpaks don't change the game in almost no measure there, especially if they get properly isolated (as another poster alluded to: I want to be able to stop all internet access to an app; just one example). And none of what the author states will stop a malicious app that's not in a container so really, what's his point there? That the Debian maintainers inspect 100% of all apps and will spot a malicious calculator? Come on now. And the rest of the post is just ranting and having a beef with a few things, which is clearly visible by his change of tone. Call me crazy but such an article can't be called convincing. ¯\_(ツ)_/¯
• compsciphd 5y ago
  All of these things aped by dissertation see: https://www.usenix.org/legacy/events/atc10/tech/full_papers/Potter.pdf https://www.usenix.org/legacy/events/atc10/tech/full_papers/... and http://www.usenix.org/events/lisa11/tech/full_papers/Potter.pdf http://www.usenix.org/events/lisa11/tech/full_papers/Potter.... what I did differently was basically say that it should be a linux distribution. each layer should be equivalent to a debian/redhat package, with full dependency information between them. therefore it be easy to a) create an image (just pick the highest level things you want and the rest get resolved automatically, much like calling yum/apt-get in a Dockerfile) b) upgrade an image when you want to (i.e. similiar to upgrading an existing redhat/debian system, it just creates a new image artifact that can be tested and deployed) you also don't have much hiding in the system as opposed to today. Yes, they might be built on debian, ubuntu or redhat, but you really can't verify easily what changes they made in the middle with ease. In my system, imagine there's a "Debian" layer repository, in general, you would end up with a bunch of easily verifiable debian layers and a small set of "user defined" layers (and when an image is deployed, the actual container layer). the user defined layers would be much harder to hide things in, i.e. it be very visible if one is overriding binaries or configuration files that you expect to come from a controlled package. considering the amount of language and implementation that docker seems to share with mine that predates it, one has to wonder if they saw my talks / read my papers (though yes, its very possible they came up with it totally independently as well). They were active in the usenix and lisa communities (at least when they were more alive).
• JohnFen 5y ago
  After giving flatpacks and the like a good, solid try, I have come to truly detest them. This article hits on most of the reasons why. If I can only get software in flatpack form, that software does not exist for me.
• phendrenad2 5y ago
  The future is Flatpak plus the heuristics Steam does to determine if something is a "core lib" (like LLVM, Mesa, etc.) that should be centralized rather than installed per-app. And then (and this is just me dreaming about a better future) the Linux world will eject all of the bad programmers and start maintaining backward compatibility, so you can just symlink libLLVM.so.5 to libLLVM.so.6 and it'll just work.
• Nasreddin_Hodja 5y ago
  That's true, future app distributions should utilize web 3.0, e.g. decentralization. There is 0install ( https://0install.net/ https://0install.net/ ), for example, it is better.
• Edwar 5y ago
  Thanks for sharing, I am very impressed with your post. https://www.garagebandapp.net/ https://www.garagebandapp.net/