I'm really frustrated with Flatpak. I thought it was going to be an exciting secure sandboxing solution, but found out the people running it just make terrible

I'm really frustrated with Flatpak. I thought it was going to be an exciting secure sandboxing solution, but found out the people running it just make terrible choices overall. Apps don't use their conventional names, so chromium ends up become org.chromium.Chromium & Visual Studio Code is com.visualstudio.code. They use fuse for mounts, which isn't necessary in modern Linux kernels that support nonroot overlays (think Podman). The whole point of sandboxing is to allow it to "hide" your real file system, and only mount what you need or permit access through D-Bus.. however, you'll find several apps that default to host access and access to all your /dev. They only provide a few device options as well... so, if you just want to give access to a webcam, well you have to provide all of /dev in most cases. Flatpak leaks all kinds of info about its sandbox too, so any app can easily determine its sandbox. If you want to setup custom mounts, for example to mount a specific host directory into a different sandbox directory, well you can't. It has to be a direct mapping from your host except it prevents you from mapping /etc/ directories. To work around this for sandboxed home directories, you can use a persistent directory mapping.. but now, you'll be trying to access your files in `~/.var/apps/org.chromium.Chromium/Downloads`. They also use a file forwarding concept, which doesn't work well when mixing arguments and files. For example, try using org.vim.Vim to pass arguments and open a file from the command line. Or, try editing system files with Flatpak where you need sudo or some privilege elevation. Why doesn't org.vim.Vim get aliased and work like regular vim? The typical solution suggested to fix anything is to add `org.freedesktop.Flatpak=talk` to the session bus, and use flatpak-spawn from within the sandbox. Many users do this not knowing the consequences. This is generally terrible advice as it will give any app in the sandbox complete host access. But what happens when you need access to host tools or native messaging apps from inside the Sandbox? Again, the top answers are to use flatpak-spawn. They have "SDK Extensions" for a few apps which are like binary dependencies, but many tools needed for things like Visual Studio Code just don't exist. Try using the Ansible extension in VS Code for example. Packaging them is a nightmare because they use a hodgepodge of tools/scripts inside a random GitHub repo to manually get all the Rust crates, node modules, python packages, etc. and add them to a nonstandard file inside your build manifest. It makes no sense why they never added this functionality to the builder itself. Development seems to be stalling. If you do build an app, good luck getting it on Flathub without some authoritarian mod telling you they don't like your app (see the Popcorn Time decision). Now, there are some good things. The build manifest is pretty neat. I like the idea of having a simple manifest to build apps that integrates with build tools, but the externals scripts it relies on makes it suck. Sandboxing isn't a unique concept. I can see an enthusiastic Rust/C/C++/Go/Typescript developer or developers doing the same thing 100x better. IMO sandboxed apps shouldn't even know they are sandboxed. Each app should have a clean environment and ideally you'd pick and choose what files/folders you want to give the app access to while it is running, and not let the app builder decide for you. Also, the user should pick and choose where to mount directories if they choose to do so.. not make ~/Documents mount to ~/Documents... what if I want to mount /mnt/dev/docs to ~/Documents. If you care about this stuff, then you may end up frustrated like me.