Red Hat Begins Talking Up The New RHEL Flatpak Runtime

[phoronix]

Phoronix: Red Hat Begins Talking Up The New RHEL Flatpak Runtime

With the recently released Red Hat Enterprise Linux 8.2, the Flatpak sandboxing and app distribution tech is ready to shine and there is also the new Red Hat Enterprise Linux Flatpak runtime...

http://www.phoronix.com/scan.php?pag...latpak-Runtime

[Smurphy]

I don't know if I like or dislike it.
With the flatpak support becoming "default" they will all start creating flatpaks - and the require 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 ...

[kpedersen]

"For many years, application developers who wanted to create desktop applications for Linux had to build their applications not just for a particular Linux operating system, but for a particular version of that operating system."

Not really. Just look at things like UT2004 and NWN. Still working fairly well today. So long as you use a sane number of dependencies, toolchain and language, it is fairly trivial to build portable / relocatable software. You don't even necessarily need to statically link everything, so long as you provide the libraries.

Flatpak is possibly good in the web developer space where they have no discipline to write software without simply mashing a load of old crap and stolen code together but for the desktop space, I don't find it too necessary.

[skeevy420]

I don't know if I like or dislike it.
With the flatpak support becoming "default" they will all start creating flatpaks - and the require 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 ...

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.

[skeevy420]

"For many years, application developers who wanted to create desktop applications for Linux had to build their applications not just for a particular Linux operating system, but for a particular version of that operating system."

Not really. Just look at things like UT2004 and NWN. Still working fairly well today. So long as you use a sane number of dependencies, toolchain and language, it is fairly trivial to build portable / relocatable software. You don't even necessarily need to statically link everything, so long as you provide the libraries.

Flatpak is possibly good in the web developer space where they have no discipline to write software without simply mashing a load of old crap and stolen code together but for the desktop space, I don't find it too necessary.

I've always thought that too based on some of the closed source Linux software out there. Because of that I've always look at Flats/Snaps/etc as an easier way to run a graphical program from a chroot/sandbox more than I have looked at them as a portable program solution. Being a long-term steam-native and ldd user doesn't help with that assessment.

[CochainComplex]

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.

I have the same impression. It becomes a bit delicate if you have e.g. Visual Code (or Codium) as Flatpak and you want to use a certain plugin which supposed to communicate with the system this can be tricky...to near impossible.

But none the less it is better then snap's. I have never tried the AppImage or how is it called?.
And steam was working rather good the last time I have checked it - less broken dependencies if you have a lot of ppa's on the native system.

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

[skeevy420]

....

I've had mixed results with AppImage -- when they work they're great, when they don't work you better be a command line warrior adept at log reading. I don't think I've actually used a Snap yet. I go out of my way to not use any of them because they all add an extra layer of crap that can go wrong that I don't want to deal with.

I've read that Steam is one of the ones that they really focus on so it really doesn't surprise me that you're giving it good marks. My biggest problem is printer support. I don't always need it...but I don't want to reboot into Windows to use a printer either...dual booting on my system theses days includes swapping drives because my motherboard sucks hard with its limit of 3 sata drives and my Linux setup consists of 1 480GB SSD and a 4TB ZFS mirror -- all my available disks -- so I gotta swap sata and power cables with my Linux root even though my PC has a free sata port and power cable available ....wow, didn't mean to go off on a dual boot rant

But, yeah, not being able to easily use my scanner or printer is what kept me away from Silverblue. I hope this move from Red Hat means that better hardware support is about there, if not there already there with development branches or patches or something -- I hope someone in the know can fill me in on that.

[Raka555]

"For many years, application developers who wanted to create desktop applications for Linux had to build their applications not just for a particular Linux operating system, but for a particular version of that operating system."

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.

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

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