Hacker News Reader

Comment by psanford | Hacker News Reader

I really like the idea of snaps. I really don't like a lot of the execution decisions around them.

Snaps break debain's stable release model. They allow upstream to ship updates outside of the normal 6 month ubuntu releases. There are times when you might want this, but it should be opt in not mandatory. I thinking specifically of lxd which is only shipped via snaps.

The snap store's trust model is confusing. Its hard to tell who is making the packages and how they are sandboxed. If I'm going to install a proprietary piece of software I want to know exactly what it can and can't do. Lately I've been using firejail when I need to run things like this.

And now for a minor complaint that also feels most user hostile to me: why do the snap developers think its ok to require a non hidden directory in $HOME? Seriously my home directory is MINE, if you have to store application state there at least have the decency to do it in a hidden directory.

View on HN

>And now for a minor complaint that also feels most user hostile to me: why do the snap developers think its ok to require a non hidden directory in $HOME? Seriously my home directory is MINE, if you have to store application state there at least have the decency to do it in a hidden directory.

4 years old now.

https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053

Unrelated to Snap, but on Windows, trying to use the My Documents folder for your actual documents is frustrating, because a huge number of apps and games like to use the folder for all sorts of nonsense, instead of using %appdata% like they're supposed to.

At least on Windows you can mark folders hidden without having to change the name. (i.e. the app that created the folder will still find it)

Create the file ~/.hidden and with the line "snap". It will then be hidden from your file manager.

dot prefixed files is a kludge that is now a standard rather than an actual hidden attribute like on Windows/NTFS.

The actual heritage is when `ls` was written to exclude .. (dot dot) directories from it's listing the code literally just had the logic to exclude any files which had a dot/period as its first character. Later operators exploited that bug/feature to create items with a dot prefix to make those files and folders hidden. Eventually this became convention.

Whereas systems released more recently understood the need to have a hidden file attribute so made it a first class property.

I do love POSIX and often the first to defend some of Linux or BSDs idiosyncrasies but if there was ever anything that was worth someone saying "I know we've always done it this way but it's shit and it's about time we implemented a proper solution", it would be the dot prefix kludge. (I also know it's easier said than done and would take years for all the tooling to catch up)

If it's still visible in ls, it's not a fix.

Make an alias that adds ls --hide the same way you do for ls --color.

The issue is that you have to continue "fixing" lots of individual utilities. In addition to your file manager and `ls`, what about tools like `fd`/`rg`/`ag` (requires adding `snap` to `~/.ignore` or `~/.gitignore`), `fzf` navigation in the terminal (may require updating `FZF_DEFAULT_COMMAND`), "open file" and "save file" dialogs in non-GNOME apps (like Zotero), and so on. The `snap` directory keeps popping up in new places, and discovering all the different ways to hide a non-dot-file is exhausting. In contrast, adding that initial dot to the `snap` directory would avoid the problem entirely.

I have still been using `snap` for the past year, and have mostly been happy with it. It works well for apps like `spotify` and `zotero`, it's a better solution than `ppa` for third-party software, and I like that it tries to introduce a permission model. But not following the dotfile convention is annoying, and not prioritizing a search-and-replace of `~/snap` to e.g. `~/.snap` in the code after four years is strange when this is their most upvoted bug.

This would be nice if it was easy to toggle showing hidden files and hidden files wouldn't show up by default in all folder listings.

Of course you do have system files, which are hidden from all standard folder listings, but aren't usually used by software, presumably because they're too damn difficult to find again (although I really hope google drive realizes at some point that desktop.ini is supposed to be a system file, not merely hidden).

AFAIK one common reasoning is that it is a writable folder that is easy for the users to find when they need to contact support.

This behavior is such normal for all the apps (especially games) that at one point I thought it was a specification.

I feel like in 2000 or before, My Documents was the "home" folder and you were supposed to put your own subdirectories inside of that. Might be wrong about that though.

The problem in Windows' case is that there never was a clear specification regarding what kinds of files should go where. The directory structure and environment in every version of Windows is a little different, and it's hard to write an app (or an installer) that does the right thing on all of them.

As long as you follow knownfolderid nothing has changed since Vista, or CSIDL constants go even further back.

https://docs.microsoft.com/en-us/archive/blogs/patricka/wher...

https://docs.microsoft.com/en-us/windows/win32/shell/csidl

.NET has its own set which is also very old and goes back to .NET 1.0 (as old as Win98) https://docs.microsoft.com/en-us/dotnet/api/system.environme...

I think the combination of complexity and obscurity of those two links reinforces my point more than it refutes it. There's a reason why basically no one gets this stuff 100% right, including some of Microsoft's own first-party applications.

Does anybody know why lxd is shipped via snaps? It's kind of confusing, because it seems like snap should be built on top of lxd. If you're running a container inside of lxd inside of snap, does that mean it's two layers of sandboxing?

My understanding is that the actual features needed to provide containers are part of the Linux kernel. What LXD provides is tooling and a daemon running as root that are used to manage containers. There's no reason why these can't be part of a snap, it doesn't introduce another layer of sandboxing for the actual containers.

(That said, I would still prefer that they not be.)

> Snaps break debain's stable release model. They allow upstream to ship updates outside of the normal 6 month ubuntu releases.

In fairness, I think that's the point, just like RHEL streams.

> There are times when you might want this, but it should be opt in not mandatory. I thinking specifically of lxd which is only shipped via snaps.

Yeah, decent idea, poor execution. Especially for system/infrastructure software like LXD. I want a stable kernel, a stable glibc, a stable LXD/Docker/k8s/whatever, and then on top, bleeding-edge applications that will not break the world if they autoupdate at random to a less-tested version.

I don’t have any experience with snaps so this is all new to me. Snaps install software at a system level right? Why on earth would there be anything in a user home directory? What if you have multiple users? Does snap get confused?

Snaps run out of a squashfs partition, but the app may save app config in the user's home directory (if they request the HOME interface, I believe).

After fighting with node, vlc and ffmpeg snaps not working reliably, I had to add a warning for my PhotoStructure users on Ubuntu to avoid those packages (and how to install them via apt).

I agree with a bunch of people here: snap promises some great features, but in practice the horrible performance, additional resource consumption, and spotty reliability led to me actively avoiding snap packages and looking for an alternative installation.

Snap stores user-specific application data in /home/user/snap/ folder. Like when packaged application wants to write into $HOME, snap gives it some sub-folder inside /home/user/snap.

Ah ok I understand now. Sibling comments reference the MacOS Library and *NIX ~/.local approaches. Both of those seem to make a lot more sense. Is there a config for Snaps to store user data in a different path, like ~/.local/snap/?

No; they use some magic with security policies and mounts so $HOME/snap is hard coded. Some of the early comments in that "4 year old bug" linked here explain it.

Most likely they download some things when you first run the software. This pretty common but usually opaque to the user due to it being in .local or .cache.

I've always liked OS X's concept of the Library folder, particularly back in Snow Leopard when it wasn't hidden by default.

Applications need a place to save state, and you don't really want it to be hidden, because sometimes I as a user do need to change it manually for any number of obscure reasons. So you make a subfolder that's designated for apps to write to.

There's no good way to put this into the existing Linux model though. All you'd do is add yet another standard a la https://xkcd.com/927/

You as a user can still access hidden directories. Most new applications are nice enough to respect the XDG specification.

Oh, for sure, but it's mildly annoying.

Especially when a . is used to make the directory hidden, because I can't unhide that specific directory without changing the name apps expect.

You can press cmd-shift-g to open a "Go to folder" prompt which has some basic tab completion. This also works in file selection dialogs. Hopefully this saves someone as much time as it has saved me over the years.

I get into the Library folder by doing: cmd-shift-g -> ~/Library -> enter

Cmd-shift-. will show hidden files and folders in the Mac Finder before Catalina.

In Catalina, it's now Cmd-shift-fn-.

https://discussions.apple.com/thread/250756110

Whoa, even better tip. Thanks!

What? Of course you can!

$ ln -s .hidden not_hidden

It's that easy. Really.

Well, that's a symlink. It's a good idea, and something I should remember if I ever do start using Linux again—but the downside is that if I do need to temporarily enable hidden files, I'll see the same directory twice.

I'm being picky, I know! But I still think the Library approach is cleaner. (Again, back when it wasn't hidden by default!)

Not exactly the same, but the closest Linux equivalent that's semi-widely used would probably by ~/.local

And the problem is gigantic, programs in general are completely broken - why does my entire system have to be compromised because I decided to play Catan. We need the iOS/Android model for permissions on desktop.

> We need the iOS/Android model for permissions on desktop.

This model is terrible. OS asks up-front: program wants permissions to do A, B, C, X, Y, Z: grant/refuse? You the user decide that the program should not be allowed to do X, so you refuse. Now the program will not run at all. That's about the worst design possible. A 10 year old can brainstorm a better design within a few minutes.

Investigate prior art:

    man 7 apparmor
    man 4 capsicum
    man 2 pledge

At least on recent Android versions the apps only ask for permissions when they actually need them, not on install time, and you can grant/refuse individual permissions.

This is also how iOS has worked since forever. I think it's helpful, but not that helpful.

In practice, apps that want access to my contacts usually keep asking for access every time I try to do anything, until I eventually either relent to make the prompts go away or click allow by accident.

And that's me as a computer-enthusiast. I would bet money most normal people just hit allow always. Because it's easier.

The missing piece is "refusing" permission should instead give dummy data: an empty address book, a random location, etc. Better would be profiles: Full, Basic, Public, Anonymous, etc

I'm not necessarily against this but there are some pretty major UX implications for non-tech users who don't understand what's going on. "Who is Foo Smith and why does this app think I know them?"

In Android 10 you "only" need to deny a permission 3 times until it is auto-rejected without a prompt.

Some apps even try to circumvent this system by showing a "help" screen with instructions on how to re-enable the permission manually, but I only saw this twice.

> At least on recent Android versions the apps only ask for permissions when they actually need them, not on install time, and you can grant/refuse individual permissions.

Still, this is not practical enough. A true user-centric strategy would be to offer "mock-permissions" to an app, so that if an app says that it needs to read your home dir, you grant mock permission to the app, and it sees an empty home dir, not yours. From the point of view of the app, it should be impossible to know if it has been granted the real permission or just a mock permission.

Do we really?

People still just click "allow" on everything. They get tired of getting questions asked, and just want the program to work, so they don't even read anything and just tap tap tap until it lets them through.

Access your files? Sure. Access your documents? Whatever. Send data off to our corporate data vacuum? Whatever, I need to see what my face will look like with an AR moustache!

Also, are you running Catan as root or something? How is it able to compromise your whole system?

I agree with you on everything but the last two sentences. An unprivileged user account still has a ton of power in a modern Unix or Windows system, because the security model doesn't really solve this problem: https://xkcd.com/1200/

Thats one thing that snaps are trying to do. I personally prefer firejail for application sandboxing and permissions but then you have to be extra careful how you install the application (dpkg post-install scripts have been known to do sketchy things) and you have to make sure you never accidentally run the application without firejail.

Reply on news.ycombinator.com