Red Hat Begins Talking Up The New RHEL Flatpak Runtime

[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.

[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.

[andyprough]

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

[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).

[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]

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.

[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.

[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.

[Weasel]

That problem was solved 50 years ago with static linking.
Dynamic linking is to blame for this mess and the LGPL and similar licenses for kind of forcing dynamic linking.

The argument of maintaining one central library goes out of the window with the flatpak/ snap chaos in anyway.

Actually it's not dynamic linking at all, because you still need to interface with the kernel no matter what. Also sometimes with services and daemons. However, the kernel has a stable userspace interface. That's what matters.

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. First of all, if you ever bump the soname, keep the old version around forever. But it's better to just never bump the soname at all, period, because you can't trust the idiot distro maintaners. Keep the old functions around forever. If you need a new, better interface, just add a NEW function. If you need to change the binary layout of a structure, add a new interface that deals with the new struct, and keep the old one around. Is that really so hard?

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.

[jo-erlend]

If I was MOTU, I would've made RedHat and Canonical to provide a shared Flatpak/Snap runtime for the GLib/GTK3 platform. They would commit to support it for ten years and they would both use that time to promote development on that platform by getting people to write books that people can buy. Sure, the mainstream would move on to newer versions, but that would only make the older versions a safer place for new developers to play with. Not saying they shouldn't do the same with Qt.

My point is we should try to grow this thing and not just fight over who's the worst distro.