Two Fedora Spins Eye Going X.Org-less

[ssokolow]

It's not my job to provide security updates or patch them. It's on the app dev. Same with static linking.

In practice, app devs are incompetent enough at it that...

• SDL has an internal mechanism to have a statically linked copy delegate to a dynamic library.
• Every package manager has a mechanism for allowing at least the common dependencies to be updated without requiring upstream to do it.

Cool. Does it touch the hard disk? I don't want to. I want everything under one directory, on a location I want to choose.

Or even run it from USB directly.

That particular command will mirror the relevant part of any configured package repository to a local folder of your choice. There's another command which allows you to specify a custom location for where packages install into.

Yikes.

Good thing 99.9% of the world does not agree with you, that's why Windows (or all other OSes) are considered user friendly for app distribution while git is "arcane".

Most of the world doesn't want to archive applications, complete with all dependencies but, even what they do want agrees with me much more than you.

That's why things like GOG Galaxy and the Itch.io client were necessary for GOG and Itch.io to compete with Steam. (It's a demonstrated fact that, in the early 2000s, before Steam came along, PC gaming was on the decline, losing out to game consoles because of their more "just works" nature.)

[Weasel]

In practice, app devs are incompetent enough at it that...

• SDL has an internal mechanism to have a statically linked copy delegate to a dynamic library.
• Every package manager has a mechanism for allowing at least the common dependencies to be updated without requiring upstream to do it.

Sure, but the point is that it's on the app dev. If you want to hack around this, then it's on you, and requiring more technical expertise here is not a bad thing.

People talk about vulnerabilities in libraries as if they're the end of the world. What happens if the app's code itself has vulnerabilities and the dev is incompetent? Bingo.

Just treat the entire thing as one package.

That particular command will mirror the relevant part of any configured package repository to a local folder of your choice. There's another command which allows you to specify a custom location for where packages install into.

How about embedding itself so you don't have to install any flatpak stuff?

Most of the world doesn't want to archive applications, complete with all dependencies but, even what they do want agrees with me much more than you.

That's why things like GOG Galaxy and the Itch.io client were necessary for GOG and Itch.io to compete with Steam. (It's a demonstrated fact that, in the early 2000s, before Steam came along, PC gaming was on the decline, losing out to game consoles because of their more "just works" nature.)

Well can't argue with delusions.

I don't use GOG, but I don't know what you mean with Steam. You can have your library anywhere and it stores games under one directory only. You can copy it to archive it (along with the manifest one level above) and plenty of people who care do just that. Not a hodge podge of complicated dependency tracking or other deduplication complicated "centralized" nonsense.

You also get all the games from Steam not from a million different repos and sources on the internet. Some might be down. Shit happens.

[ssokolow]

How about embedding itself so you don't have to install any flatpak stuff?

BUG: Appimage requires that app developers opt into providing the metadata for the optional appimaged to receive updates.

BUG: Appimage can't deduplicate bundled dependencies to save space on your SSD.

I don't use GOG, but I don't know what you mean with Steam. You can have your library anywhere and it stores games under one directory only. You can copy it to archive it (along with the manifest one level above) and plenty of people who care do just that. Not a hodge podge of complicated dependency tracking or other deduplication complicated "centralized" nonsense.

You also get all the games from Steam not from a million different repos and sources on the internet. Some might be down. Shit happens.

It boils down to "Appimage doesn't have a package manager and experience has shown that people who don't also have time to install and update Gentoo Linux tend to want as many of the apps in package managers as possible." (For reasons like "I don't want to have to whether the site I'm downloading this from is trustworthy again for each thing I install" and "I don't want every application to (badly) reinvent updates" and so on.)

Likewise, the biggest difference between snaps and Flatpak... the difference that makes snaps perform like ass... is that snaps are more like Appimages, based on keeping things packed into disk images.

Macintosh app bundles lack that flaw because of two things:

1. They aren't actually disk images... what you drag out of the DMG disk image is a folder that the file manager pretends is a file unless you use the option in the context menu to descend into it.... which means you get all the same performance advantages that Flatpak's "forest of hardlinks for deduplication" approach brings.
   (Don't believe me? Look under /var/lib/flatpak/app/ for system-installed Flatpaks. For each version of each application currently installed (eg. /var/lib/flatpak/app/org.mozilla.firefox/x86_64/stable/efd4e2492e49d9208f2a3ed50ba6d898eed4f8a92b902ccbd2 a9a4cc703b8257/files/), you'll find a clean, intuitive copy of the non-platform parts of what would be packed into an Appimage or Docker container. Most of the work is just setting up the hardlinks and integrating into the system metadata.)
   
   (...though normally you'd use the symlinks and just go to /var/lib/flatpak/app/org.mozilla.firefox/current/active/files)
2. Like with the Steam Runtime, they can trust that the platform will provide more or less everything they need as part of the guaranteed-to-be-ABI-stable platform interface. (Flatpak, Snap, and Appimage are acknowledgements that, even when they try, Linux library developers suck at maintaining ABI stability to the degree where you wouldn't want to bundle your dependencies just in case.)

[Weasel]

BUG: Appimage requires that app developers opt into providing the metadata for the optional appimaged to receive updates.

Different topic, but auto updates are cancer. Imagine downloading random code from the internet and installing it immediately, before doing any audits or at least a scan.

How to properly update: download new version yourself!

BUG: Appimage can't deduplicate bundled dependencies to save space on your SSD.

Depends on filesystem. For those without deduplication you can use a tool to find dupes and hardlink them or something.

But far more importantly it stores everything the app needs under the app's directory. Storing them in a centralized place is a complete nightmare in comparison. That's why normal distro packages suck.



For your other comment, yes, I do not want them to touch my /var or whatever other centralized place. I don't want them to touch my home directory either, unless I explicitly place it there, and then only in a subdirectory of where I placed it. Snaps have a semi issue here as well.

Remove the app entirely (without configs)? rm -rf /path/to/app/dir or use simple file manager to do it.
Back it up? cp -aft /path/to/backup /path/to/app/dir or use simple file manager to do it.

No need to install anything. No need to use complex software with possible bugs. Works on any file manager or distro or filesystem (who doesn't bundle rm or cp?). Nothing is written "behind my back" by some obscure utility and certainly I dictate exactly where the storage goes. If I have 5 disks, I want to precisely decide where it ends up, not in freaking /var.

Simplicity, man. Simplicity.

A complex system doing shit behind your back isn't it.

[ssokolow]

Different topic, but auto updates are cancer. Imagine downloading random code from the internet and installing it immediately, before doing any audits or at least a scan.

How to properly update: download new version yourself!

Or, instead of opening up a browser and manually copy-pasting the contents of what appears into vim, I could use wget. Flatpak lets you review what updates are available and choose which ones to apply, so I don't see a major difference.

...especially when Flatpak makes it easier to use and customize sandboxing than Appimage+Firejail ever did for me, because upstream builds and tests with the expectation of containerization, and the peer pressure to sandbox as thoroughly as is reasonable for a default configuration, given available XDG portals.

...and how often do you actually audit the stuff you're installing in any sense thorough enough to be meaningful? Be honest now.

Depends on filesystem. For those without deduplication you can use a tool to find dupes and hardlink them or something.

That assumes the duplication is visible to the filesystem. Things like compression, block alignment, or subtle differences in dependency build configurations can easily throw that off.

Flatpak's runtimes, BaseApps, and common dependencies repo are designed to minimize the chances of files slipping past its file-level deduplication (the "if they have identical sha256sums/whatever, just hardlink instead of redownloading" function).

Simplicity, man. Simplicity.

A complex system doing shit behind your back isn't it.

Given equivalent requirements, some complexity is inherent. It's only a question of whether it's in your head or in the computer. I prefer the latter.

To me, what you're saying is equivalent to "I don't want git doing things behind my back, so I run cp and fdupes -H every time I want to record a new commit."

[Weasel]

Or, instead of opening up a browser and manually copy-pasting the contents of what appears into vim, I could use wget. Flatpak lets you review what updates are available and choose which ones to apply, so I don't see a major difference.

You have your browser open anyway and you use it already. Who the actual hell uses wget for a non-automated (non-scripting) download???

Are you actually serious right now, I feel like I'm talking to a neckbeard who thinks we don't need a GUI and all should be command line. Yeah, we live in different worlds, but I'm on the 99.9% of the population side.

...especially when Flatpak makes it easier to use and customize sandboxing than Appimage+Firejail ever did for me, because upstream builds and tests with the expectation of containerization, and the peer pressure to sandbox as thoroughly as is reasonable for a default configuration, given available XDG portals.

...and how often do you actually audit the stuff you're installing in any sense thorough enough to be meaningful? Be honest now.

I don't update apps as often as you think. Only if I really want to because of a new feature I consider worth. "If it ain't broke, don't fix it". I update the browser, of course, since it has access to the internet, but I always run at least one virustotal scan and then a google search to see if anyone found something suspicious with the new update. And that's a couple of days after it was released.

That assumes the duplication is visible to the filesystem. Things like compression, block alignment, or subtle differences in dependency build configurations can easily throw that off.

Flatpak's runtimes, BaseApps, and common dependencies repo are designed to minimize the chances of files slipping past its file-level deduplication (the "if they have identical sha256sums/whatever, just hardlink instead of redownloading" function).

If the files differ, it sounds like potential for breakage. Think of crap like anti-cheats or other low level garbage that assume exact contents or whatever. So, good they're separate?

Given equivalent requirements, some complexity is inherent. It's only a question of whether it's in your head or in the computer. I prefer the latter.

To me, what you're saying is equivalent to "I don't want git doing things behind my back, so I run cp and fdupes -H every time I want to record a new commit."

Huge difference here: everything on a project is stored under that project's directory with git. Archive the project? Just copy the directory. Or remove it to get rid of it. No remnants on some paths someone else decided to on your PC, or whatever drive it ends up at. You have full control.

Literally same as I said above.

Also, git stores the entire files of a checkout "uncompressed" so, at worst, even without any .git magic, you can still have the specific checkout (or latest), you just lose the version control. It's still something, at least.

Lastly, git is insanely complex for a lot of people to get their heads around. That's an undeniable fact. I understand basic concepts myself, but I'm no git guru, either. Sometimes the easiest way to deal with a problem (complicated rebase for example) is to simply have it spit out patch files, because that's far more intuitive. See what I mean?

[ssokolow]

You have your browser open anyway and you use it already. Who the actual hell uses wget for a non-automated (non-scripting) download???

Are you actually serious right now, I feel like I'm talking to a neckbeard who thinks we don't need a GUI and all should be command line. Yeah, we live in different worlds, but I'm on the 99.9% of the population side.

We're talking about package management. Of course I'm automating things. That every upstream has its own unique URL scheme and metadata is one of the problems with AppImage.

If the files differ, it sounds like potential for breakage. Think of crap like anti-cheats or other low level garbage that assume exact contents or whatever. So, good they're separate?

More like "Package X builds SDL with --a, --b, --no-c, while package Y builds SDL with --a, --no-b, --c, and package Z builds SDL with --no-a, --no-b, --no-c, so Flatpak just provides a standard SDL dependency definition with all the functionality enabled", except less obvious.

Huge difference here: everything on a project is stored under that project's directory with git. Archive the project? Just copy the directory. Or remove it to get rid of it. No remnants on some paths someone else decided to on your PC, or whatever drive it ends up at. You have full control.

Until I want to have them in my launcher menu and my file-type associations system and so on, and then we're back to needing external tooling to avoud having to manually connect and disconnect everything, be it Flatpak or appimaged.

Also, git stores the entire files of a checkout "uncompressed" so, at worst, even without any .git magic, you can still have the specific checkout (or latest), you just lose the version control. It's still something, at least.

So does Flatpak. $PATH_TO_FLATPAK_INSTALLATION/app/org.mozilla.firefox/current/active/files

Lastly, git is insanely complex for a lot of people to get their heads around. That's an undeniable fact. I understand basic concepts myself, but I'm no git guru, either. Sometimes the easiest way to deal with a problem (complicated rebase for example) is to simply have it spit out patch files, because that's far more intuitive. See what I mean?

My point remains equally valid for any version control system. It's not dependent on git's sub-part UX.

[Weasel]

We're talking about package management. Of course I'm automating things. That every upstream has its own unique URL scheme and metadata is one of the problems with AppImage.

???

I'm talking about the users having to use it. Package management exists and it sucks for some reasons, not saying it's not fit for many tasks (system stuff basically), but it does suck for some. flatpak is basically package management v2, which still sucks for some of those reasons.

The whole spirit of AppImage-like stuff is that it does away with the notion of package management. I'm not saying you should make everything an AppImage (or similar), though.

More like "Package X builds SDL with --a, --b, --no-c, while package Y builds SDL with --a, --no-b, --c, and package Z builds SDL with --no-a, --no-b, --no-c, so Flatpak just provides a standard SDL dependency definition with all the functionality enabled", except less obvious.

The point is that has potential for breakage (at the very least, bugs). Here's another one less obvious: let's say a feature enabled uses more memory, or maps a lot of memory (like PA does), which can be a big problem on 32-bit. (for example it's a problem with Wine and 32-bit games)

Until I want to have them in my launcher menu and my file-type associations system and so on, and then we're back to needing external tooling to avoud having to manually connect and disconnect everything, be it Flatpak or appimaged.

Fair point, I dislike those things unless I manually add them.

So does Flatpak. $PATH_TO_FLATPAK_INSTALLATION/app/org.mozilla.firefox/current/active/files

Does it contain all the dependencies under that directory? Like, could you copy that dir and then run the app from there without flatpak? (assuming correct LD_LIBRARY_PATHs of course, and obviously no sandboxing or anything, just asking if it works, not that you would do it)

[dragon321]

PowerPC CPUs had no monopole means they could cut it and had zero fallout from it.

X86 instead has a monopole... if they cut it that means it will hurt them much.

x86 has a monopole on PC, not on Macs. After few years x86 will be history for Macs just like PowerPC. There is literally no reason why Apple would keep compatibility with it.

[ssokolow]

I'm talking about the users having to use it. Package management exists and it sucks for some reasons, not saying it's not fit for many tasks (system stuff basically), but it does suck for some. flatpak is basically package management v2, which still sucks for some of those reasons.

The whole spirit of AppImage-like stuff is that it does away with the notion of package management. I'm not saying you should make everything an AppImage (or similar), though.

I think that we're never going to see eye-to-eye on this. What you want and what I want can only be reconciled when you have someone like Apple or Microsoft bridging the gap with a monolithic, stable platform ABI and the ability to dictate that the desktop environment will come standard with integration analogous to appimaged.

The point is that has potential for breakage (at the very least, bugs).

So does any custom building. The Flatpak approach is "Hey, upstream. Here's a standard build manifest for your dependency we think is the least likely to go wrong. If you agree that it'll work for you, please use this instead of doing your own."

Here's another one less obvious: let's say a feature enabled uses more memory, or maps a lot of memory (like PA does), which can be a big problem on 32-bit. (for example it's a problem with Wine and 32-bit games)

Fair point... but the trend is for distros to drop support for 32-bit hosts, and, while Flatpak supports 32-bit x86, Flathub doesn't provide packages for it so it'd be up to the distro that wants to continue supporting 32-bit to download the Flathub's public repository of build manifests and make 32-bit builds on their own infrastructure, similar to what Ubuntu does with packages inherited from Debian.

Fair point, I dislike those things unless I manually add them.

And I like them enough that I'm working on a tool to heuristically generate a Steam/Lutris/etc.-like listing of games from a folder of game folders that may or may not have explicit metadata files. (Best case, a game is just a case of unzip gog_installer.sh to avoid cluttering up my system launcher menu, but some require things like heuristically converting the folder/file name in to a human-friendly title.)

Does it contain all the dependencies under that directory? Like, could you copy that dir and then run the app from there without flatpak? (assuming correct LD_LIBRARY_PATHs of course, and obviously no sandboxing or anything, just asking if it works, not that you would do it)

Everything except dependencies provided by the platform runtime (eg. SDL, GTK, Qt, etc.), which is another package with a path like $PATH_TO_FLATPAK_INSTALLATION/runtime/org.freedesktop.Platform/x86_64/22.08/active/files/

The runtime to use is specified in the .ini-style manifest file at $PATH_TO_FLATPAK_INSTALLATION/app/org.mozilla.firefox/current/active/metadata

The application is built with --prefix=/app and the runtime is built with --prefix=/usr and Flatpak --bind mounts them to those locations when launching a container. (With /app being writable at build time and /usr being read-only at build time, while both are read-only at runtime.)

Flatpak explicitly supports swapping out the runtime for debugging purposes, so the build can theoretically work with the default system /usr, assuming any required dependencies from the runtime (eg. SDL 2) are present and of sufficiently new versions, but whether a Flatpak application package will work at a path other than /app depends on whether it embeds hard-coded --prefix paths at build time.