[Conan_Kudo]

As one of the folks that was present during the early decision-making around this, this was a wart that I wish the team had heeded me on fixing early on. Once they introduced "classically confined" snaps (that is, snaps that have no confinement and exposed the real filesystem hierarchy to them), there was no fixing this anymore. To be clear, the decision to stick to their guns on /snap predates the introduction of "classically confined" snaps.

The reason that "classically confined" snaps don't work on Fedora out of the box and don't work on Fedora Silverblue at all is because of this wart. Fedora's snapd uses an alternate path because /snap is not allowed. This means that /snap path doesn't exist, but it also means that "normal" snaps work fine on all Fedora variants, since it doesn't require an FHS hierarchy mutation.

[curt15]

>Once they introduced "classically confined" snaps (that is, snaps that have no confinement and exposed the real filesystem hierarchy to them)

If there is no confinement, what advantages do "classically confined" snaps offer over AppImages?

[loloquwowndueo]

None, but that’s the point/ feature of classic confinement snaps : they have access to the entire filesystem at the expense of having access to the entire filesystem :)

By comparison, a strictly confined snap only has access to its own data directory and possibly to some configuration files or the users home directory, depending on which permissions it’s been granted.

A text editor which is most useful if it can edit arbitrary files in the filesystem could be classically confined.

A music player might be strictly confined with access only to external devices (and maybe users home directory).

A fishy untrustworthy crypto miner could be strictly confined with no additional permissions so it can only see/touch its own data.

[BruiseLee]

Forced updates.

[moistbar]

Or a centralized update mechanism at all. As I understand it, Appimage doesn't offer such a feature.