Red Hat Begins Talking Up The New RHEL Flatpak Runtime

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

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

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

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

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

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

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

[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?page=news_item&px=RHEL-8.2-Flatpak-Runtime