nobody says it can not …
… but if we wanted to copy it we would have called snappy “mac-os-like-packaging” instead of snappy, snaps or snapd 
snaps are not intending to copy MacOS …
First of all in mac you can run app from everywhere. In linux now you need to ‘snap install (–dangerous) …’, when in mac you just need to extract it from .dmg.
Yes but as stated the work required to get snaps to run from anywhere (well, to be able to do so easily with a snap command and for it to actually work) would be a lot. Just changing where snaps are put in the system won’t get portable snaps working and it would be quite hard to rework that in the first place.
snaps are not intending to copy MacOS
But they can in some things, not fully as getting away from /bin, /usr, /var, /lib, etc... in package, but in installation and running ways.
But snappy is just trying to do what works, rather than trying to copy any particular existing way of installing programs on any other OS
I know that moving it into different dir don’t change anything. It’s just more pleasent for me to see all my installed apps in one directory that can be easily get from “the top”, and not from an 3 folders away from it. So it be enough for me for some time that they will work on ‘portability’.
As one man said ‘OS X maked humans for humans, and Windows maked pigs for pigs. Linux is just shit’ - you know, linux is really shit for typical user with that hard understanding of things. Linux is need to be simplier for anyone that got to use it, as mac does perfectly (there is some exceptions, but rarely). So done atleast this in good way, please.
did you try “ls /snap” ? it will just show all installed snaps
(like “snap list” will)
1 Like
Actually the common complaint is that /snap (which allows you to see the full list; oh and ~/snap) is not Freedesktop compliant (or that’s what I read anyway, I think). I can’t remember what the compliant directory would be but it wouldn’t be top-level!
It’s all the mounted snaps, not installed.
I mean it’'s a apps folders, not original apps archives with ‘.snap’ format.
this is the same … installing a snap implies it gets mounted there … so all installed snaps show up in that dir.
I did not finish my comment a bit, upd.
Putting things in a top level directory has a lot of a consequences, one of which is that you’re breaking people’s expectations. Lots and lots of applications are built around the FHS layout, including things like backup applications and whatnot. There’s an expectation that any other directory at the top level, if it exists, is private and up to the system administrator, so you can collide and break things.
And note that /snap does not exist on all distributions. snap list is a far better way to see what’s installed.
In Linux, this is possible… As long as you don’t want kernel-level security. This is possible in AppImage because they deliberately do not handle security. Snaps are installed so that it can generate the interfaces, register the security profiles (currently only AppArmor, but could be SELinux or SMACK in the future) and set all that up in a sane way.
Flatpak sort of works around this by having a highly restricted scope (desktop applications) and leveraging bits that can be configured sort-of through userspace through Bubblewrap, but they require installation so that it can be registered with the per-user AppStream database (local user install) or the per-system database (system wide install).
Snaps do not have the luxury of being so restricted in scope, so we need to pull out all the stops to make sure confinement works.
Then it’s propably can be moved not to top, but to home? It’s a top of user’s own place.
Okay, nevermind. Dir, that ‘snap install’ using is not so important now, but “running from everywhere” much more… atleast for me. So where can I get next release planned features list, in a case it appear there?
As Ogra said, portable snaps is not going to happen anytime soon because it would be too much work (and, as Conan implies, you may lose the security of snappy in the process). However you can look out for 'in progress: snapd <version>’ posts in the forums.
it would be too much work
Yes, but as snappy is so young now, it needs to fix that soon. Because if everyone going to use it then will be hard to implement big changes like this.
True, so it may be that snappy never supports portable apps and you have to use AppImage to get that for the Linux desktop.
Changing format not too good idea. It’s a problem with snappy itself, because it costs much space for one app. That will happen to low-popularity of it, if noone going to implement some workaround, like feature that allows you to move apps to external devices or hdd partitions.
On old pc’s with low space it’s going to be difficult and useless to use snap.
This is not a big change, it’s just a change that is not critical today. There are way more critical things we are working on. 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.
Snapd is FOSS, you can help out though if you are a programmer or not there are plenty of things that need love. We need code reviewers, we need packages, we need people that document existing features, we need people that test beta releases, we need people that work with other users that know less than oneself. There’s always something interesting to do.
Please help youself and everyone else out by thinking in terms of actionable activity. Be active, be smart and lets build the best software packaging system on the planet.
2 Likes