Red Hat Begins Talking Up The New RHEL Flatpak Runtime

[Jabberwocky]

I have found the idea of Flatpak very useful over the past 3 years. It has helped me to install software on my distro quickly and removing software without breaking other things or leaving too many things behind.

I have many problems with the implementation form trusting apps, to false sense of security, to broken apps VS Code's additional runtimes and broken screen sharing. On the one side these problems can be solved, on the other side I keep asking myself: should it be solved in this way?

I've been wondering if it would help to split Flatpak into components and support/implement awesome existing software like Firejail.

Flatpak just for dependency management is useful in the short term, but ultimately a waste of resources IMO. Flatpak for dependency management, portability and proper sandboxing is something I would find useful in the long term.

If all those idiot library developers understood that backwards compatibility is paramount

Linus pretty much said the same thing many years ago, but Linus is just some guy who like to complain (sarcastic).

Flatpak/Snap is a bandaid not a cure. The cure is for userland to provide backwards compatibility like the kernel does.

The code is already there. You don't even have to fix security issues with the old one: since new apps will use the new interface, and people using flatpaks WOULD USE THE OLD LIBRARIES ANYWAY full of security issues. There's no difference.

It's ironic, because depending on your distro this is the other way around. Same for proprietary software like slack or discord. I've found flatpak images that used newer libraries than Ubuntu's or Centos' native package-manager had.

[zxy_thf]

One funny thing is, there are a lot of comments here showing their commenters have ZERO experience in porting one application from one distro to another.

Common myths include:
1. "App xxx solved this problem decades ago"
Yes, by bundling everything and thus created a VERY bloated package.
It's so ironic to see people who were constantly blaming bloated Windows applications suddenly feel it's totally fine to have bloated Linux apps.

2. "Static linking blablabla"
Also created bloated package, and to make it worse you can't replace a broken/buggy library bundled inside the application.

[starshipeleven]

If all those idiot library developers understood that backwards compatibility is paramount, like Microsoft or Intel (into their very own CPUs) have.

It's not dynamic libraries, they are perfectly fine, it's the morons designing them.

I don't know why it's so hard for them to follow some simple rules.

It's usually a money/time problem. Developers making most of the libraries don't have the same level of funding and manpower that Microsoft has. And even MS drops or changes functions. They are just slower.

First of all, if you ever bump the soname, keep the old version around forever.

THis works only if the function is a one-liner or such.
For anything serious that is also relying on other internal functions or logic, this leads to massive bloating of the codebase and it would quickly become unmaintainable mess like Xorg where you still have 100% (theoretical) support for the old X protocol so (theoretically) an application speaking that protocol should work, but in practice none has ever tested this in the last 20 years because the applications now all use a subset of it, so most of that stuff is probably horribly broken.

This is one of the reasons why most commercial software where retrocompatibility is strongly enforced becomes a horrible cesspool of madness in 5-10 years. Code that was left untouched 5 years ago and none understands it or why it was created, stuff that should work but relies on other stuff that was reworked in an incompatible way and none had proper automated testing to detect that, and so on.

The code is already there. You don't even have to fix security issues with the old one: since new apps will use the new interface, and people using flatpaks WOULD USE THE OLD LIBRARIES ANYWAY full of security issues. There's no difference.

Sorry? If people can just use the old libs anyway what's the point of keeping around old versions of the API inside each library forever. Just use the lib at the right version.

Really, the only thing that makes sense, given the limitations of opensource world is a way to bundle libraries with the application in a more or less static way, and run it in a sandbox so that any bs is contained.

[starshipeleven]

It's so ironic to see people who were constantly blaming bloated Windows applications suddenly feel it's totally fine to have bloated Linux apps.

To me, flatpak is more of a way to distribute commercial applications, where you have a craptacular codebase and the people doing the porting may or may not be Linux wizards themselves so you can't expect them to do a great job at supporting 5-8 different distros.

So the bloat in this case is acceptable because I'm not going to have more than 3-4 of these applications to begin with, or it's only temporary (i.e. like the old "download random tool from the internet to solve current problem" from Windows).

While most of the opensource applications can still be packaged and shipped by the distro, without the need of flatpak.

[starshipeleven]

I've been wondering if it would help to split Flatpak into components and support/implement awesome existing software like Firejail.

Firejail is basically a "standalone Flatpak's sandbox", as they both offload to SELinux or APParmor (depending on what you have installed) and cgroups linux kernel functionality.

Imho the main Flatpak's problem is that the security profile (i.e. how stringent is the sandbox) is defined in the application manifest, and many application manifests don't really set stringent rules at all. It can be overridden https://docs.flatpak.org/en/latest/s...reference.html on runtime, 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).

[andyprough]

Sticking all your customers with one bloated, boggy runtime for 10 years sounds like a nifty idea for growing profits.

[You-]

Sticking all your customers with one bloated, boggy runtime for 10 years sounds like a nifty idea for growing profits.

They are not sticking their customers with 1 runtime for 10 years. They are guaranteeing support and presence for 10 years.

When RHEL 9 is released, I am sure there will be another runtime made from that. It is likely that RHEL 10 will be outwithin the 10 years too. For commercial software that doesnt want to spend time updating, it will continue to work for atleast 10 years. For everyone else, they can move onto newer runtimes.

And this is for people who do not want to use the freedesktop runtimes - which are AFAIK supported for 2 years.

So a good breadth of option for software vendors.

[starshipeleven]

Sticking all your customers with one bloated, boggy runtime for 10 years sounds like a nifty idea for growing profits.

The "runtime" is just a flatpacked version of RHEL, so it follows the same schedule.

And having some runtimes with long-time support from an actual OS vendor (none of this "community" or "opensource" support amirite?) is something that will be very interesting for many corporate software vendors, and even consumer software developers eventually.

[mroche]

When RHEL 9 is released, I am sure there will be another runtime made from that. It is likely that RHEL 10 will be outwithin the 10 years too.

If what I heard at Nest was anything to go off of, it will be. It was mentioned, IIRC, that RHEL is on a three year major release cycle starting with RHEL 8. I’ll have to try and scrounge that clip up once posted or ping SteveG to confirm that. I believe it was noted that RHEL 9 will be based on Fedora 34.

The Red Hat cycle has seen drastic change with this release, including the pieces for CentOS Stream and Enterprise Linux Next.

Cheers,
Mike

[cl333r]

I don't know if I like or dislike it.
With the flatpak support becoming "default" they will all start creating flatpaks - and the required HD Space will go up again, like in old times. Almost like Windows installation packages. Wonder if they implemented the mess it makes under windows, into Flatpaks ...

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.