With newer AppImages, you can run --appimage-extract and you will end up with a directory that looks very much like an .app on macOS, containing all the files for your to edit.
You can run AppImages in a sandbox of your choice; for example, Firejail has native support for it.
I look’d at AppImage apps and find it very interesting, but.
It’s available only for 64bit - that is problem for me, I don’t want to install 64 bit distro only for one format. And it’s not so popular on my opinion as snappy or flatpak, because Canonical or Gnome much famous than some noname. In the end I find much interesting that snappy have snapd - tool without what .snap’s can’t work, shorter - engine. Flatpak’s have it too, but it’s not preinstalled and need to be configured to work properly.
This is something you care about but you must understand that we don’t always have exactly the same plans as every person using the software we make.
Ok, I don’t pushing anyone to work on it just now, I only want to see good things happen in Linux’s “user-friendly” history. I want to see that any app for Linux is distributed in only one format, the true format, not .deb, .rpm, .appimage (seriously long name) or .flatpak. That zoopark is just delirium.
This is not even true on Windows or macOS, it’s even less likely to happen on Linux.
Windows has either custom installers (NSIS, WISE, etc.) or MSI based installers (InstallShield, WIX, etc.).
macOS has custom installers (InstallAnywhere, VISE, etc.), macOS Installer, RPM4OSX, Fink, MacPorts, Homebrew, etc.
At least in the Linux world, it’s usually quick to reduce to a few options (RPM/DPKG, Flatpak/Snap, AppImage).
Usually Mac OS don’t need installers at all, apps distributed in .dmg that itself just a container like a zip or iso. Only thing that user need to do with that .dmg is to open (mount) it and copy single file from it (I’d liked to see snap to be like that ‘single file’). Rarely .dmg contains more than one .app file - readme’s and additional things; and it happens that there can be .pkg - common app installer in mac. Don’t used OS X much cause of hard lags in vmware, installing of hackintosh is just impossible task for me, but all of apps that I downloaded don’t haved things what you said. Windows not mentioned here at all, it IS piece of shit.
Welcome to the forum Peter! I’m super happy to see you here.
Hi folks - I think it’s a great idea that we enable snaps that can be mounted in places other than /snap/foo. It would take some work for the snap author and it would have to be classic, but at the end of the day, I have no problem with something like ‘snap mount foo.snap /home/user/where/i/want/it’ working straightforwardly.
That said, I would not think we want to complicate the internals of snapd very much to achieve that. I don’t think we should try to make aliases work in this case, or other low-level system integrations. But it is absolutely fine to essentially treat snaps as what they are - a filesystem that can be mounted - and potentially allow users to do this for themselves without root.
This would also enable people to have two versions of a snap with different paths.
You would have to accept a bunch of missing capabilities (systemd jobs, aliases, tab completion etc) that are really related to a ‘system level install’. But you would get your blob where you want it. Thoughts?
My initial thinking into this was somewhat motivated by daydreaming and several console games in my son’s (right 
room. I was thinking what would it take to distribute a CD disk with a squashfs file system instead of iso8859-2. Such disk would could be mounted in a “ephemeral”-ish way where there are no services or other deep integration (though I would expect many things to work as usual, for example I would expect confinement to work without any changes). The system would activate the snap when the media is present and deactivate the snap when the media is gone. User data would be preserved as usual. I think such snaps should be somehow annotated “valid for use in removable media-like situations” just to ensure that developers don’t get unexpected behavior just because someone copies the snap to a thumb drive.
If you ignore the idea about CD disks this could be done with “just let me run my bunch of snaps on removable media here”.
There are lots of unanswered questions though, primarily about updates.
EDIT: Updates could obviously work if snapd kept them in the usual place and would allow to apply them without rebuilding the squashfs file. If we could have a kernel feature where we can say something like:
mount -t squashfs /dev/sr0 /snap/foo/bar -o ro,delta=/var/lib/snapd/snaps/foo_delta1,delta=/var/lib/snapd/snaps/foo_delta2`
And have the kernel look up the right block in the most recently changed object.The era of CD’s already gone, they replaced with high GB’s flash drives. So we need ‘no-binded to CD’ system, but the one that can give possibility to storage and run snaps from everywhere. About updates… I would not worry about this so much, only about auto-updates. I don’t update my software for long, only if update very impressive/necessarily.
For the low-level capabilities apps can require installing to root and do not allow to run without it, similar to how it’s working in mac already.
My remark was obviously not bound to the particular media format like CD, it was merely an example
I got an idea, i don’t know how to implement it!! So,
So we create some kind of menu, by right clicking there would be two option, Install or Run, if we select run the warning is showed (can be anything though 
). So when you run it is still mounted but when you close the app the mounted partition is unmounted.
The problem is how will it store userdata? according to my knowledge snap files are real only!
Run - Mount/Close - Unmount is a base of this idea. Run need to be default option that not need right-clicking to do, ‘install’ can be there though. But there is exception for cases when .snap contains more than one app and don’t have ‘main_application’ (can be named everyhow) in snapcraft.yaml - install option by default and running impossible (or possible to select what to run, I have no idea what will be exactly).
Up. Any news about this?
no news about this in particular, no.
This and another topic (I’d link it but it was a few days ago and I don’t remember the details) has me thinking that we want a way to let the sysadmin flag external media for .snap storage. Something like snap attach /dev/sdb1 which would add a snap directory and perhaps some metadata, such that from there on if that device is present, those snaps are present, and if not there the snaps are either listed as “broken” or disappear (the former is probably less work).
Perhaps.
Hello,
My need may be a useful example:
Libre Office has a powerful command-line interface for converting files, e.g. .docx → .pdf in a “headless” mode, i.e. without using the GUI. I want to install it on a webserver where I do not have root access.
The webserver does not have libX11 etc. etc. installed (it’s a webserver) but LibreOffice requires all those libraries to work. So installing a snap, which is supposed to be self-contained, seems like a perfect solution.
Except. Without root access on the webserver, I can’t use a snap.