[Doc] Query: Should the Readme file be improved wrt packages?

[giantclambake]

I'll open this with one of your statements from #1627 ....to wit;

I don't think this is a Flatpak issue, I would have noticed something wrong on the SteamDeck if that was the case (which can only use flatpaks)

Indeed, the text in bold being the crux ~ on the SteamDeck, one really doesn't have a choice -- you have to use the flatpak route. Ofc, a speculative question remains --- if SteamOS worked with DEB packages, would you still use the flatpak? ;)

Far be it from me to tell anyone how to install/use software packages, but, having been around linux since day dot, it has long been the credo of major linux distros, to use the (.deb/.rpm) system packages 'if available', as suited to their respective package manager setup. This is because 'someone' built the package, checked that it worked for the target OS version(s), and is most likely to work as expected, OOTB as it were...just like other packages.

I really question, if ticket #1627 would've existed at all, had the user installed using the provided RPM package, instead of using the flatpak route? Personally...I'm leaning towards the answer "no" ...rationale: there'd be lots of fedora users complaining the RPM package didn't work, and currently nobody has complained in this regard afaik.... Occam's razor ;)

I think it's worth bolstering some apparent reality, by improving the github Readme file, under Getting Amiberry -> Linux ... something like this...

• Amiberry is available as DEB and RPM packages for ARM32, ARM64 (aarch64) and x86_64 Linux platform distributions. You can download the latest version of these packages from the Releases area.

• A Flatpak version of Amiberry is also available on Flathub, for linux systems where a Flatpak installation is preferred, for example installing Amiberry on a SteamDeck.

Yeah?....it just tidies that text up a bit (current text inadvertently and non-alphabetically proffers 'Flatpak' ahead of DEB/RPM..in a para that links to the Releases page where the flatpak is not ;) Without saying as much, the above proffers DEB/RPM to the various linux distros (added word 'distributions') which, for us, are tested deployment methods, whilst still proffering the Flatpak route...(the actual keywords are 'for linux systems', which infers if your distro supports DEB/RPM packaging, you should probably use that route instead)...and giving a hint this has been tested on a SteamDeck....

What do you think?.....

TIA

[Arcitec]

I really question, if ticket #1627 would've existed at all, had the user installed using the provided RPM package, instead of using the flatpak route? Personally...I'm leaning towards the answer "no"

Well, good timing hehe, the answer is there now:

Yeah, I have tried the native RPM Fedora package now, v7.0.4. It still freezes on X11. So it was not a Flatpak issue.

[giantclambake]

Yeah, answers the question ;) I still think the Readme file should be improved notwithstanding tho' =)

[Arcitec]

Yeah your suggestion about phrasing seems fine.

As for Flatpak, it's becoming the primary way to distribute applications on Linux and is backed by KDE, GNOME and others. It solves the fact that desktop (not-server) Linux is an extremely unsafe operating system (the least safe in the world in fact), where every native application runs without sandboxing, without any antivirus, and with complete access to do crypto ransomware attacks, personal file theft, SSH key theft, etc. Because all native code is capable of reading and overwriting every single file in the user's home directory.

Malware on Linux is a growing problem as Linux gains popularity. There's plenty of Linux desktop malware going around already. There's also plenty of malware being discovered in 3rd party libraries and dependencies all the time (often hidden in the very long tails of dependencies of dependencies of dependencies). Flatpak is secure by default and it's up to the app authors to choose what directories the app should have read and/or write access to. App authors are strongly discouraged from adding host or home access, and are instead told to restrict to the exact directories they need.

Malware vetting is also improved by having a unified place to analyze the manifest and code (at Flathub, where there's a lot more eyes on the code). Whereas native Linux distros often have almost zero vetting of the packages they build and distribute - unless it's one of the "huge" apps like Firefox, their other packages are usually just managed by one volunteer dude that uploads new source tarballs whenever he/she feels like it, with zero source code vetting.

It also solves the cross-distro packaging problem by ensuring a stable environment where all dependencies are always compatible with what the application needs. Otherwise you'd have Debian where you have something like "SDL 3.0" and Arch where you have "SDL 3.15" etc etc, which means that software would be unable to rely on new features that are missing in libraries on the outdated distros. A massive pain that has plagued Linux since the start.

Next, it solves cross-desktop environment distribution. In the past, if you wanted a KDE application, you had to install a ton of KDE dependencies, or if you wanted a GNOME application, you had to install a ton of GNOME dependencies. Those dependencies conflict with each other (GNOME keyring vs KDE keyring on dbus would conflict with each other, and KDE desktop portal would conflict with GNOME desktop portal, etc). With Flatpak, that's all isolated away from the host so that you can use any app you want on any desktop environment, finally.

Flatpak also solves secure device access to things like webcams, screen capture etc, via permission portals where the application requests permissions, and Flatpak grants or denies it based on the user's choice. This means that things like keyloggers and screenloggers are stopped.

It's also the only way to install apps on immutable distros, since you can't install packages on those distros (or if you can, it's often a slow and tedious process of layering on top of the immutable base, and in the case of Silverblue it adds a very long, permanent delay to the daily system auto-updates, since the native packages have to be slowly re-layered after every update).

Lastly, it solves the "developer burnout" problem on Linux by giving developers a very easy way to accept donations and subscriptions (it's coming soon) so that Linux developers aren't slaving away thanklessly.

It has some issues for sure, but it's constantly evolving to fix its shortcomings, and is overall a great thing for Linux and has led to a boom in application developer activity.

[midwan]

Thanks, Readme updated