Red Hat Begins Talking Up The New RHEL Flatpak Runtime

[Paradigm Shifter]

I'll be honest, I prefer Flatpak over Snap, although both do things which really frustrate me.

Getting theming to work reliably has been an exercise in frustration. Dark themes in particular are a wossname; I got a dark theme working only to have the icons still "light theme" - and thus practically invisible - then figured out how to get the icons working correctly. Worse, some programs obey theming and others don't for no reason I can figure out.

Getting either to see the office printer... well, I've given up on that one. I just print to a file and then print that manually. Installing GNU Octave via Flatpak seemed like a great idea until I then spent a day poking around to get various dependencies for the Octave packages visible to it. Which I need to do practically every time I need to add something. When I set up a second box, I just bit the proverbial bullet and compiled Octave from source, which was less painful with the 5.x release than I remember it being with the 4.x releases...

Sandboxed applications are great for things you don't (or shouldn't) trust. Like a web browser. For other things? Not so much.

[cynical]

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.

Ooh, bravo! This is not repeated often enough. It just seems rude to me now to simply break someone’s code and expect them to keep up with your crazy decisions. Like if you want to completely change the API or something, due to expanded scope or a different vision, why not simply make a new project and leave the last one for people to use? Rename it instead of breaking the API and forcing people to update their code. (which may not even be possible in some cases)

Working with Lisp and immutability in particular has completely changed my perspective on how things should be done. You get used to the idea of not mutating things, but rather adding to something existing without changing it or making something totally new. That may be why some developers find it natural to do what they do. They have a destructive mindset from being able to mutate and destroy at will in C code and lack the discipline or the insight to do better.

[cl333r]

My last hardcore Flat usage was around 4 to 6 months ago so things may have changed a bit since then.

It's a mixed bag -- on one hand it's nice because if the programs go FUBAR they don't wreck your main system...on the other hand some things like game controllers and printers can be difficult to impossible to get working which can make the program not even useful.

The HD space isn't always that bad since Flats can share some dependencies. It can be like installing either Kate or Yakuake on a Gnome system since either one will pull in 1GB of KDE/Qt dependencies whereas installing Yakuake a day after installing Kate might pull in 20mb of application data...but Flats still seem to be larger overall so that isn't the greatest of examples, just the closest I can think of.

As it stands I'm against it for regular, normal people usage until all the hardware kinks are worked out. It just isn't something that's "Mom Ready" quite yet.

Once it's just as easy to use as any other generic app store and peoples' hardware, etc just works after installing a Flat is when I'll be for them for mass usage....though I still have reservations about sandbox versus native performance....but we're discussing this at Phoronix so that reservation is to be expected.

Agreed, though I use it because an app isn't available thru apt-get, ppa or is too old, e.g. I installed handbrake and it's the latest version (1.3.3). And flatpak has a better terminal interface than snap. Never was a sysadmin or such so never cared about security.

[You-]

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

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.

[starshipeleven]

Compare that with AppImage which is orders of magnitude leaner solution (zero dependencies),d easy to use and simply wotks from the perspective of the user.

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.

[zoomblab]

Every time I read about flatpak and snaps I feel sad. Because I know that both have slim chance of relevance in the long run (10+ years). And that is because they require a big (especially so in the case of flatpak - just research ostree) underlying technology infrastructure in order to achieve negible results for the user. Definition of over engineered bloatware.

Compare that with AppImage which is orders of magnitude leaner solution (zero dependencies), dead easy to use FROM THE GUI and bundles simply work from the perspective of a user. Not mention the benefit of freedom from being a follower and supporter of vendor agendas.

[starshipeleven]

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.

Keyword is "can".

[LinAGKar]

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.

Yes, since it puts it in OSTree, which identifies files based on the hash, any files that are identical will only be stored once.

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

[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