Hi gang,
Of late, I notice that quite some stuff is only found on Flatpak and not in the Repo (anymore)… 
Anyone noticed that trend?
Is it a trend?
Personally, I’d prefer the Repo or compiling on my machine…which is…the “core” Linux way, I suppose…
Am I alone in this view?
Thanks for meditating with me
Peace
Melissa
Honestly? I doubt it. Although I might be wrong.
I don’t even have flatpak or snapd (or whatever you want to call it) on my computer. I only use the repositories or the AUR as last resort.
I guess companies like Flatpak because they’re contained, so easier to make and maintain for, so cheaper to work with/for.
That said, I haven’t come across anything that was Flatpak-only…
4 Likes
it’s a imho a bad habit because flat- and snappacks will bloat the disks if everyone delivers his own “package” and it’s a danger as we can see with snappacks who became a popular way for malware-intrusion in the past.
1 Like
Are you sure?
Are your mirrors sorted?
There is no concerted effort to remove the repos and replace with flatpak.
1 Like
I use the interface - I may need to see what repos I have active. I was looking for the ZX Spectrum emulator, today, and it was only in the Flatpak. As @Olli mentioned, it is an attack vector…
Glad to notice that it’s my impression…
Personally…i’m not a fan of Flatpak, just like @Mirdarthos , or I’d have stayed with one of the “other” OS’es 
Flatpak packaged apps - in general terms - is not more dangerouse than other apps.
As with every opensourced application one has to determine if one trust the author(s) and developer(s) of the application.
Because everyone can upload a flatpak it requires the user to take proper precautions and exersise diligence in determining the possible sideeffects - if any.
Installing a flatpak using the Pamac GUI will be done using elevated permissions - which is unnecessary when it comes to flatpak.
Thus it is recommended to use the flatpak command to add an app from flathub. Doing so will limit the damage the application can cause if it turns out to be mailicious.
Flatpak is package technology which has the least impact on your base system and is a viable option when you try to keep your system stable.
Of course there is minor sideeffects when integrating to the current system - most notably device access, usb, files, camera and sound.
3 Likes
Attack-wise, I would think that it’s as safe/dangerous as the AUR.
What do you have against flatpak? Generally, the application works as the developer intended and all the dependencies are included, so it just works. This might be especially important on Arch-based rolling-distros where suddenly the underlying dependency is updated and the application doesn’t run anymore. Or on very old (or someone might say “stable”) distributions, the applications is updated but requires now newer dependencies which are not available on the older system.
One of the good things for flatpaks is for the developer of the application. They don’t need to care about the distribution channel: building a .deb for Debian/Ubuntu, .rpm for Fedora, providing PKGBUILD for Arch/AUR, etc. A flatpak is simpler to build and distribute.
3 Likes
but this will resume in the same that we call DLL-Hell in MS-windows. as long as someone uses only a few flat or snaps it might be okay but if it becomes the mainstream then it ends up in a bloated system.
1 Like
Is it actually bloated? It will take a few megabytes more but at least it makes sure that the application runs. What would be beneficial of a “non-bloated” version but it can’t run?
With flatpak, most libraries are shared, so they don’t bring their own ffmpeg for example.
1 Like
I have, though I can’t remember exactly which as I type, probably because my typical reaction is to raise my middle finger in annoyance, and move on to something else.
Same here, to a great extent. I think the issue lies in that containerised applications are ultimately less expensive in terms of overhead; one package to rule them all (so to speak), rather than having to deal with multiple packaging systems.
That’s plausible, and yet, I can’t help feeling it’s a rhetorical argument for most players. Historically, there have been Debian packages available for most everything while other formats were lacking.
The argument that there is too much overhead (in learning, production, etc.) has been used ad nauseam throughout all of that history, and as far as I can remember, nary an attempt has been made to overcome the situation. One could argue that containerised apps do just that, I suppose; yet, I’m not convinced.
Perhaps the popularity of producing containerised apps is also a convenient justification of some kind for an age-old whinge-fest.
I’m somehow reminded of the Monypythonian Life of Brian with the the Peoples Liberation Front where all they did was talk about reform, without actually taking action.
:end-mini-rant
Disclaimer: Chivas-Regal shares partial blame for this post.
2 Likes
There is such tendency, especially among the individual developers. Supposedly it is easier for them to reach more customers. But in reality, they would do the same if they publish easy instructions to compile, a deb and rpm. That is all it is needed, much of the aur stuff for example is just extracted debs.
For me, each of the universal/container formats has its own positive and negative sides (i do not want to comment on snap, let us just forget that this exists at all…i am just allergic to nonfree/propitiery/closed ecosystem/monopolised stuff):
Appimage: they are relatively small. They can be checked with virustotal, they can be extracted and inspected manually. The negatives are, they are sometimes not that universal and missing dependencies, and they have no permission system. In theory they can be updated with a click, but it is rarely implemented, so it comes down to a new manual download most of the time.
Flatpak: it has permissions, they can be managed, but it is hard to inspect the package. Cannot be scanned with virustotal. It does have an update system, manages dependencies, can remove orphans. Generarally speaking a very nicely organized system. BUT: it is an OS in the OS. And that makes it huge. The bear minimum for the first app is a gnome library which is a gigabyte…and vaapi, and and and, and if you install a qt app it is of course a gigabyte of kde at least. And those have different versions, so if some developer did not update his app and uses and old version of the runtime, you have another couple of hundred megabytes for the old gnome…
Yes, that impact minimizes the more apps you install, but still, it is something to consider and the biggest problem with the flatpak.
In both cases there might be issues with, for example, theming.
2 Likes
Which Spectrum emulator exactly? There are 100’s of them out there.
Most Manjaro packages come straight from Arch Linux so if it was in the repositories before and isn’t now then it was probably removed upstream for some reason. But it’s certainly not a trend in Arch/Manjaro.
It’s not a few megabytes. A GNOME flatpak app will pull in at least 1GB of GNOME library dependencies. Same for Qt/KDE. In theory these are shared with other flatpaks, in reality developers use different versions and so you end up with multiple GB of different GNOME/KDE versions.
3 Likes
Just an example how inefficient and bloated flatpak is:
Name Application ID Version Installed size
unlockR com.github.jkotra.unlockr 0.9.0 3,4 MB
Paolo Stivanin com.github.paolostivanin.OTPClient 3.6.0 179,4 MB
Flatseal com.github.tchx84.Flatseal 2.1.1 551,9 kB
Proton AG com.protonvpn.www 4.2.0 40,6 MB
Bottles Contributors com.usebottles.bottles 51.11 456,4 MB
Heliguy io.github.flattool.Warehouse 1.5.1 2,3 MB
nroduit io.github.nroduit.Weasis 4.3.0 154,1 MB
Freedesktop Platform org.freedesktop.Platform 23.08.14 592,6 MB
Mesa org.freedesktop.Platform.GL.default 24.0.3 495,2 MB
Mesa (Extra) org.freedesktop.Platform.GL.default 24.0.3 495,2 MB
Mesa org.freedesktop.Platform.GL32.default 24.0.3 525,8 MB
Intel org.freedesktop.Platform.VAAPI.Intel 46,5 MB
ffmpeg-full org.freedesktop.Platform.ffmpeg-full 20,5 MB
i386 org.freedesktop.Platform.ffmpeg_full.i386 20,6 MB
openh264 org.freedesktop.Platform.openh264 2.1.0 790,0 kB
GNOME Application Platform version 45 org.gnome.Platform 1,0 GB
i386 org.gnome.Platform.Compat.i386 518,2 MB
Matcha-dark-sea GTK theme org.gtk.Gtk3theme.Matcha-dark-sea 2021-12-25 555,0 kB
DXVK org.winehq.Wine.DLLs.dxvk 2.3 22,7 MB
Gecko org.winehq.Wine.gecko 109,1 MB
Mono org.winehq.Wine.mono 238,0 MB
If we calculate this, it makes about 800 MB in app size and 4100 MB in dependencies (runtimes). Adding to the confusion, this is real size, if one checks through the gui file manager will get the apparent size of the sparse files, which is about 8 Gig instead of the 5 you get from flatpak and du. And yes, i excluded my personal files and cache. This is pure installation size.
p.s. and to this day i do not understand why i need mesa 3 times. And yes, this is after removing the unused runtimes and the cache.
2 Likes
No…
1 Like
I think you mean ‘A ZX Spectrum Emulator’.
GitHub - chernandezba/zesarux: ZEsarUX - ZX Second-Emulator And Released for UniX this one?
A nice place to get insights is Linuxlinks : Best Free Linux Home Computer Emulators - LinuxLinks
There’s Fuse - the Free Unix Spectrum Emulator available in AUR as a PKGBuild, and then they state that the most recent version is always available also on Flathub .
1 Like
and then we run to the security question. once you’re using different versions (especially older ones) of a library and one of them has been updated because of vulnerbilities while you’re running an outdated non-safe one then the nightmare gets real.
So this was just spurred by a single application not being in the repos?
Besides which its also odd because there are at least 2 dozen hits for ‘zx spectrum’ if you include the AUR.
These ones
aur/zxinfo-file-browser-git 1.2.3.r3.g18c1e30-1 [+0 ~0.00]
Organize and manage your emulator files for ZX Spectrum & ZX 81 - powered by the web
aur/zxinfo-file-browser-bin 1.2.5-3 [+0 ~0.00]
Organize and manage your emulator files for ZX Spectrum & ZX 81 - powered by the web
aur/rustzx 0.16.0-1 [+0 ~0.00]
ZX Spectrum emulator written in Rust
aur/pzxtools 1.1-4 [+0 ~0.00]
A set of programs for manipulating PZX files, a tape file format designed primarily for archiving content of Sinclair ZX Spectrum tapes
aur/fbzx-git 3.9.1.r2.52b99b0-2 [+0 ~0.00]
Sinclair Spectrum emulator, designed to work at full screen using the FrameBuffer or under X-Windows.
aur/2cdt 1.4-1 [+0 ~0.00]
Create CDT/TZX for Amstrad/Spectrum out of raw files
aur/zesarux-bin 10.0-2 [+1 ~0.00] [Orphaned]
Emulator of different Z80-based computers, including ZX Spectrum. Precompiled binary.
aur/unreal-speccy-portable-git 0.0.83.r1.ged823c7-3 [+1 ~0.00]
Portable ZX Spectrum emulator based on UnrealSpeccy 0.37.3 by SMT
aur/skoolkit 9.1-1 [+1 ~0.00]
A suite of tools for creating disassemblies of ZX Spectrum games.
aur/retrovirtualmachine 2.1.11-1 [+1 ~0.00]
Emulator for ZX Spectrum (including Pentagon and TK models), Amstrad CPC (including Plus models), MSX-1, Colecovision SEGA SG-1000 and Sega Master System machines
aur/libspectrum-git 1.6.0.1ec4c7-1 [+1 ~0.06]
ZX Spectrum emulator support library.
aur/fuse-emulator-sdl-git 1.7.0.5114e2-1 [+1 ~0.06]
ZX Spectrum emulator.
aur/fuse-emulator-git 1.7.0.5114e2-1 [+1 ~0.06]
ZX Spectrum emulator.
aur/zesarux-git 2:ZEsarUX.11.0.beta1.r30.g2056b3e-1 [+2 ~0.00]
A Zx80/Zx81/Z88, Zx Spectrum 16/48/128/+2/+2A and ZX-Uno emulator with ULAPlus support. Development version.
aur/libayemu 1.0.0-1 [+2 ~0.00]
AY/YM sound chip (from ZX-Spectrum) emulation library.
aur/fuse-emulator-utils 1.4.3-1 [+2 ~0.00]
ZX Spectrum emulator utils
aur/bin2tap 1.3-1 [+2 ~0.00]
ZX Spectrum .bin to .tap converter
aur/zxtune-bin r5056-1 [+3 ~0.21]
Portable toolkit for ZX-Spectrum music playing (pre-compiled)
aur/unreal-speccy-portable 0.0.83-3 [+3 ~0.00]
Portable ZX Spectrum emulator based on UnrealSpeccy 0.37.3 by SMT
aur/zesarux 1:X-1 [+4 ~0.00]
A Zx80/Zx81/Z88, Zx Spectrum 16/48/128/+2/+2A and ZX-Uno emulator with ULAPlus support
aur/spectemu 0.99.3-6 [+6 ~0.00]
Fast and accurate emulator of the original 48k ZX Spectrum.
aur/fuse-emulator-sdl 1.6.0-3 [+6 ~0.00]
ZX Spectrum emulator (SDL GUI).
aur/zxtune-git r5054.r0.g2d3461378-1 [+8 ~0.21]
Portable toolkit for ZX-Spectrum music playing
aur/libspectrum 1.5.0-1 [+48 ~0.00]
ZX Spectrum emulator support library.
aur/fuse-emulator 1.6.0-3 [+64 ~0.00]
ZX Spectrum emulator.
1 Like
aaah, that one could do the trick… 