Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Dunno why people try to push app isolation on Linux desktop.
It'd be better and more comfortable to make task/workspace isolation easier. You have all your apps installed system wide as usual, and you isolate processes in sandbox per your current task.
Isolating individual apps and having to deal with permission prompts and protals, and persistence of permissions is uh, not very user friendly anyway.
Feels like this whole flatpak and similar mechanisms is more oriented on bringing in untrusted apps, rather than anything actually comfortable and useful as far as "work" isolation needs go.
by megous - > ... and you isolate processes in sandbox per your current task.
Oh is that all? If you start writing up the requirements to make that happen (without permission prompts and portals, right?), I think you'll find that would be even more difficult than app isolation and have even more backward compatibility issues.
by bronson - I use bubblewrap directly, never liked Flatpak.by regexorcist
- Same except for Steam. Hope this money revitalizes bubblewrap's development, it'd be nice to get proper signal handling cleanup up then merged (even util-linux's unshare has it, these days).
- I like the idea behind Flatpak and the ability to sandbox applications. What I don't understand is why they chose to lock the build process so tightly to Linux.
I'm currently on macOS, and while I can cross-compile applications, I can't actually bundle them as Flatpaks. For that, I need `flatpak-builder`, which is so deeply coupled to Linux itself that I don't think it can realistically run on other platforms.
Snaps have a similar issue with `snapcraft`. However, you can still build a snap manually with `mksquashfs`, whereas I haven't found an equivalent low-level option for Flatpak. I may be missing something, though, and I'm still looking.
- I do tend to agree that in an deal world it should be possible to cross-build flatpaks, but:
1. You can't then test the output to make sure it even works.
2. As a practical point, you could just do it in a VM
by yjftsjthsd-h - I'd rather they invested €500k in contributing to the maintenance of distribution packages so I don't need to deal with Flatpak (on Debian here).by sdcfgy
- So what? I would rather they made Flatpak better so we have unified gui app system.by omnimus
- Better money spent than on Omarchy.by kombine
- My trust in Flatpak diminished after installing the book reader Calibre and finding that despite the sandboxing Calibre was given blanket access to my drive. Apparently a quirk of the developer behind Calibre insisting upon it. No warnings or communication of the exception were given. All trust I had in Flatpak was eroded from that moment on. Curious about the podman options or similar. Having desktop apps in a container with selective access to system resources seems like it would be more secure and configurable if configured correctly. Flatpak as it stands seems to be a legacy solution to what should be a container and namespacing solution.by minimeow
- That’s what the kasmweb images on dockerhub are - desktop apps containerisedby jarym
- Had similar concerns about the default sandboxing, so had to use `--sandbox` with every app and then carefully engineer the permissions so the apps would actually work.
After reading about potential future problems with Flatpak on my distro, I decided to experiment more with Bubblewrap. It turned out to be surprisingly easy to build a minimal container manager around it (here comes the shameless self-plug): https://github.com/pakstak/pakstak
Although for desktop apps, it is not as easy as just packing an app into an OCI container and expecting it to work. Since you are basically building on top of the kernel, which brings true portability between distros, you have to provide the userspace part of the drivers, and this layer depends on your hardware. Overlaying an app container on top of a "driver container" can help with this though.
by nmsv - > No warnings or communication of the exception were given. All trust I had in Flatpak was eroded from that moment on
This is just wrong. Clients like the flathub website or gnome software show the risk posed by wide ranging access to local files, but Flatpak has to support legacy applications that don't use portals yet and thus they can't block applications having those permissions
https://flathub.org/en-GB/apps/com.calibre_ebook.calibre
> calibre is potentially unsafe
> Full file system read/write access
> Can read and write all data on the file system
by preisschild - Don't know how you installed it, but required permissions are usually shown and warned about. The CLI could be clearer, though, but shows that host filesystem access is granted to calibre when it prompts to installby kalaksi
- The Soverign Tech Agency are currently hiring for a Director of Technology. Definitely a dream job for someone. https://www.sovereign.tech/jobs/director-of-technologyby robin_reala
- "Director of Technology (all genders)"
I guess I hadn't looked at German want ads ever. Is mentioning the gender as the most important qualification - literally in the headline - standard practice?
Also I guess Berlin is cheaper but seeing 99.5k EUR as the upper bound salary for a director role is a bit jarring.
I guess it's just the "otherness" of it but the DEI statement is shaped oddly to an American eye too. Please tell us if you are black or disabled but not if you are old or married.
by xyzelement - I avoid flatpaks and snaps as much as I can.
Here is a little blog post from 2021 that lists some of the huge issues flatpaks have https://ludocode.com/blog/flatpak-is-not-the-future
If you want to sandbox your programs highly recommend looking at firejail.
- I loved Flatpak until I started building a MiniPC with a 112 GB internal disk for HTPC usage... Then I felt the pain of having to get all slightly different dependency versions for each little program I wanted.
The box' cost already topped the project's budget so no new disk for it. I'm back to "proper .deb packaging please"
by j1elo - Use cases naturally differ, but I'd much rather use more storage than hit yet another unresolvable dependency issue.by Anonyneko
- I never understood why a program installed in Flatpak is not just a directory on disk.
When you install something via Flatpak, it still changes data in god-knows-what places on my disk. And the software itself has read/write access to god-knows-where on my disk.
The answer is probably "convenience and efficiency". But I would much prefer a "An application is a directory and by default cannot access anything outside of that directory" approach.
by TekMol - I think most people making a good ol' desktop program these days do it because they need very liberal access to the filesystem, or access to weird hardware peripherals. If they don't need either they could just put their app on the web!
Looking at the top apps on Mint's "app store" shows this trend too, everything is an editor of sorts (code editors, photo editors, video editors, audio editors, painting, modelling etc.)
by 654wak654 - Tech debt, primarily. Flatpak is designed to be able to package apps not designed with it in mind.
If neither compatibility nor resources are of concern then integrating true Mandatory Access Control into both the UX and the entire tech stack would be the best way forward.
by lunar_rover - As everyone else has written, two very different things are being mentioned n your last paragraph:
First, the application should be just a directory on disk. I wholeheartedly agree, this should be the way to install applications, and OSX has shown that this works wonders.
Second: it being limited to only read and write files in that directory. No, that's the wrong idea, the application should be associated with some extensions and should be able to edit documents in your Documents directory. It makes no sense otherwise.
by Shorel - I'd prefer that too. Preferrably with permission popups for requesting folder access outside of it. Shared libraries / whatever flatpak calls them could live at a central symlinked location?by schmorptron
- Same prefer, although I'm not sure what you mean by "installing changes data in places on my disk"?
Nothing should change, all installations and addons go to the ~/.var directory. When you launch the application, yes it can start reading and writing to arbitrary places on disk, which is why I make it a habit of first launching Flatseal to modify permissions and know exactly what it can and can't do and reach.
I actually vastly prefer this methodology with what we have right now, but if it or something else adopted an application/directory methodology as you described I'd be elated.
- Isn't that exactly how it's supposed to work, though? When I install a flatpak app for my user, it gets put into a standard location as a directory and by default has no access to filesystem other than the apps own config and data dirs (can't remember the paths). The fact that many apps choose to require excess permissions and can then bypass standard locations is a different matterby kalaksi
- > But I would much prefer a "An application is a directory and by default cannot access anything outside of that directory" approach.
That makes sense if the application is the only program that needs to interact with the data. For example: If you have a drawing or photo editing program. You might have downloaded an image from the internet or from your camera. Then you make some edits. Afterwards you want to send the image to someone else via e-mail, which is another program.
by vaylian - By default, software has a sandboxed location that is exposed to the host in `~/.var/app/[APP]`.
Most software needs access to user files. Since most applications aren't written with Flatpak in mind, they will attempt to load files using their own file browser, meaning that for the application to function at all it needs to have access to swaths of extra data. You can see what data the application can access either via FlatSeal or in whatever "app store" you're using. Often it'll be your entire home directory.
The software that is designed with Flatpak in mind will use XDG Desktop Portals, where the host displays a file browser and then hooks it up to the sandboxed app so it has access only to that file or directory.
Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to this file. Allow/Deny" because the program doesn't know if this file exists, and the user wouldn't be able to navigate to it via the program's bespoke file browser since it doesn't have access to directories or their contents.
by pinkwah - I’m thankful for the STF. Germany is one of the few countries doing something. But it is not strategic software-development.
The how planet needs Linux, BSD, cURL, ffmpeg, Flatpak. We need to ensure that this work for the people.* They don’t employ software-developers. No safety for the developers. No control over developers. * It is only temporary. * The projects need to apply repeatingly for funding. Wasting time and resources and chausing worries.We feed for 30 years constantly money into monopolies. We shall feed the next century constantly money into things the people need.
Many developers of Linux and GCC are paid. Because companies decided it is necessary.
by ho_schi - We do all this self-congratulation around funding OSS companies and then end up with OSS companies that exist only thanks to government subsidization. Why? Isn’t governmental control over funding what we hate about Microsoft? What is so bad about letting real customers decide which companies need funding?by jimbob45