Because Flatpak imposes some design choices that are... less than optimal for porting existing applications, and if you ask them to change maintainers will insist this is the way to go.
They have told users that if they want, for instance, Jetbrains IDEs to work, they should simply get a Job at Jetbrains and convince them to rewrite their entire IDE to support the flatpak model.[1]
This is the reason I avoid distros with Flathub enabled by default. Half the software on there is broken in some pretty subtantial way, and nobody at Flatpak or Flathub cares. They really need to realize they're not Apple, they simply can't tell everyone to do things their way and hope to build a working and reliable ecosystem.
They have the equivalent to snap's classic confinement, but it needs to be explicitly enabled every time you launch an app.
Seems like just allowing the user to specify 'unconfined' as an override. Then the user would just need to do that with flatseal. Alternatively, and with much more needless complication, some kind of fuse-mounted /bin directory that acts as a portal could be used. Point is there are solutions that don't require huge perversions of the Flatpak model and also don't require Jetbrains to rewrite everything.
Personally I like that the Linux Desktop community is finally starting to wake up to the idea of universal application distribution that doesn't require armies of unpaid third party maintainers, and while Flatpak is definitely not perfect it is, in my opinion, a huge step forward in that regard[0].
[0] Not that the idea is really that new, there have been many attempts at bringing sanity to Linux application distribution, many of them better (IMO), but they've just never really been embraced by the community the way Flatpak has.
You're under the impression that they can compromise here, when this is false. That's a misreading of that comment. The "compromise" used by snap is to just not have sandboxing at all. Mounting /bin fundamentally breaks the sandboxing, it's never going to work. The only other option is to change the entire OS to support this (and maybe the kernel too), and that's going to break everything even more. You'll have the same problem attempting to do this in docker.
The main mistake you're making is thinking that Flatpak imposed this design constraint, when really it's a fundamental property of the underlying OS, that sandboxing solutions are forced to work around. It's possible to fix this with a distribution built in a very specific way like NixOS where you can theoretically mount different systems together, but that comes with it own sets of problems and things that it breaks.
If you can't make it work, don't ship it. Please. In this instance, not only the Terminal is broken, but also large parts of code analysis, task running, compiling, testing... essentially all but the editor. And this experience is essentially universal. The next app I installed had sync support that didn't work because the sync working directory was unwritable.
It makes me want to rip out flatpak from every system I see.
IDEs usually expect/require access to all sorts of things on the host, things like vscode can be used to use remote container support on the host, etc. but it's still an area that needs improvement.
Personally I just layer my IDEs with ostree as a compromise.
They have told users that if they want, for instance, Jetbrains IDEs to work, they should simply get a Job at Jetbrains and convince them to rewrite their entire IDE to support the flatpak model.[1]
This is the reason I avoid distros with Flathub enabled by default. Half the software on there is broken in some pretty subtantial way, and nobody at Flatpak or Flathub cares. They really need to realize they're not Apple, they simply can't tell everyone to do things their way and hope to build a working and reliable ecosystem.
They have the equivalent to snap's classic confinement, but it needs to be explicitly enabled every time you launch an app.
[1]: https://github.com/flathub/com.jetbrains.IntelliJ-IDEA-Commu...