.snap is a good format, but it lacks of portability. I’m not saying about cross-distribution but a cross-disk executableing. So if I want to run and store app on USB Flash drive rather than installed in my system (it costs a big space, considering that all dependencies go with app archive), I’m going to be dissappointed that I cannot do that. Which can not be said about Apple’s NEXTstep (Then OS X) .app format, I can run apps from everywhere and it don’t need to necessarily be extracted (installed) in to system /Applications (/snap) folder.
It’s a great problem for me, as I only have 512GB hdd with almost all space is busy with games, pictures, large Windows software and other downloaded stuff.
.snap need to be as simple as OS X’s .app. And that’s true, such a good thing surely need to be stealed. Start of it already is done, now linux apps can be installed without any compilation with dependencies things, that end-user not need to know. Now it need’s to be even simplier (sound’s like we in Russia would say ‘Simple as for downs’) - Copy == Install. Don’t say that about apps that you can install from terminal using ‘snap’ tool, but that you can download from the Internet. Though, you can download only it from terminal too - so about that. /snap dir is no need to be root, because it’s my apps and I can do anything with them without need to be administrator - copy/move/delete. What if it been moved to user’s home folder? Then my apps is really “my”, and others users of this PC don’t going to know what I have installed - this is a privacy thing too
And original /snap folder can be leaved for system-oriented apps, as Nautilus or entire Gnome Environment.
In short words: As .snap package costs a lot of space we need ability to store it on removable drives. Running of this package in my understanding is just double-clicking on .snap file, then it’s virtually extracted to Ram and loads from there. Simple but comfortable OS X style. Is this possible?
This is something I was thinking about some time ago, I was planning on putting the squashfs file on a CD/DVD drive. Since snapd does not need to copy the file anywhere to install it (after all, we just mount it) we could devise a scheme where if a given removable medium is present a given snap may be mounted, at other times it is installed but inactive/ejected (terminology TBD).
For certain type of software (games and typical apps) that don’t need background services to operate this could be easy/natural in user experience. We don’t plan on doing any of this work right now but it’s well possible to do.
In short words: As .snap package costs a lot of space we need ability to store it on removable drives. Running of this package in my understanding is just double-clicking on .snap file, then it’s virtually extracted to Ram and loads from there. Simple but comfortable OS X style. Is this possible?
Note that this is how all the snaps are used today. Snaps are not uncompressed/copied anywhere at all. They are mounted from a given location and decompressed block-by-block on demand.
Note that this is how all the snaps are used today. Snaps are not uncompressed/copied anywhere at all.
That’s not how they work for me, did I miss something? I need to snap install --dangerous <snap location> (then it extract .snap somewhere in /snap) first and can’t just do snap run <snap location>. Nautilus suggests me to open snaps with ‘Установка приложений’ (‘Applications install’ or something) too.
But snap install installs the .snap. to /snap, right? It would be nice (though, as Zyga says, not a priority) if one could just use snap run .snap to run a snap without installing it to /snap?
So why there is no some snap instarun <.snap> command, that will temporary create symlink to my .snap in that directory, mount and then run it?
UPD: Even if there is many apps in one package, it’s can be done to have exceptions for ‘one app’ .snap’s and for .snap’s that have ‘main_application: app name here’ in snapcraft.yaml. In the end some snaps will work as .pkg installers and some like just typical .app’s in OS X.
while doing a fuse-mount of a squashfs to a random place is surely not that hard …
changing snapd, snap-confine, the whole apparmor profile generation, namespace-mounting and seccomp profile generation etc might be not that trivial… and since you touch existing code there is also regression potential so there needs to be a lot QA as well, to not break existing installs …
snapd does not get any features without proper planning either, so there would also be a planning phase adead of the implementation time …
there are many snaps that ship and require services, that needs to be taken into account, do interfaces work out of the box or do they need to be changed etc etc … this isnt as trivial as you might think
Yes, but appimage is a really ‘one’ file, that is bad for debugging app code in parts. In OS X app is a folder that contains everything app is need to work, not a file that you cannot even look what contains.
Well clearly the work for making snaps portable is not high on the developers’ priority list so eh. It’s a niche use-case (having portable apps which are debuggable in parts is a very niche case!) so I guess that’s fair enough.
Don’t breaking existing installs cannot be done with that reworking. Ugh… or part of it. Now installed snap apps containing in /var/lib/snapd/snaps and you can run any app that have that .snap’s entering it’s name in terminal, but then you need to run they from a specific folder. Let’s go with /Snaps - move /var/lib/snapd/snaps to it, and mounted packages need to be moved from /snap to /mnt/snaps, for avoiding confusion.
And with that OS X styled folder, I would to forgive unimplementation of snap run <.snap>
Because macOS is absolutely get better with apps system than linux or windows. What is bad with copying good things? macOS and Windows copied ‘many desktops’ feature from Linux, so why Linux can’t copy OS X apps system?
