Dziękuję! Your insights are very much appreciated. I learned something new.
> - how to represent /data for security, is it equivalent to the home > interface or do you want to special-case it? I'd like to _assign_ it to some predefined interface at least. Special cases tend to make things more complex which usually doesn't help security. > - what if the location is not /data but actually something that > already exists in snap view? say /usr/lib, after all, it is configurable > so the user may, without knowing the consequences, choose to do that. Hmm, aren't developers allowed to limit the number of choices a user has, though? So what's the trouble in failing to mount a snap which has such clashes? Personally I'd write _that_ off under "fail early" and be very happy with it as a user. At least this way _snap_ would show a clear error rather than VLC showing some error which doesn't make sense at face value. And this way it's likely I would have caused issues anyway (i.e. by specifying an illicit path that was already present in the snap), so by the system preventing me from doing it, no harm would have been done, right? And it's better than figuring out some time later that something fails, just because the VLC running as a snap doesn't have the same idea of the file system I have (which is by purpose, I understand, but which isn't obvious without some additional reading -> user perspective). So long story short: the ease of use that the snap packages supposedly bring, falls apart quite quickly if you run into an issue like _this_. And seeing it without knowing implementation details (like you!), the VLC instance has presumably no idea that it's running in as a snap and possibly shouldn't know it either, whereas as a user I am left to assume that VLC is to blame (which, it turns out, it isn't). Hope that clarifies a bit better why I think this is a usability/UX issue. With the --classic option not working, but being touted everywhere as a "workaround" for the issue and with VLC fully moving to snaps, where does that leave me as a user? I get that there ought to be a balancing between security and convenience. But convenience comes in shades, whereas the refusal of VLC to play stuff is binary (either it plays or it refuses to play outside of hardcoded locations ... but with an error message that doesn't _really_ help me as a user; and I had looked into snaps before due to LXD). > The implementation is evolving. As we gain more kernel features and > learn of creative ways to use existing features it may become possible > to do what you want. Right now we are where we are. Yep, I'm an avid user of bind-mounts already, so it's not a huge deal for me. However, some tools do misbehave with bind-mounts, so items show up multiple times in GNOME despite x-gvfs-hide mount option. And _that_ - while not to be blamed on snap or VLC - is an issue that means that there are now already two aspects that force me to adjust the way I work. > I hope you understand where we are coming from. There are lots of > use cases and everyone cannot be supported at the same instant in > equal amount, as we have finite resources. Absolutely. I have the same for the FLOSS projects I maintain. So please don't take this personally in any way. Please rest assured if it came across this way it wasn't my intention. The only intention was to provide a user's perspective. With best regards, Oliver -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1643706 Title: snap apps need to be able to browse outside of user $HOME dir. for Desktop installs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1643706/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
