Why do some people dislike containerized applications so much

[Dirklangohr]

I’m curious, what do y’all think about Nix packages? I rarely see people talking about them when discussing containerization/sandboxing

[thefrog]

I don’t use containerized apps for the simple fact that I am old school and just use what I have been used to. I see a need for such things for certain circumstances however really don’t have one for myself.

I believe in choice and I believe each person should be able to make their own choice of what is for them and what is not.

[keybreak]

Are they containerized / sandboxed in any way though?
At least they were not last time i’ve checked…

[_mk]

similarly, I was curious about others’ opinion about LXC and systemd-nspawn as a way to containerise and sandbox applications…
Specifically, I was reading about it on ArchWiki right this morning, with wine as a use case in mind…the process truly looks a bit convoluted when involving XOrg/Wayland…on the other hand, apparently Bottles via flatpak allows a kind of easier approach when it comes to permissions.
So, imho, together with freedom and privacy - very relevant to me - it comes also implementation

[Dirklangohr]

At least they carry all their dependencies, so some of the Pro and Conta arguments for Flatpacks are valid too

[keybreak]

Oh i see…but that’s more about deployment / reproducibility, than sandboxing

Sounds great for what it is though

[Dirklangohr]

Mh, I kinda expected you to not like them after what you’ve said earlier

@keybreak

Outdated containers are risky because of known vulnerabilities, say you have 50 containers on your system that have same dependency with highest risk known vulnerability…In order to patch it - you need to update all of them, and it takes only 1 outdated container to make your system vulnerable.

For example this is true for anything shipping with their dependencies, right?

On the other hand they got some advantages, avoiding dependency hell for example. It should be easier for not-so-experienced users to work with them or even troubleshoot them (because all you need to do probably is downgrade this one package). And the Nix repos are even bigger than the AUR from what I’ve heard.

[keybreak]

I haven’t really used Nix, but from what i understand all the packages are maintained by NixOS team, so it’s that case:

@keybreak

Technically absolute most of that can be solved by individual distros packaging and securing containers themselves, to enjoy isolation and other small pros…but that beats the main pro of containers as they’re advertised which is - ease of maintaining compared to traditional packages, for distro devs

So they can fix such problem by updating all affected packages as fast as they can.

[Locutus]

Putting aside boxer’s BS as far as I’m concerned containered apps should only be used when the app is available no other way. I have 2 flatpaks, 3 appimages, 1 snap cause the particular apps can’t be found otherwise. That said in my opinion I’m not running Docker for apps I can install from any number of sources. Why would I add an addition install layer?

[Cphusion]

@Locutus

That said in my opinion I’m not running Docker for apps I can install from any number of sources. Why would I add an addition install layer?

Docker isn’t really meant for desktop applications but for server applications.

[boxer]

@Locutus

Putting aside boxer’s BS as far as I’m concerned

I think you need to calm down fast. If you can’t discuss a topic without your condescending crap then go fix your lawn or something.

Your opinion is NOT the answer to anything regarding flatpaks, snaps etc. It’s your personal choice to use them. I don’t use them at all and I will have my right NOT to use them. I don’t give you crap because of that. I defend your freedom of choice.

I just agree on most of the issues regarding sandboxed apps statet by the author of the article I linked.

[Cphusion]

@boxer

This article is nice reading explaining why I (and many others) don’t like sandboxed apps Flatpak,snap etc is not the future

It was an interesting read, thanks for sharing. I did come across a blog post that is response to the one you shared.

Response to “Flatpak Is Not the Future”

Although I find it hard to just take someones word for it because everyone has an opinion about something and it sometimes hard to know what is true and what isn’t because of the overflow of information that are available on the money topics on the web.

[ricklinux]

@thefrog

I don’t use containerized apps for the simple fact that I am old school and just use what I have been used to. I see a need for such things for certain circumstances however really don’t have one for myself.

I agree! Not interested in containerized apps. It’s like using apps from the Windows store. I’d rather install the full blown software from source.

[Cphusion]

@ricklinux

It’s like using apps from the Windows store.

I don’t see the comparison to the Window Store, you place your trust somewhere so it’s a matter of trust. If you run Windows and use the Windows store you place your trust in Microsoft, if you download a Windows installer/setup file from the developer’s website you place your trust in that developer. If you install a Linux distribution you place your trust in the developers of that distribution and if you decide to also use Flatpaks you place your trust in the maintainers of the packagers on Flathub.

[dalto]

I am not hard-core about is one way or the other. However, I think that there are both positives and negatives to containerized applications.

General container pros:

• For the most part, they “run anywhere”. Flatpaks and appimages run on most Linux distributions.
• It can allow you to run software that otherwise wouldn’t be compatible with your distro:
  • On a fast moving distro, this usually means the ability to run older software
  • On a slower moving distro, you can run newer software than would otherise be available
• They can be updated at any time and don’t need to be synchronized with the system updates

General container cons:

• Increased disk space requirements due to the way they are packaged(runtimes) and duplication
• Increased bandwidth utilization(A big deal if you have a limited, metered connection)
• You have no idea what is inside of them
  • They often contain outdated libraries with known bugs and vulnerabilities
  • This can create real security problems you have no way to manage the risk because it is hidden from you inside the container
• They aren’t updated along with the other packages in the system unless you use a special application or script to do that
• Containers generally move the responsibility of packaging from the distro packagers to the devs.
  • Distro packagers are usually specialists that adhere to distro standards that sometimes includes a review process
  • Being a developer doesn’t inherently mean that you understand the security or packaging implications of the decisions you make during that process

Appimage pros:

• There is nothing you need to install, you just download and run them as-is

Appimage cons:

• Keeping appimages updated can sometimes be a challenge
  • There is no centralized framework for distribution so there isn’t a universal way to check for updates
  • Some appimages check themselves for updates, some update automatically and others never update
• There is no obvious way to know who packaged them. Unless you are getting the appimage directly from the developer/publisher, I would be highly skeptical of appimages
• Integrating them into the system is often a manual process.
  • Often the filenames change with each update which means even your manual integrations can breakl
  • There is appimagelauncher but it creates as many problems as it solves

Flatpak pros:

• There is a centralized way to manage flatpaks
• Flatpaks are well supported by both CLI and GUI update utilities
• Flaptaks provide a degree of sandboxing and isolation from the rest of the system and each other

Flatpak cons:

• Flatpaks on flathub can be packaged by anyone and it isn’t obvious at a glance who is packaging them
  • Some are packaged by the publishers/dev and many are not
  • The only way to tell is to use the flathub website, using the verified mark
  • When they aren’t verified, you have to actually look to see who is committing to the sources
  • Some of the most popular flatpaks aren’t official in any way. i.e. Steam
• The sandboxing in flatpaks is of limited utility, the controls aren’t granular enough especially when it comes to device access
• Having flatpaks use the system theme can be a real challenge. At least on DEs that support theming beyond light and dark.
• The default permissions for flatpaks are set by the developer and sometimes involve minimal sandboxing
  • You should always review the permissions for a flatpak before running it

Snap pros:

• The snap store makes it much more clear who is packaging the application

Snap cons

• Snap has forced and intrusive telemetry so the privacy focused should stay away
• Snap sandboxing by itself is very basic, it relies on apparmor profiles
  • If you aren’t using apparmor with the right profiles in place you may have little protection in place
• Snaps often slow boot times
• Snaps create mounts for each snap which can make reviewing your mounts an annoying prospect

On an Arch-based distro, I try to stick to the repo and AUR using appimages/flatpaks on an exception basis only. I won’t use snaps.

[LDC]

It’s not like I want to avoid giving recognition to the awesome work made by flatpaks/snaps/appimages teams, they indeed solved a problem for many but, unfortunately, they created different ones.
I only use one flatpak, Photogimp. The moment anybody packages an AUR with that, I’ll uninstall the flatpak.

[keybreak]

There are some interesting updates i haven’t seen before:

• Space efficiency: Flatpak deduplicates libraries and other files used by multiple applications to save megabytes or even gigabytes worth of storage depending on the amount of applications installed.
• Delta updates: only changed files are downloaded for updates.

(c) https://docs.flatpak.org/en/latest/introduction.html#reasons-to-use-flatpak

[dalto]

@keybreak

There are some interesting updates i haven’t seen before:

Flatpak has done delta updates since very early on. In my experience though, it still leads to much larger updates.

Even with those things in place, you are still using a lot more disk space with flatpaks. This could be limited if you only used flatpaks such as endless does.

[dalto]

@Dirklangohr

I’m curious, what do y’all think about Nix packages? I rarely see people talking about them when discussing containerization/sandboxing

Nix packages aren’t containerized or sandboxed are they?

I thought that Nix worked by using an alternative filesystem structure that allows for multiple versions of a dependency to be installed. Those packages don’t contain their dependencies though, they still just reference them.

That is a method of avoiding dependency conflicts but it isn’t a container.

[d-air1]

I’m not necessarily against them. I just hate when we come up with a good idea in computing and then try to apply that to every aspect of computing. Just because it is good in some scenarios does not make it good in all scenarios.

For example: I recently tried out Fedora Silverblue and BlendOS. The idea is that you try not to layer packages on the system image. It has it’s own libraries and packages and for the rest you are expected to use flatpaks and toolbox / distrobox (a.k.a. yet another container). Now if flatpak does not have the app you want or it doesn’t work well, you move to a distrobox / toolbox. Now lets say you need an app or something from an arch distrobox container. It will download an arch container image and then you enter the container and download the app. This will of course download all of the dependencies used by this app.

What I quickly found was myself using three different containers. One for arch, fedora, and debian packages of software. Now I’ve got 5 full OS’s on my system. The system and its libraries and packages. The three containers with the libraries and packages of the their OS and what’s needed to make its apps work. Finally, flatpak and its runtimes. With all of these formats having trouble inter-operating with each other. Getting a flatpak or system package to work with an app or command line util that is located inside of an arch container while also respecting your theme, cursor icon, and other system settings is not worth the hassle.

Now you might say that I was using them wrong. At most you should have one container and use flatpaks, but what if the app or utility or the version of said utility is not in the container that you have. Well, you download another one.

Another thing I have a problem with is how people tout how well Android and IOS handle these things as if those two operating systems are somehow the epitome of computing. Since Android 10 you can’t even have a clipboard manager without going back to rooting your device. In the name of security of course.

Last year I bought a Samsung Galaxy Tablet S8 Ultra. Wondering if I could make it work as a laptop replacement. If you ever try this you will quickly find out just how hobbling of an experience this is. For example even using Samsung Dex, most apps don’t allow for any form of drag and drop. The only apps that support it are first party apps of the manufacturer you are buying from if they see fit. Like some samsung apps and some microsoft apps on their Surface Duo, and half of the time it doesn’t work correctly. You could see this if you visit the subreddits that are about these devices. (If you can still bring yourself to click a reddit link). Otherwise, you need to use the share menu. This only works if the apps you want to share to register themselves as accepting a certain file format. If it is not listed you can’t share to said app even if you know that it supports the file format that you are trying to share.

Now I know that some of this stuff about android has nothing to do with sandboxing. I’m simply pointing out that there is a lot of stuff that you expect to be able to do. That simply doesn’t work due to either design, security, sandboxing, or in most cases, all the above.

While I never expect some limtations of android such as not being able to switch the default keyboard in most areas to come to linux. There are documented and real world examples of the limitations of containerization and sandboxing that I feel are not being addressed in the scenarios that we are adapting them to.