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
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.
2 Likes
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.
1 Like
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?
3 Likes