I don't understand what is the point of releasing an IDE via #flatpak, when that flatpak doesn't include all the necessary dev tools, and it can't access the ones outside its sandboxing. Honestly. What's the point? I'm looking at you, #Geany. Personall...

Alex L 🕊 🇵🇸

But, if in the future the host OS is deployed with OSTree and its content-addressable storage is in common with Flatpak's, a distro could hypothetically build the OSTree host images and the Flatpak apps/runtimes from the same (RPM) packages, resulting in zero duplication until the user install a third-party app from, for example, FlatHub, and even in that case only the strictly needed files would be duplicated.

Eugenia L

@gnomelibre @vwbusguy @wickedsmoke I usually install Linux for friends and family on old chromebooks that have 16 GB of storage. With Debian, one of the lighter ones, I get only 7 GB free after installation with XFce. I can't afford to install Flatpaks. Appimages are slightly smaller and in rare occasions that's ok. But .deb are much, much more better in this case. I just don't like the bloat of flatpaks, especially with only 50mbps internet in my area. Sorry, not a good alternative for me.

Scott Williams 🐧

@gnomelibre @wickedsmoke @eugenialoli That's the promise. Unfortunately, that's still situational. The zoom flatpak is currently still writing to ~/.zoom in addition to ~/.var/app, for example.

Flatseal can be helpful here if you want to more granular control, at the risk of breaking some features.

Combining flatpak with an immutable OS is great for security and stability in general, but the OP is right about IDEs. They're hit and miss with flatpak right now.

Scott Williams 🐧

@gnomelibre @wickedsmoke @eugenialoli It's possible to mix flatpak and toolbox to conjure up a working runtime, but it's a huge pain. I think when container-focused development got emphasized, people heard it as general dev tools. There's zero shame in installing an IDE from rpm-ostree or tarball if it's more practical than flatpak and then use distrobox etc when it's the right tool rather than trying to force a square peg into a round hole.

Scott Williams 🐧

@gnomelibre @wickedsmoke @eugenialoli That said, I use geany from flatpak on my Kinoite box and it works for me, but I've been using it for decades now and have gotten used to tweaking the compiler options due to containers or python venvs, so it doesn't feel any more cumbersome to me. I hear vscode users complaining about this more than anyone else.

Scott Williams 🐧

@alxlg @wickedsmoke @eugenialoli That's possible, to some extent. Flatpak uses libostree under the hood and Fedora has a flatpak repository included out of box in the distro if you want to go that route. The problem for IDEs in flatpak becomes when you need to access language specific compilers and libraries that you would normally just dnf install. Also, having distro specific runtimes in FlatHub would be an anti-pattern for the goal of cross distribution packaging.

Scott Williams 🐧

@eugenialoli @gnomelibre @wickedsmoke Yeah, with only 16G of storage, that totally makes sense. Flatpak definitely has a bigger upfront storage cost.

I would personally use rpm-ostree in that case (w/Fedora ostree). Deb totally makes sense for Debian.

Alex L 🕊 🇵🇸

@vwbusguy @wickedsmoke @eugenialoli

> The problem for IDEs in flatpak becomes when you need to access language specific compilers and libraries that you would normally just dnf install.

GNOME Builder integrates with Podman and to my knowledge VS Code can be configured to use containers too. I think this is the way: host OS ≠ dev env.

> Also, having distro specific runtimes in FlarHub would be an anti-pattern for the goal of cross distribution packaging.

Indeed, I was not suggesting that.

Scott Williams 🐧

@alxlg @wickedsmoke @eugenialoli Yes, vscode can be configured to use containers. Have you tried it? It's messy. It's also a significant barrier when you didn't need to use a container for something before. I'm not saying you can't, but it's far from a trivial workflow change.

Karl R

@alxlg
Yes, it's an extra step that I want nothing to do with as either a user or application developer. I fear that it will be used as a native package replacement for more programs over time.

@eugenialoli

Alex L 🕊 🇵🇸

@wickedsmoke @eugenialoli

They are different things that doesn't make sense to compare. Flatpak is a platform for third-party applications, while package managers are a way to assemble and configure an OS or other kinds of artifacts, like container images or Flatpak runtimes.

The point is that a distro can't package all the apps out there, if you think it is possible, do your best by maintaining as much packages as you can, because no volunteer owes you anything.

Alex L 🕊 🇵🇸

@vwbusguy @wickedsmoke @eugenialoli

Yes, I have tried, and yes, it is problematic.

Then what, we should give up and modify the OS to include packages needed for development, just because most IDEs don't integrate with containers yet?

In Windows and MacOS they don't do that and the Linux desktop approach would be crazy for them.

Karl R

@alxlg
FOSS is a software commons. The idea of a "third-party" is a business thing. Linux distros have been providing major applications in the OS repository which share common libraries and this has been a boon for users.

Flatpak, I suspect, is being put forward by RedHat to make it easier for corporate vendors to support Linux. Big business doesn't care how much storage & RAM is wasted - "Just deploy my app now!"

@eugenialoli

Karl R

@alxlg @eugenialoli @vwbusguy

IMO application developers and distro maintainers should be working more closely on packaging. A number of times I've had to poke Fedora to update packages which were years out of date. Upstream had fixed serious issues, but there seems to be no communication with maintainers.

Having a single package specification to be used on distro-specific services like Copr could help developers to do their own packaging.

Scott Williams 🐧

@alxlg @wickedsmoke @eugenialoli Again, I'm not saying you can't, but this is an area with a lot of opportunity for improvement in the experience of using flatpak. There are some things that reasonably should work out of box that don't currently. Another example is integrating KeePassXC to a browser when they're installed from flatpak. That's something that doesn't currently work out of box that should.

Alex L 🕊 🇵🇸

@vwbusguy @wickedsmoke @eugenialoli

Of course, I just wanted to say that Flatpak doesn't inherently mean more used storage and in general things need to be adapted to the new approach.

Alex L 🕊 🇵🇸

@wickedsmoke @eugenialoli @vwbusguy

It's volunteer work, you can't tell people what they should or shouldn't do with their free time.

And third-party software platforms are everywhere, including browser extensions, they're not a business thing.

Scott Williams 🐧

@alxlg @wickedsmoke @eugenialoli Users can and should do whatever they want to make their system work for them the way they like it. If someone wants to use rpm-ostree, they should use rpm-ostree. It's their system.

People who care about making flatpak better should pitch in to help make it better.

Scott Williams 🐧

@alxlg @wickedsmoke @eugenialoli It does initially mean more storage, because there is duplication of things that are already installed on the host when you install the necessary flatpak runtime. That hit is less the more you use flatpak since runtimes get re-used, but it definitely has an initial higher storage cost.

Scott Williams 🐧

@alxlg @wickedsmoke @eugenialoli As a Fedora package maintainer, someone poking us to update something is often a useful contribution to the process (when done respectfully). Because we're volunteers, it's easy for things to slip off our radar and knowing that an update would benefit someone in the community helps prioritize the work.