Background-Story: I did a “flatpak update” on a remote client and every package wants the PW for downloading and for installing again. I had to enter the password like 30 times or more.
Background-Story: I did a “flatpak update” on a remote client and every package wants the PW for downloading and for installing again. I had to enter the password like 30 times or more.
I don’t know, I think it’s really far already. I can’t think of any big issues I’ve had. Biggest technical issue is KeepassXC talking to Firefox, if both are in flatpaks. But that has a working workaround and the issue is being worked on right now (I had a ton of emails since I seem to be following the issue on github lol).
That is a big one, inter process messaging securely.
The other one is memory deduplication. Uncontainerized libraries get code stored in memory once. When two applications use the same library, only library variables are duplicated, executable code is stored once.
When two flatpacks package the same library, they duplicate memory use. This is has to be addressed if we’re thinking of replacing regular packages altogether.
Ok, suppose we got over that technical jump and can share code memory among different flatpacks. What happens when one of them is updated and packs a newer version of the library? Can we use the newer version for both? Are we breaking compartmentalization by doing so? Or by the very sharing of it?
The concepts need to be worked out (a big hurdle), then implemented. At this point, are we departing too much for the concept that we’re essentially creating just another package format?
I don’t have these answers, but I think there’s a good chance the answer to those will limit flatpack (and competitors) application as the end-all, be-all package format.
Inter process messaging seems to be have quite some attention right now. I don’t think it’s very far now, if KeepassXC/Firefox issue I’m following is any indication.
Maybe I misunderstood you, but if they share the same library, the memory deduplication is already happening? I found this https://github.com/flatpak/flatpak/issues/4997
I’ve been running fairly low ram machines and I genuinely haven’t noticed any difference. Maybe I haven’t run enough of them at the same time and them having different (not shared) libraries. I wonder what the benchmarks are on this. I’ve only seen threads where people say it uses a bit more but no real comparison.
I’m not sure if that’s the direction. I think flatpak is specifically targeting GUI apps, with the “system” packages being traditional packages. And I think that’s a good solution, that way you’d have a tighter system layer that could even be immutable and you’d have a separate application layer, so they don’t mess with each other. Good for preventing breakage of the system if there’s somehing fucky with some app.
I think that deduplication ticket refers to library flatpacks. Like both flatpacks depend on a third one, and the contents of that third one will be loaded only once in memory.
I was taking about libraries packaged together with two apps. I don’t think the OS will know that two files located in different locations are actually the same and can be loaded only once in memory.
If that is solved, I’d be really glad to hear. Especially the decisions involved in handling multiple versions.
Whereas about how much of the system goes in flatpacks, once you’ve put your DE and apps on it, that’s like 80% of a typical desktop software load. There’s not much left and, like you said, the rest can be immutable. You may argue the DE is part of the base system, and I’d agree with you, but many people don’t.
Veering off topic for a bit… TBH it feels a little too much like Windows for my taste. When apps have a package maintainer, you can choose the level of stability you want and developers can focus on adding features / optimizing. When you remove that layer, the developers need to figure out how stable to keep their app to cater to most users, and if you are not comfortable with that, tough luck.
They do talk about how the library deduplication in memory is an OS feature and nothing to do with flatpak so it’s possible that the same library being shared might be dedupped whether it is in same runtime or not. But I don’t know. In any case, I guess extra RAM use is possible but I don’t think (from personal experience and reading up on it) that it’s very noticeable. Not to mention a lot of the used libraries do come with the runtimes, so that alleviates the issue if the dedupping isn’t happening.
I think the intention is to keep at least some parts of the DE outside of it, but the apps that make it as flatpaks. So for KDE I think it would be something like the shell, file indexer, “low level” stuff like that out and image viewer, media player, browser, “apps” like that in flatpaks. Which does break the DE up but makes sense to me, with “system” being separated from “apps”.
You could have “stable repos” for flatpaks, maintained by distros but I feel like it would take away some of the point of it (being to ease distro repo maintainer workload). Some devs will be happy that there’s no “meddling” distro maintainers, which is a complaint I’ve sometimes seen from devs. I think the idea that the apps come straight from the devs is both good and bad. Good in that it’s how the dev intended and updates are possible much quicker. Bad in that often the modification distros do serve a good purpose, of making the app better fit in to the whole or fixing stuff that misbehabes but for whatever reason hasn’t been fixed upstream.
Nothing further to add, I’d just like to thank you for the engaging discussion. Have a good one!