If you ever used flatpaks you would know that they are very noisy about dependencies being not up to date.
They also gain substantial amount of security by being sandboxed by default unlike majority of native packages.
They also gain substantial amount of security by being sandboxed by default unlike majority of native packages.
1. Current release applications on deprecated OS (Mostly good)
2. Deprecated applications on current OS (Mostly bad)
The Windows style packaging architecture introduces more problems than it solves. Fine for running something like Steam games with single shot application instances using 95% of system resources each power cycle, but folks could also just stick with Windows 11 if convenience and security-theater is their preference.
Some people probably won't notice the issues, but depends what they do. Arch Linux itself is a pretty awesome distro for lean systems. =3
Source? There is no measurable energy or efficiency difference at least for flatpak on any semi recent hardware. I know that snaps do take couple seconds longer at first start.
I prefer flatpaks for proprietary and internet facing applications because of there easy sandboxing capabilities. There is also the advantage on archlinux not needing to do a full system update for a single application.
https://tldp.org/HOWTO/Program-Library-HOWTO/shared-librarie...
Getting into why the community argued for years while Debian brought up deb version controlled packaging is a long dramatic conversation. Some people liked their tar ball mystery binaries, and the .so library trend started more as a contest to see how much people could squeeze out of a resource constrained machine.
In a single unique application running context, the power of a cached .so reference count are less relevant. As a program built with .so may re-use many resources other programs or itself likely already loaded.
> ldd --verbose /usr/bin/bash
> ldd --verbose /usr/bin/cat
Containerization or sand-boxing is practically meaningless when punching holes for GPU, Network, media and HMI devices. Best of luck =3
Many applications don't need these permissions and even the ones that do will be much more secure than having full user space access by default.
Someone could exploit the system to gain more access vs someone does not need to do anything because they have full access by default. It's like arguing you don't need a root password because sudo is insecure anyway.
Qubes, Gentoo, and FreeBSD are all a better place to start if you are interested in this sort of research. Best of luck =3
But thanks for trying to post actual relevant data on the topic. =3
"Popcorn Music Video" (The Muppets)
An outdated old package library relies on people understanding/tracking the complete OS scope of dependencies, and that is infeasible for a small team.
If someone wants in... they will get in eventually... but faster on a NERF'd Arch install. =3
That is exactly the strong point of flatpaks. It's a lot easier to use toggle in a GUI for permissions than write whole new profiles. Not to mention that many even disable selinux because it is difficult.
>An outdated old package library relies on people understanding/tracking the complete OS
It takes 0 understanding to copy paste a outdated package warning and report that to the repo listed in flathub. It explicitly tells you as much.