"Flatpak Is Not the Future"

Chat about anything related to Linux Mint
Forum rules
Do not post support questions here. Before you post read the forum rules. Topics in this forum are automatically closed 6 months after creation.
acerimusdux
Level 5
Level 5
Posts: 633
Joined: Sat Dec 26, 2009 3:36 pm

Re: "Flatpak Is Not the Future"

Post by acerimusdux »

Honestly, this article seems a bit of a mess.

The author's main point seems to be that flatpak will never be a replacement, on my Linux Mint system, for things like dpkg, apt, synaptic, the Linux Software Manager, or official debian, Ubuntu, and Mint repositories. But I think it wasn't quite meant to be that?

The article misses what flatpak does well. Sure, many developers might choose to offer their programs with less than ideally secure default settings. But that some developers are not, by default, using the full security that is available under flatpak, is not a very good argument for giving those *very same* developers complete unfettered access to your system with downloadable executables, including those which may have been packaged with mojosetup. With flakpak, you can at least install flatseal and easily manage those permissions. This author's preferred alternative is not really any useful alternative at all.

And he has also misrepresented security concerns around access permissions here. He complains about the permissions which show "in the Software app on a fresh install of Fedora 34", but seems to have not noticed that those are not the permissions with which GIMP actually installs from flathub. The GIMP in flathub has very secure permission defaults. It has file access only to it's own configuration directory, a directory for Gtk configurations, /tmp, and gvfs directories which allow it to create it's own virtual filesystem. He seems to imply that nearly ALL apps in the snap store can access all personal files and system resources. While I doubt whether this is true of snap, I don't really care about snap. But I know that it isn't true of flatpak. And so why then, isn't the title of the article "Snap is Not the Answer?" Or why didn't he at least check some of the most popular flatpaks on flathub like Firefox, Spotify, GIMP, Discord, and Steam? All of which seem well locked down.

In any case, sandboxing is a huge security benefit. Lax permissions lose some (but not most) of the potential benefits of sandboxing. But far and away the most common real world security threat on linux is people just randomly downloading and running things (often with root permissions) from questionable sources on the internet. And this guy pretty much wants that to be the default for 3rd party software installation.

And his proposed solutions for things all seem to invariably make things less secure and more complicated. He seriously want every developer to have to rewrite their code to make it compatible with flatpaks? And then says this:
Fedora is auto-converting all of their rpm apps to Flatpak. In order for this to work, they need the Flatpak permission system and Flatpak in general to require no app changes whatsoever.

Why on Earth would they do a mass automatic conversion of apps?
Maybe......because that is much simpler and much more convenient for both users and developers? Why on earth should an application's code have to be changed for a packaging and containerization system to work?

The flatpak portal system is working. It's why programs like Firefox, Gimp, etc., *can* run today with locked down default permissions. And there's no reason such a system couldn't eventually work also for programs like Excel and Photoshop. And while he may trust Microsoft and Adobe enough to want to allow them unfettered access to his system, I wouldn't. Even if such programs were available, I don't think I'd be tempted unless it was as a flatpak. And I don't see these companies being tempted to release Linux versions of their software either, if they have to rewrite these applications for either every platform, or every packaging system.

Ultimately, this article reads as though it was written by someone who doesn't understand the permissions based security system which has long made linux and other unix variants more secure than Windows. Sandboxing is in a way only a further extension of that kind of model. Moreover, he doesn't seem to understand how most free open source development works, either. Refusing to use flatpaks, even for what they are good at, is not by any means going to encourage any improvements. Nor is insisting on using only GTK 3 going to encourage the better development of more modern toolkits.

The one legit major downside I see with flatpaks is that the packages are big. Installing one might require 2G. Installing ten, more like 4G-5G. So I think best for now to limit it to things that need sandboxing, things which connect to the internet, and third party packages which are not available in Debian, Ubuntu, or Mint repositories (and some of which might not be available at all if it weren't for flatpaks). But who knows what future improvements will bring.
rene
Level 20
Level 20
Posts: 12212
Joined: Sun Mar 27, 2016 6:58 pm

Re: "Flatpak Is Not the Future"

Post by rene »

acerimusdux wrote: Mon Nov 29, 2021 4:00 am The author's main point seems to be that flatpak will never be a replacement, on my Linux Mint system, for things like dpkg, apt, synaptic, the Linux Software Manager, or official debian, Ubuntu, and Mint repositories. But I think it wasn't quite meant to be that?
Well, as you yourself point out only a bit later: yes, it does seem to be ultimately meant to be that, at least on Fedora. I.e.,
acerimusdux wrote: Mon Nov 29, 2021 4:00 am
Fedora is auto-converting all of their rpm apps to Flatpak. In order for this to work, they need the Flatpak permission system and Flatpak in general to require no app changes whatsoever.

Why on Earth would they do a mass automatic conversion of apps?
Now, Fedora Schmedora and all and I'm (fairly) sure that Ubuntu will not go all-in on snaps like that, but certainly it's been converting key applications; i.e. the Chromium issue that caused Mint to withdraw further from snaps.

Rest is again an all "security" comment. While snaps are/were originally server-side technology flatpak is explicitly desktop-side and as I mention frequently, in a practical sense and right now security is not really much beyond a theoretical issue anyway on desktop Linux --- even if you'd of course want the concept dealt with in a general application distribution system and especially one geared towards bypassing the repository model...

... but why does literally everyone keep on ignoring that there already is such deployed technology in the form of AppArmor/SELinux which works without this technically/fundamentally utterly ridiculous step of running every app in its own private Linux distribution on top of your actual one? Enforcing app-transparent sandboxing with native apps is creating/enabling a file in /etc/apparmor.d away.

Admittedly the article itself doesn't comment on that and certainly is geared towards not liking Flatpak --- but with all those other downsides of this as mentioned in essence utterly ridiculous technology I personally feel it somewhat justified.
acerimusdux
Level 5
Level 5
Posts: 633
Joined: Sat Dec 26, 2009 3:36 pm

Re: "Flatpak Is Not the Future"

Post by acerimusdux »

Well, as you yourself point out only a bit later: yes, it does seem to be ultimately meant to be that, at least on Fedora. I.e.,
But they haven't actually replaced those rpm, just added flatpaks as an alternative, so that some of these things can also be installed by people on different distributions, or even on different versions of Fedora. Now maybe they are hoping that flatpak can even replace rpm sometime in the future? But for now, well they just released Fedora 35 at the beginning of this month, and the ISO for their main desktop distribution, Fedora Workstation, comes with 1714 rpm installed, and zero flatpaks.

Yes, it will give you the option to install some flatpaks once that's installed, but for now, what they are actually doing isn't much different from Mint. Fedora does also have some other alternative distributions, including one an immutable OS image, and another container based one which uses things like Docker.

So maybe this is all meant to be directed more at Fedora, and the fear that they would one day get rid of rpms. But I'm doubtful that rpm, or deb for that matter, packages are going to be going away anytime soon.
Enforcing app-transparent sandboxing with native apps is creating/enabling a file in /etc/apparmor.d away.
Is there a convenient graphical interface for managing this? I mean, right now, running a sandboxed browser is as simple as selecting the flatpak in the software manager. Maybe that level of security could be duplicated by a combination of apparmour and firejail? But I wouldn't know how to use apparmour. Can you recommend a tutorial even?
rene
Level 20
Level 20
Posts: 12212
Joined: Sun Mar 27, 2016 6:58 pm

Re: "Flatpak Is Not the Future"

Post by rene »

acerimusdux wrote: Mon Nov 29, 2021 7:01 pm But they haven't actually replaced those rpm, just added flatpaks as an alternative [ ... ]
For now fair enough-ish I suppose. Which is not to say that I think "for now" holds definitive relevance on Fedora or elsewhere. As to us here on Mint the literally first thing that happened is that one of the most popular applications on Ubuntu, Chromium, went snap-only, not snap and .deb. Worse still, introduced a .deb that installed the snap behind your back.

Don't get me wrong. I used to think that potential for serious improvement regarding the third-party development / binary-compatibility situation was worth a lot and perhaps even the technically ridiculous step of running applications in their own little private distribution on top of your own. But having seen all these "runtime sharing" promises falter basically immediately, and in true Linux fashion that mentioned "potential" only having turned into more fragmentation, I'm fairly open to the by the article posited argument that Canonical and Red Hat ultimately merely aim to now finally also make it as big as the Android and/or iOS app stores.

Because really? We duplicate basically all of the distribution in a per-app manner so as to have the total of their startup time, disk and memory use increase manifold because of... uhm... uhm... I know! I know! Let's say it's for secuwity! They are bound to fall for that one again! Hahahaha!

No, as far as I'm aware there's no nice graphical interface to AppArmor. Yet. As mentioned, without that third-party promise to me it makes way more technical sense to invest in that than in the fool's paradise technology of flatpak/snap. It's not like AppArmor's hard as to its basics.

Code: Select all

rene@p55m:~$ sudo apt-get install apparmor-utils
rene@p55m:~$ sudo tee /etc/apparmor.d/usr.bin.cat >/dev/null <<EOF
#include <tunables/global>

/usr/bin/cat {
  #include <abstractions/base>
                              
  deny /etc/fstab r,          
}                             
EOF                 
rene@p55m:~$ sudo aa-enforce usr.bin.cat && cat /etc/fstab
Setting /etc/apparmor.d/usr.bin.cat to enforce mode.
cat: /etc/fstab: Permission denied
Yes, sure, Ubuntu has in true Ubuntu fashion in e.g. /etc/apparmor.d/usr.bin.firefox buried the reason why you can with it enabled still write to outside your Downloads folder a few includes deep but that kind of thing is fixable. The reason standard AppArmor profiles are hard to construct is that they are mandatory and app-transparent, i.e., not necessarily/generally app-endorsed, i.e., exactly as you above said the point of mandatory, app-transparent enforcement in the case of flatpak would be.

I am utterly unconvinced of this entire containerisation debacle and am becoming ever less so. Steam, sure. For me the point of a computer game is it being, well, an irrelevant computer game, and other than points at which "performance" starts to encroach on the enjoyment of said game, who the hell cares about efficiency and frankly much else in the fundamentally binary-only environment it is in in the first place. Sandbox the hell out of it and if after that you still don't trust it, don't play it.

But I really don't need that same ridiculousness for my main operating system and its applications.
User avatar
MurphCID
Level 15
Level 15
Posts: 5907
Joined: Fri Sep 25, 2015 10:29 pm
Location: Near San Antonio, Texas

Re: "Flatpak Is Not the Future"

Post by MurphCID »

Linux noob here. Dumb question; Why are the software packages in the repositories somewhat older than either Flatpak or direct from the maker (i.e. LibreOffice, or Thunderbird)? One my quirks is that I constantly install updates to my system (a hold over from the Windows reflexes), and I really, really want the most stable up to date Office suite for its compatability with Microsoft Office.
rene
Level 20
Level 20
Posts: 12212
Joined: Sun Mar 27, 2016 6:58 pm

Re: "Flatpak Is Not the Future"

Post by rene »

MurphCID wrote: Tue Nov 30, 2021 7:48 am Why are the software packages in the repositories somewhat older than either Flatpak or direct from the maker (i.e. LibreOffice, or Thunderbird)?
A non-rolling distribution's repositories --- Mint and Ubuntu are non-rolling --- is semi "frozen" at the time said distribution is released as the very meaning basically of "rolling vs. "non-rolling" in that context. In the case of Mint 20.x this was when Ubuntu 20.04 was released, i.e., back in 2020-04. As the idea of things included software gets important bug-fixes from that point on but does not see an upgrade to an entirely new version. There's of course always exceptions; in Mint most notably Firefox and since some time Thunderbird.

Rolling vs. non-rolling is a choice on the scale of bleeding' edge - new - current - old - historic. At the time of a new Ubuntu LTS and Mint major-version release it starts at current and at approximately our current time in the 2-year cycle ends up anywhere between current and historic depending on the specific bit of software. It is indeed also worthy of explicit mention that these application distribution systems are/can be a solution for getting newer applications on a still not bleedin' edge distribution and one that's in practice probably for most users most relevant even. The downside is e.g. that sandboxing/apparmor crap when you can no longer depend on your distribution to have integrated and checked things for you.
User avatar
MurphCID
Level 15
Level 15
Posts: 5907
Joined: Fri Sep 25, 2015 10:29 pm
Location: Near San Antonio, Texas

Re: "Flatpak Is Not the Future"

Post by MurphCID »

rene wrote: Tue Nov 30, 2021 8:14 am
MurphCID wrote: Tue Nov 30, 2021 7:48 am Why are the software packages in the repositories somewhat older than either Flatpak or direct from the maker (i.e. LibreOffice, or Thunderbird)?
A non-rolling distribution's repositories --- Mint and Ubuntu are non-rolling --- is semi "frozen" at the time said distribution is released as the very meaning basically of "rolling vs. "non-rolling" in that context. In the case of Mint 20.x this was when Ubuntu 20.04 was released, i.e., back in 2020-04. As the idea of things included software gets important bug-fixes from that point on but does not see an upgrade to an entirely new version. There's of course always exceptions; in Mint most notably Firefox and since some time Thunderbird.

Rolling vs. non-rolling is a choice on the scale of bleeding' edge - new - current - old - historic. At the time of a new Ubuntu LTS and Mint major-version release it starts at current and at approximately our current time in the 2-year cycle ends up anywhere between current and historic depending on the specific bit of software. It is indeed also worthy of explicit mention that these application distribution systems are/can be a solution for getting newer applications on a still not bleedin' edge distribution and one that's in practice probably for most users most relevant even. The downside is e.g. that sandboxing/apparmor crap when you can no longer depend on your distribution to have integrated and checked things for you.
Thanks. For the most part it does not bother me for probably 99% of software, which is why I like Mint and its approach. But my quirk if you will is the Office Suite, which I want to be the most up to date. For the most part I ignored kernels as well until I got these System 76 laptops, where I have to have late model kernels. Again, for the most part of 99% of the software, the two year cycle works well for me since I want stable over crash prone, except in Office Suites.
rambo919
Level 5
Level 5
Posts: 673
Joined: Wed May 22, 2013 3:11 pm

Re: "Flatpak Is Not the Future"

Post by rambo919 »

2 Years is WAY too long for a lot of programs..... downright ancient really.

Bleeding edge to me is half a year at most and anything beyond that should already be considered stable.
User avatar
MurphCID
Level 15
Level 15
Posts: 5907
Joined: Fri Sep 25, 2015 10:29 pm
Location: Near San Antonio, Texas

Re: "Flatpak Is Not the Future"

Post by MurphCID »

rambo919 wrote: Wed Dec 01, 2021 2:22 am 2 Years is WAY too long for a lot of programs..... downright ancient really.

Bleeding edge to me is half a year at most and anything beyond that should already be considered stable.
I completely understand you here, but for most people they want stable over unproven stable software. But I think for desktop and ONLY desktop LInux, there should be the opportunity to install via Flatpaks the latest versions of software, at your own risk of course.
acerimusdux
Level 5
Level 5
Posts: 633
Joined: Sat Dec 26, 2009 3:36 pm

Re: "Flatpak Is Not the Future"

Post by acerimusdux »

MurphCID wrote: Wed Dec 01, 2021 7:35 am I completely understand you here, but for most people they want stable over unproven stable software. But I think for desktop and ONLY desktop LInux, there should be the opportunity to install via Flatpaks the latest versions of software, at your own risk of course.
Yes, this is the nice thing with flatpaks, in theory at least, they should be relatively isolated from the rest of the system, so there is little risk of it breaking something else.

When people maintain distributions, there are various libraries and system programs which many other packages will depend on. It kind of makes sense to update everything at once, so you can make sure everything is compatible, and you can do some testing before release, and release when you know it's all stable. But then as newer versions of some programs come out, depending on newer libraries, they may need to wait for the next release.

Flatpaks just bundle some of those libraries and such in with the program, instead of installing on the rest of the system where it could be incompatible with something else.

Doing this with a few programs, for security and convenience, at the expense of it requiring a little more disk space, seems to make sense to me.

I guess the alternative is to run Debian Testing and deal with a little breakage once in awhile.
BrianI
Level 2
Level 2
Posts: 72
Joined: Fri Apr 12, 2019 6:13 am
Location: Fife, Scotland

Re: "Flatpak Is Not the Future"

Post by BrianI »

I can kind of see both sides of the debate. Flatpaks are somewhat larger, especially if it requires certain frameworks to be installed, e.g. Gnome or KDE stuff.More space is used if a flatpak requires a certain version of a framework, compared to another flatpak which requires a different version, e.g. Gnome Application Platform version 40 vs 41.

However it's easier to get software installed (particularly newer versions) via flatpak, rather than dealing with Ubuntu 20.04LTS based distros not having an up to date version of a required library.


Here is what I currently have installed on my system, flatpak wise.:

Code: Select all

brian@Giger:~$ flatpak --columns=app,name,size,installation list
Application ID                                    Name                                          Installed size         Installation
com.stremio.Stremio                               Stremio                                       255.2 MB       system
net.displaycal.DisplayCAL                         DisplayCAL                                    268.7 MB       system
net.sourceforge.Hugin                             hugin                                         143.9 MB       system
net.sourceforge.qtpfsgui.LuminanceHDR             Luminance HDR                                  39.5 MB       system
org.audacityteam.Audacity                         Audacity                                       50.2 MB       system
org.audacityteam.Audacity.Codecs                  Codecs                                         20.4 MB       system
org.entangle_photo.Manager                        Entangle                                       10.4 MB       system
org.freedesktop.Platform                          Freedesktop Platform                          742.0 MB       system
org.freedesktop.Platform                          Freedesktop Platform                          557.5 MB       system
org.freedesktop.Platform.GL.default               Mesa                                          313.2 MB       system
org.freedesktop.Platform.GL.default               Mesa                                          375.6 MB       system
org.freedesktop.Platform.GL.nvidia-470-86         nvidia-470-86                                   1.9 MB       system
org.freedesktop.Platform.html5-codecs             html5-codecs                                    8.8 MB       system
org.freedesktop.Platform.openh264                 openh264                                      778.2 kB       system
org.gimp.GIMP                                     GNU Image Manipulation Program                351.0 MB       system
org.gimp.GIMP.Manual                              GIMP User Manual                                1.1 GB       system
org.gimp.GIMP.Plugin.BIMP                         BIMP                                          763.4 kB       system
org.gimp.GIMP.Plugin.FocusBlur                    FocusBlur                                       9.3 MB       system
org.gimp.GIMP.Plugin.Fourier                      Fourier                                        26.6 kB       system
org.gimp.GIMP.Plugin.GMic                         G'MIC                                          38.8 MB       system
org.gimp.GIMP.Plugin.Lensfun                      GimpLensfun                                     5.0 MB       system
org.gimp.GIMP.Plugin.LiquidRescale                LiquidRescale                                   1.7 MB       system
org.gimp.GIMP.Plugin.Resynthesizer                Resynthesizer                                 377.9 kB       system
org.gnome.Platform                                GNOME Application Platform version 40         982.1 MB       system
org.gnome.Platform                                GNOME Application Platform version 41         766.0 MB       system
org.gtk.Gtk3theme.Adwaita-dark                    Adwaita dark GTK theme                          3.6 kB       system
org.gtk.Gtk3theme.Breeze                          Breeze GTK theme                                1.4 MB       system
org.gtk.Gtk3theme.Mint-Y                          Mint-Y Gtk Theme                              318.0 kB       system
org.kde.Platform                                  KDE Application Platform                        1.2 GB       system
org.kde.Platform                                  KDE Application Platform                        1.0 GB       system

Quite a bit of duplication, due to applications and their platform frameworks being sandboxed...


So my 50gb root partition on the 500Gb NVME drive is sitting at ~31gb used!

I do have a few Appimages though, they are easy to just download, and run from your drive, no actual installation needed, nor any dependency issues are all required libs are baked in. Again, a bit bigger in size, than a native .deb package.

Here is what I have on my ~/Applications folder on my home partition

Code: Select all

brian@Giger:~/Applications$ ls -lh
total 1.6G
-rwxrwxr-x 1 brian brian  47M Nov 23 09:01 audacity-linux-3.1.2-x86_64.AppImage
-rwxrwxrwx 1 brian brian  86M Oct  3  2020 balenaEtcher-1.5.109-x64.AppImage
-rwxrw-r-- 1 brian brian  80M Jan 15  2021 csBooks-5.6.0_0cce96df166e4d41344a80fc1ec4167b.AppImage
-rwxrwxrwx 1 brian brian  71M Apr 19  2020 electronplayer-2.0.8.AppImage
-rwxrwxr-x 1 brian brian 168M Jan 23  2021 GIMP_AppImage-release-2.10.22-withplugins-x86_64.AppImage
-rwxrwxrwx 1 brian brian  97M Oct 14  2020 JSplacement-1.3.0_fc029bf35f5bf65f6136325b4f8b4c88.AppImage
-rwxrwxr-x 1 brian brian 173M Oct 25 11:18 kdenlive-21.08.2-x86_64_0ccf743066f9b407bde2fc93e1835058.appimage
-rwxrw-r-- 1 brian brian 226M Nov  9 09:15 krita-4.4.8-x86_64_741934abbdda41c7cf7a11118d5b0880.appimage
-rwxrwxr-x 1 brian brian 133M Sep  1 12:16 Mandelbulber_v2-2.26-x86_64.appimage
-rwxrwxr-x 1 brian brian 123M Oct 23 20:04 Publii-0.38.3_390cc9427ad77115a20fc75f1a3c2ce7.AppImage
-rwxrwxr-x 1 brian brian 252M Oct 29 23:07 QMapShack-x86_64.AppImage_Ubuntu-18.04
-rwxrw-r-- 1 brian brian 105M Nov  9 09:27 RawTherapee_5.8.AppImage
User avatar
MurphCID
Level 15
Level 15
Posts: 5907
Joined: Fri Sep 25, 2015 10:29 pm
Location: Near San Antonio, Texas

Re: "Flatpak Is Not the Future"

Post by MurphCID »

I have noticed that the Flatpaks here are still way behind on LIbre Office which is at 7.2.3. and the one downloadable is 7.1.something. That is odd.
User avatar
Portreve
Level 13
Level 13
Posts: 4870
Joined: Mon Apr 18, 2011 12:03 am
Location: Within 20,004 km of YOU!
Contact:

Re: "Flatpak Is Not the Future"

Post by Portreve »

So, there's three issues I personally see with containerization, all of which I feel could be resolved:
  1. How can we trust binaries provided from some random source?
  2. They need to be able to work with attached peripherals (for example, Scribus as an AppImage doesn't seem able to see installed printers)
  3. Desktop Environment integration: there's gotta be a way not to have to bundle the damn DE with the program
Flying this flag in support of freedom 🇺🇦

Recommended keyboard layout: English (intl., with AltGR dead keys)

Podcasts: Linux Unplugged, Destination Linux

Also check out Thor Hartmannsson's Linux Tips YouTube Channel
rambo919
Level 5
Level 5
Posts: 673
Joined: Wed May 22, 2013 3:11 pm

Re: "Flatpak Is Not the Future"

Post by rambo919 »

MurphCID wrote: Wed Dec 01, 2021 7:35 am
rambo919 wrote: Wed Dec 01, 2021 2:22 am 2 Years is WAY too long for a lot of programs..... downright ancient really.

Bleeding edge to me is half a year at most and anything beyond that should already be considered stable.
I completely understand you here, but for most people they want stable over unproven stable software. But I think for desktop and ONLY desktop LInux, there should be the opportunity to install via Flatpaks the latest versions of software, at your own risk of course.
The problem is this is a fight that windows automatically wins, it says proudly that on linux only old versions of the software won't crash your system, that linux is slow to improve and fast to be unstable.

Flatpak in theory is good.... but in practice the dependencies are huge because all of linux is organized on a paradigm of single dependencies which means size does not matter as much which leads to huge flatpak installs while no one is looking with some apps basically installing whole multiple OS's worth of dependencies.

And then there is the problem of isolation which breaks some apps, freefilesync flatpak for example is utterly useless in many use cases.

The ONLY place for flatpak I can see is proprietary software where appimage can sometimes be superior depending on the product.
rene
Level 20
Level 20
Posts: 12212
Joined: Sun Mar 27, 2016 6:58 pm

Re: "Flatpak Is Not the Future"

Post by rene »

rambo919 wrote: Tue Dec 07, 2021 3:31 am The ONLY place for flatpak I can see is proprietary software where appimage can sometimes be superior depending on the product.
FWIW, that is the statement I agree with --- even if a valued third-party commercial developer that went of of its way to also provide a native version for the specific distribution and version thereof that I'd be using that particular fortnight would still have a leg up (if I'd not trust them I'd not use their software, period).
User avatar
MurphCID
Level 15
Level 15
Posts: 5907
Joined: Fri Sep 25, 2015 10:29 pm
Location: Near San Antonio, Texas

Re: "Flatpak Is Not the Future"

Post by MurphCID »

rambo919 wrote: Tue Dec 07, 2021 3:31 am
MurphCID wrote: Wed Dec 01, 2021 7:35 am
rambo919 wrote: Wed Dec 01, 2021 2:22 am 2 Years is WAY too long for a lot of programs..... downright ancient really.

Bleeding edge to me is half a year at most and anything beyond that should already be considered stable.
I completely understand you here, but for most people they want stable over unproven stable software. But I think for desktop and ONLY desktop LInux, there should be the opportunity to install via Flatpaks the latest versions of software, at your own risk of course.
The problem is this is a fight that windows automatically wins, it says proudly that on linux only old versions of the software won't crash your system, that linux is slow to improve and fast to be unstable.

Flatpak in theory is good.... but in practice the dependencies are huge because all of linux is organized on a paradigm of single dependencies which means size does not matter as much which leads to huge flatpak installs while no one is looking with some apps basically installing whole multiple OS's worth of dependencies.

And then there is the problem of isolation which breaks some apps, freefilesync flatpak for example is utterly useless in many use cases.

The ONLY place for flatpak I can see is proprietary software where appimage can sometimes be superior depending on the product.
I've never really thought about file sizes for Flatpak installs, it is just not something I have ever considered. Maybe that is my Windows legacy or something. If all the dependencies are met, for me anyway, I don't care about how big the file is as long as it works. I remember dependency hell from the bad old days of Linux.
rene
Level 20
Level 20
Posts: 12212
Joined: Sun Mar 27, 2016 6:58 pm

Re: "Flatpak Is Not the Future"

Post by rene »

MurphCID wrote: Tue Dec 07, 2021 7:24 am I've never really thought about file sizes for Flatpak installs, it is just not something I have ever considered. Maybe that is my Windows legacy or something. If all the dependencies are met, for me anyway, I don't care about how big the file is as long as it works. I remember dependency hell from the bad old days of Linux.
Note though that it's not just file size. All code/data that is not in fact shared also needs to be loaded into memory, i.e., memory size, and loaded into memory, i.e., loading speed, and run from unshared memory, i.e., cache pressure/runtime speed. As such and as said flatpak/snap can only be said to be reasonable technology technically when it does in fact share, which it as also said does to far less extent in practice than theory, and sort of by its very nature/goal.
Hoser Rob
Level 20
Level 20
Posts: 11796
Joined: Sat Dec 15, 2012 8:57 am

Re: "Flatpak Is Not the Future"

Post by Hoser Rob »

rambo919 wrote: Tue Dec 07, 2021 3:31 am ... The problem is this is a fight that windows automatically wins, it says proudly that on linux only old versions of the software won't crash your system, that linux is slow to improve and fast to be unstable....
Actually, software versions that are too old will break things just as readily as too new ones if you force the install.
For every complex problem there is an answer that is clear, simple, and wrong - H. L. Mencken
rambo919
Level 5
Level 5
Posts: 673
Joined: Wed May 22, 2013 3:11 pm

Re: "Flatpak Is Not the Future"

Post by rambo919 »

MurphCID wrote: Tue Dec 07, 2021 7:24 am I've never really thought about file sizes for Flatpak installs, it is just not something I have ever considered. Maybe that is my Windows legacy or something. If all the dependencies are met, for me anyway, I don't care about how big the file is as long as it works. I remember dependency hell from the bad old days of Linux.
It's much more noticeable on low capacity drives or slow internet. If you have large/fast of both you won't necessarily mind that a 2mb program requires a 5GB download.
rambo919
Level 5
Level 5
Posts: 673
Joined: Wed May 22, 2013 3:11 pm

Re: "Flatpak Is Not the Future"

Post by rambo919 »

Hoser Rob wrote: Tue Dec 07, 2021 10:02 am
rambo919 wrote: Tue Dec 07, 2021 3:31 am ... The problem is this is a fight that windows automatically wins, it says proudly that on linux only old versions of the software won't crash your system, that linux is slow to improve and fast to be unstable....
Actually, software versions that are too old will break things just as readily as too new ones if you force the install.
True but that's not something most people will think of.
Locked

Return to “Chat about Linux Mint”