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.

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.

OP might want to edit this.

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.

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!

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.

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.

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.

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

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.

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.

No, you just trigger the download on install to get the 15th version of the runtime

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.

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.

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.

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?

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.

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.

Oh no we're all doomed.

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.

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. ¯\_(ツ)_/¯

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)

>Note that the app package itself is only 4.4 MB.

Calc 98 is huge at 495 KB:

http://www.calculator.org/download.html

Xcalc (RPN) is around 200-240 KB:

http://www.tordivel.no/xcalc/

Is anyone here distributing a commercial Qt/C++ app on Linux? Are you using Flatpak or something else?

see: https://www.usenix.org/legacy/events/atc10/tech/full_papers/... and 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).

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.

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.

What about the gargantuan WinSXS folder?

I think, something like Appimages are the better fitting equivalent to Window's normalized madness, no?

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.

For example, rust's cargo can compile and install applications into `~/.local`, but it's pain to keep them up to date, so I prefer to use same tools from my OS (Fedora) distribution repo instead.

And parts of the industry are beginning to move back and favor stability, as a result of

- numerous NPM packages being taken over by coin miners and other malware - at the scale of some of them, even a ten minute takeover window were millions of installs, and source chain audits are almost impossible

- framework churn being an actual liability for large enterprises - many were burned when AngularJS fell out of love and now they were stuck with a tech stack widely considered "out of date". Most new projects these days seem to be ReactJS where Facebook's heavy involvement promises at least some long term support

- developer / tooling churn - same as above, the constant amount of training to keep up with breaking changes may be tolerable at startup, money-burn phase, but once your company achieves a certain size it becomes untenable

You can get the same behavior on Linux by linking with -Wl,-rpath,\$ORIGIN (minus the PATH env var, use LD_LIBRARY_PATH for that).

All I was saying is that if a new package manager addresses all of the issues scripting languages had, scripting languages would still use their own package managers. Because the culture is now set, even new scripting languages would write their own package managers.

I think "largest" is quite an exaggeration since historically scripting languages packaging has been rather terrible on Windows. While Windows was a consideration for languages like Python (I've read they avoided Make because of Windows), for me cygwin always coming up along with it until recently.

That would provide no benefits.

> Not to mention that container images are still mostly built by using regular packages

Yes, and because of the bundling they are a security disaster, as proven by many researchers:

e.g. https://www.infoq.com/news/2020/12/dockerhub-image-vulnerabi... https://www.darkreading.com/threat-intelligence/malicious-or...

Ok, say a wild CVE appears and it says libblip versions 1.3 through 2.0.4 have a severity-10 RCE vulnerability and should be patched ASAP. If the container images and flatpaks are not opaque, I presume you have a simple command that lists all vulnerable library versions that are present on all the machines you administer? And, subsequently, that you have an easy procedure to patch them all?

I don't understand what you mean here. Do you think that the Debian is not trying to provide a full OS, they are just curating a set of popular packages?

I think this is patently false, as most distributions typically take clear decisions to standardize and maintain particular OS components, such as choosing a particular libc (glibc in most distros, musl in Alpine), choosing a particular init system (systemd vs System V), particular network management demon etc.

However, instead of taking additional time to create and commit to a backwards compatible Debian SDK, Alpine SDK etc, they then package all of these OS components the same way they package popular software.

> As opposed to what?

Opposed to distributions providing targeted updates to each package.

> Dynamic linking does not solve this problem, contrary to popular belief.

On the contrary it provably works very well for distributions.

>>- Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have to maintain yourself.

>Again, as opposed to what?

Opposed to distributions that do the huge work of packaging, testing, backporting etc.

>>- Licensing issues: distros review licenses (and find plenty of copyright violations while doing so). A flatpak puts you or your company at risk.

>Sounds like a good way for a proprietary software to be distributed...

This is unrelated to the lack of licensing review.

>>- Impact on the ecosystem: the more users switch to opaque blobs the less testing and review is done for proper packages. The whole ecosystem become more vulnerable to supply chain attacks.

>I don't see how one follows the other.

Supply chain attacks are strongly mitigated by maintainers doing vetting and packaging, and by distribution doing release freezing.

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.

I'd be genuinely surprised if distributions like Fedora still use, or actively maintain, RPMs for any GUI software after a few years.

Does that mean I'll download one copy of libThatWasUpdated for every app that uses it?

Seems like this is exactly like iOS and Android work. I see the appeal (they are definitely more secure against malicious apps than Linux with apt-get), but the waste of space still bothers me. Docker has the same issue, and didn't really solve it with its layered filesystem (you always need several dependencies, but you can't merge images, so you'll need to install a new copy of some of them).

These packages also make it hard to audit the versions of security-critical code installed on my system. It's good that they can be updated separately by the OS, but at least when apt-get was upgrading shared libraries, I could be sure that all programs had the fix. Now I'll need to go dive into each package to know if it should be allowed to run, or if I should wait for the upgrade.

Flatpak/snap is somewhere in between where on the main repos (eg. flathub.org) anyone can publish a package for anything without being affiliated with upstream. It incentivizes users to just search for the app name and download whatever comes up as a result. That's a pattern we've known to be broken for years: from Windows users downloading the first link Google suggests (usually a sponsored link bundled with spyware/adware) to Android users downloading anything the Play Store suggests (usually spyware, see how many flashlight apps there are and what permissions they require). F-Droid in the Android ecosystem strikes a balance because there is strong community vetting for all packages published, so it's like a distro-agnostic repository following the distro packaging threat model.

I believe there are ways to mitigate those issues (eg. namespace enforcement on flatpak) but i don't think downplaying them is doing any good.

To make things worse, Flathub changed the way they display "Publisher" field for a flatpak. Which says whether a package was published by Flathub maintainers, Upstream developer or somebody else in Flathub. Now instead of saying who, they just say a "See details" link under Publisher field in flathub.org for a flatpak. That link which in turn directs me to a github page and I am still unsure who the hell uploaded that flatpak.

Before, they used to say Upstream developer's name or say "Flathub maintainers" which means Flathub team uploaded the flatpak making it easier verify who uploaded the flatpak. But now it is making it more difficult. This has been the most pissing thing about Flatpak other than the security issues and problems which keeps coming up about Flathub every now and then. Why would you change something that is so crucial when it is working?

Cos now, I could package a software which is not in Flathub and it would just say "See details" instead of my name. This provides the illusion of trust. Cos if it were to show my name there, more people would've been like.. who the hell is this guy and do a check on me (I used to do that). But now, If I could slip through Flathub checks and provide malicious flatpak, majority of the folks will still install cos most of them are using Flatpak for convenience. Not security and performance.

Want proof? Just scroll up and you will see someone saying he don't care even though agrees to the things in the blog post. He just don't care. :shrug:

On Windows, there is a very clear solution: for any 3rd party you need outside the Windows SDK, you bundle it into the MSI installer you distribute. When installing the MSI, it can check if this particular 3rd party is already installed, and avoid it.

I don't think I've seen anything like the manual instructions you discuss for more than 10 years. Even OSS projects typically ship with simple installers today.

I believe, but have not tried it personally so may well be wrong, that similar mechanisms are common on MacOS with App packages.

[1] https://news.ycombinator.com/item?id=28978086

In NixOS the whole system works this way, so there aren't really any global system libraries, except for the graphics system.

Aaaand folks who live in the Apple universe have been accustomed to accept that they are holding it wrong, and that there's someone whose job is to figure out what's the official best way to do things. If it involves downloading 130 megs it's 130 megs. No problem. The UX and end result is worth it for them.

"Flatpak: Linux application sandboxing and distribution framework " [0]

"It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system." [1]

The whole point of a sandboxing environment is that you can run applications that do not want to be sandboxed. The flatpack proposition is directly contradictory with this basic requirement, in that it requires the application to be flatpacked to begin with.

[0] https://github.com/flatpak/flatpak

[1] https://en.wikipedia.org/wiki/Flatpak

Snaps use portals like flatpaks do. The problem is more about frameworks you build applications with not being ready to consume portals. Turns out only some reasonably recent Qt versions can work with portals. IIRC Electron only landed support couple of months ago. Back on the host side of confinement, you need to run a reasonably recent xdg-desktop-portal (and a maching GUI integration bit). Some old distros do not provide any of those packages or ship version that don't work, so things are DOA.

As opposed to today, where app developers definitely don't just tell users to run:

  sudo apt-key <name> --keyserver hkp://<X>:80 --recv <X>
  sudo add-apt-repository 'deb [arch=amd64] https://<X> multiverse'

  sudo apt install ./mydownloadedpackage.deb

----

As far as I can tell, the parts of distribution that Flatpak makes easier aren't the literal distribution parts. Yes, they make it so you need to create fewer bundles (just Flatpak instead of deb, rpm, etc...). But they're more about the containerization than the distribution, if all you care about is distributing Debian packages outside of the official repos, that isn't necessarily that hard of a problem. I think you can even host a custom package source on a static site through Github pages, you don't even have to pay for the server.

The big change here is that you don't need to share dependencies, but importantly, you already didn't have to share dependencies, Linux apps could already embed unsupported system dependencies that they wanted to use, and many of them (particularly games) already did.

This makes that process easier, which you may view as a negative, but another benefit of that is that easy linking with Flatpak runtimes means applications are more likely to link to those libraries in a more inspectable way, and it's easier to at least audit the applications that were already bundling these dependencies before.

For example, you mentioned Signal. I stopped using the Flatpak because of this: https://github.com/flathub/org.signal.Signal/issues/181

(There's also a docker image, a macOS DMG, a Windows installer, and other editions as well--and yes, you can configure any edition to _not_ upgrade automatically if you prefer).

RedHat did not create libcontainer and it was never rewritten to go (it was always go). libcontainer was started by Michael Crosby at Docker as a replacement to execing out to (at the time unstable) LXC, later donated to OCI (not CNCF) as a piece of tooling called "runc", which is still in use today. As part of OCI RedHat and others have certainly contributed to its development. libcontainer lives in runc, and is actively discouraged to use directly because go is really quite bad at this case (primarily due to no control of real threads), and runc's exec API is the stable API here. Side note: much of runc is written in C and imported as cgo and initialized before the go runtime has spun up. That is not to say libcontainer is bad, just that it is considered an internal api for runc.

RedHat did end up creating an alternative to runc called "crun", which is essentially runc in C with the goal of being smaller and faster.

-- edit to add more context on development in OCI

In general, when there are is some useful and commonly used C SDK , common FFI wrappers in any language quickly appear and become popular.

It isn't some fantastic never-seen-before concept, it is how applications on Windows can use new APIs from Windows 11 while still running on Windows XP or how OpenGL programs can use APIs from OpenGL 4.6 while being able to run on drivers that only expose OpenGL 3.1.

As a user, I'd like to give Krita/Libreoffice permissions for ~/Documents and Tor Browser permissions for ~/Downloads. I don't know yet of a user-friendly method to achieve that.

For instance I always do `python3 -m pip install --user wormhole` or `pip install --user wormhole` instead of sudoing my way to permissions hell. Python apps get installed in $HOME/.local/bin, so no cruft for other users.

But stuff installed with deb packages often have hard coded pathways and assumptions of where and how their files are run.

So I think it's fair to ask in reply to someone implying that `dpkg --root=$HOME -i mypackage.deb` is as clean/same as a flatpack behaviour "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!"... It's fair to ask "where do those files in the deb package go ?" because if it works as implied (no pollution of the OS) I am certainly going to start testing installing things that way.

To be honest, i don't care much about how programs look. But i do know many people do care.

For example Ubuntu is trying very hard to push snaps. In contrast to flatpaks only they can run the store for it so there's clearly a motivation of vendor lock-in.

This kind of thing makes me suspicious and more critical of new tech. I'd first want to see if it offers me any value. In this case I don't see the big benefit even though flatpak doesn't seem to carry the lock-in that snap does. But I like the optimisation of dynamic libraries and the way I can update openssl once and have all the apps patched that use it.

Systemd is a different story. It's open enough but a bit too heavy and complex for my liking. It's not bad though and I use it on some of my boxes. Alpine is working on an alternative based on s6 and I'll probably end up using that when it matures.

Anyway I didn't choose Linux/BSD because I cared about having the same as everyone else :) Being able to deviate from the beaten track is one of the benefits of these. I currently use FreeBSD because it has the least corporate meddling right now.

> From what I have seen, most of the opposition to Flatpak comes from the same place that the one to systemd: fear of change.

This is what pisses me off. You, nor anyone else, can tell everyone else what >I< think or feel. It's not fear, nor fear of change, nor any other dumb ass reason people who think like you think it is. I hate it because it's just a package manager. I hate it because, when all the reasons against it are brought up, something nebulous like "security" or something quazi-psychological like "fear of change" are brought up in defense of it.

The real problem with flatpacks is that they don't solve the real problem, and they do it poorly.

Want to solve the problem of your program not running on multiple distros, or not running in 5 years ? Then look at why that is. For example; it's not that the zip file format will change, so why must i recompile my program every time libzip changes ? Or X11 to wayland transition; why does my program have to even care about that when all i want is a window and an opengl context ? (bdw the solution to the latter is SDL2)

Let's look back when flatpack started. Why did it start ? Maybe because GTK3 changed it's API ever so often ?

Linux doesn't have a good GUI toolkit. THAT is the biggest problem here.

I just fucking hate the "ohh, you just don't like change" people. That dismisses all further discussion. That is the real "hate" that people like you blame others of.

A working system calls for a conservative viewpoint. I'm only looking to introduce change if my needs aren't being met.

A lot of the vocal people who pick linux are people who want complete control over their systems. Things like wayland, systemd, and flatpak take away some of that control.

Systemd was such an improvement over the existing speghetti for folks selling / supporting linux that it was a pretty clear takeoff.

Flatpack seems a bit more focused than snaps. The usability issues with snaps kind of surprising given ubuntu has usually had a good user focus. One thing, Fedora has their silverblue / ostree type distribution initiative, which may reduce their use case for using things like flatpack for printer subsystems etc (snaps seem more flexible). I moved off linux desktop a year ago though so not at all current unfortunatly.

Which I am, but this is besides the point.

> There are a metric ton of holes to plug in the Linux security model, Linux security is a dumpster fire.

Please don't spread FUD. Perfection does not exist in this world but Linux is used in most security critical environments in the world, from banks to military applications to security devices like firewalls.

> But... run Wayland, use Flatpak (and check your permissions), check file access/network access -- these are steps in the right direction, they are security improvements over apt-get.

Sandboxing and installation tools like apt-get are completely orthogonal topics. Flatpak blurs the line and people get confused.

Furthermore, sandboxing can be effective only if the whole UX is designed and tested centrally.

Applications need access files in ways that are compatible with each other and useful for the end users.

Policies need to be written and reviewed by a trusted organization.

You can't rely or random upstream authors to configure sandboxes for different applications independently from each other.

Sample the sandbox settings on some flatpak applications and you'll find they range from too strict to completely lax.

> Android/iOS's model of app isolation is unambiguously more secure than an apt-get free-for-all

And yet the phones are full of spyware/telemetries antifeatures.

> I would not today assume that Flatpak is secure or battle-tested

It's not.

Flatpak aware apps (like the ones I develop, or any on elementary OS since flatpak is the native packaging format there) tend to just work.

Windows backcompat isn't perfect, true, but largely the stories of where it fails are exceptions to the rule. Where as you can't even have backward compatibility in a Linux Desktop with applications compiled for the previous version of the same distribution in many cases.

You shouldn't need to trust either. Just the sandboxing system of your OS.

Yes, and very big: Debian maintainers need to build a reputation for years to gain upload rights, meet in person, sign keys, and the packages are peer reviewed my multiple persons.

Plus, packages spend time in release freeze being tested by a large userbase before a distro is released.

It is an issue if you want to compile new programs on a new distro that can run on older distros, but IMO that is much less of a problem than not being able to run older programs in newer distros. And there are workarounds for that anyway, though none of them are trivial.

Did you not read the last line? You are free to do whatever change you want.

You are also free to use a distribution as it is without having to spend your time handling security, stability and compatibility across applications all by yourself.

Yet you cannot mash together a frankenstein OS while also expecting it to provide security and stability. Not because of a distribution decision but because of reality.

ORLY? What's Kurt Roeckx[0] up to these days? Oh right, he's the Debian Project secretary, despite famously crippling RNG in OpenSSL.

> Developer wishes are developer wishes. User wishes are more important.

You mean like the wish to get up to date software directly from the developer without waiting for some third-party middleman to get around to updating the repo?

> You can use any distribution developed by developers (do you know any?) if you dislike maintained distributions and share experience with us.

Such a beast doesn't seem to exist in the Linux world, so I just don't use Linux. Linux Desktop's abysmally low market share may or may not be related.

[0] To be fair to Kurt, he wasn't the only one who didn't see a problem removing those lines and he did ask around first. It is an understandable mistake and I don't mean to crucify him.

Debian did this, they said oops and moved on. Packagers suck as developers, they apply patches they don't fully understand to solve problems they don't understand on codebases they don't understand.

The REAL problem is libraries breaking their ABIs, not Linux itself.

As you probably know, there is no policy, and no "Linux Desktop" either. You've got Linux distribution releases that are supported for up to 10 years (like RHEL and Ubuntu LTS) by teams a couple of orders of magnitude smaller than either of MacOS or Windows. They usually get HWE kernel updates too (hardware enablement) from newer Linux series. By definition, they maintain ABI backwards compatibility for the duration of their support. If you care about it, that's what you should use.

But it's in the nature of free software world to want to mix and match, so the idea of a singular Linux Desktop does not exist. You should treat each one of them as a separate OS, which is unfortunate, but realistic. Flatpak/snapcraft recognise that to a point (packaging up everything but the kernel, regardless of the system packages already installed).

Of course, not "frozen" like TeX, but seeing active feature development too.