Red Hat Begins Talking Up The New RHEL Flatpak Runtime

[skierpage]

But as with docker containers or VM Images. You have to update each and every library/binary for security fixes etc. all the time.

But someone else is doing it for you for every library in the shared runtimes. My Flatpak apps currently use org,gnome.Platform/3.36 and org.kde.Platform/5.12 and both have both received multiple fixes. The runtimes seem to get rebuilt by professionals who know what they're doing, and I've yet to experience any breakage caused by a minor bump. That's true for the package wranglers for my distro (Fedora) as well.

The best feature of Flatpaks for me is when a developer wants to know if my bug occurs in git master of their program, I can install its nightly flatpak from a development flatpakrepo and check, without disturbing my normal version or having to build from source. https://wiki.gnome.org/Apps/Nightly and https://community.kde.org/Guidelines_and_HOWTOs/Flatpak

[starshipeleven]

I guess Flatseal is new to you.

Indeed. Does it allow me to limit storage access (as many apps are simply accessing the whole "home" folder) too?
I'll try it later.

[Alexmitter]

, but it's not exactly as user-friendly as I would have liked it (I would like something like Android permissions with a GUI and switches).

I guess Flatseal is new to you.

[Vistaus]

Bottomline I tend to like Flatpak as alternative to native - especially if some dependency chain can not be meet But usually I prefer native.

Couldn't agree more!

[starshipeleven]

Which is why AppImage bundles "just work" in contrast to the miriad of problems with broken flatpaks and snaps.

for the same distro they were created for/with.

Really, it's basically a folder and a chroot.

That was not the problem that solution was designed to tackle in the first place. Rather than portable and easy to use bundles that work across distributions, in the like of MacOS app bundles.

which are also unsafe bullshit that relies on closed ecosystem to be "safe".

But aside from There is no real difference between that and just making a distro-specific package (that is an archive) that contains all libs and stuff you need, so you don't need to care about where and what libraries the distro offers.

This is what most cross-distro applications do (dropbox, TeamViewer, Anydesk, all commercial VPN client applications for VPN services like NordVPN...)

And Ihaven't seen, heared or met any real person user that actually asked for runtime sandboxing

most real person users don't know what they are doing.

That said, Android does that with apps, runtime sandboxing.

The big pain everyone has in Linux is having to port and bundle to the Nth degree. And that is what AppImage solves.

So, can you explain why there are far more flatpaks and snaps available than there ever were Appimages?

[zoomblab]

and lacks any way to sandbox anything, and requires the package to fit the whole damn distro in it if you want to still be able to use the software in a different distro from where it was created on.

Gee I wonder why it never cached on.

Which is why AppImage bundles "just work" in contrast to the miriad of problems with broken flatpaks and snaps.

And you know what?

That was not the problem that solution was designed to tackle in the first place. Rather than portable and easy to use bundles that work across distributions, in the like of MacOS app bundles. And Ihaven't seen, heared or met any real person user that actually asked for runtime sandboxing - that is more like a nice to have. The big pain everyone has in Linux is having to port and bundle to the Nth degree. And that is what AppImage solves.

[Smurphy]

wow I just noticed, did you wake up from a coma (join date 2008, posts: 10)?

Linux distros won't switch from apt or dnf to using flatpaks, it's just that flatpak solves several cases not properly covered by the native package system, for example I'm using the flatpak handbrake app because the one in the Ubuntu repo is too old, though there are many other corner cases for flatpak.

*lol* Nope. Didn't wake up from a coma. I only didn't participate in forums in the past

You are right on dnf/flatpacks etc.
But as I work in the Enterprise env., I do see what they do with that... and security updates is the last thing they care about. Reason I don't like it.

[cl333r]

You are not wrong. But as with docker containers or VM Images. You have to update each and every library/binary for security fixes etc. all the time.
And - flatpak now is kind of package management in a package-manager installed system.

Sometimes, it just don't make sense to have it that way. The biggest advantage Linux systems had over Windows and Apple in the past were really the package managers who did a great Job. Now we will have to deal with more than one on the same system.

Question: Who in here create docker or EC2 images. And who in here make sure these get security updated on a regular base.

wow I just noticed, did you wake up from a coma (join date 2008, posts: 10)?

Linux distros won't switch from apt or dnf to using flatpaks, it's just that flatpak solves several cases not properly covered by the native package system, for example I'm using the flatpak handbrake app because the one in the Ubuntu repo is too old, though there are many other corner cases for flatpak.

[Smurphy]

Correct me if I'm wrong, but it seems to me flatpak has runtime(s) (e.g. from flathub) that can share libraries with other apps that need the same library and version.

If so, flatpak HDD space won't increase linearly with every new app like many windows apps/games do.

You are not wrong. But as with docker containers or VM Images. You have to update each and every library/binary for security fixes etc. all the time.
And - flatpak now is kind of package management in a package-manager installed system.

Sometimes, it just don't make sense to have it that way. The biggest advantage Linux systems had over Windows and Apple in the past were really the package managers who did a great Job. Now we will have to deal with more than one on the same system.

Question: Who in here create docker or EC2 images. And who in here make sure these get security updated on a regular base.

[mroche]

I hope that the videos are uploaded on Youtube soon so that those that missed it can catch up.

As for release cycles, I would suggest that the normal target is every 3 years, but this was missed for RHEL 8 because they wanted modularity and it needed to be developed into a form they could ship. Aiming for 3 years again is IMO a good thing.

Yeah, the 7->8 cycle was much longer than prior releases, which hover around the 3 year mark. I was fine with the wait for 8, though, as my industry is slow moving and I'm very much into the Modularity stuff. Looking forward to what happens in RHEL 9.

I'm hoping they post them soon, there were so many sessions and not enough time to attend them all! It was really nice to be able to interact with the Fedora community, they put together a really cool 3 day event. I highly recommend (because they're some of the ones I got to catch) the OKD 4 talk, Meet your FESCo, CentOS Stream: The Shared Space, and ELN: The New RHEL Pipeline. There's also a few talks on Fedora CoreOS, new tooling, and Neal gives one on BTRFS.

All the talks that should be available can be seen in the Hopin schedule: https://hopin.to/events/nest-with-fedora#schedule

Cheers,
Mike