←back to thread

Grayjay Desktop App

(grayjay.app)
512 points pierrelf | 3 comments | | HN request time: 0.001s | source
Show context
bisby ◴[] No.42474981[source]
Launching the Linux release and noticed in the logs:

Directories:User Directory: /home/bisby/Grayjay

And there is a directory there now. I absolutely hate having stuff automatically create anything in my home directory like this. Ideally, this should be following XDG directory guidelines on linux: https://specifications.freedesktop.org/basedir-spec/latest/

replies(4): >>42475304 #>>42479118 #>>42482018 #>>42483636 #
koen31 ◴[] No.42475304[source]
Grayjay dev here. If you want it to use your user directory like other apps, just remove the file called "Portable". Keep in mind that it just uses your working directory to write files otherwise.
replies(7): >>42475423 #>>42475680 #>>42475733 #>>42475939 #>>42475958 #>>42476022 #>>42476313 #
bisby ◴[] No.42476022[source]
Sorry, to be clear, I dont wan't Grayjay data in my user directory AT ALL. Portable is basically what I want, I'm just very untactfully dropping feedback about where the data is placed.

Even with the "Portable" file, it creates a directory `/home/bisby/Grayjay`. I don't want that. No app should ever put a file or directory directly in `/home/bisby` without me asking it to. The Linux standard for "where should an app put it's files" is defined the XDG spec that I had previously linked (https://specifications.freedesktop.org/basedir-spec/latest/).

The summary is that user specific data should live in $XDG_DATA_HOME and config should live in $XDG_CONFIG_HOME (and various other things like $XDG_CACHE_HOME). If these values are unset, there are predefined places to put the files (eg, data in $HOME/.local/share or config in $HOME/.config, cache in $HOME/.cache).

This puts all the Grayjay data in places like /home/bisby/.config/Grayjay (instead of /home/bisby/Grayjay) which is nested away inside a hidden directory and structured in a consistent way.

This would be the equivalent of putting data in %AppData% in windows instead of cluttering someone's "My Documents" (or whatever the modern equivalent of that is).

Some of the Linux decisions feel a bit like linux is a complete afterthought, but included because Linux users tend to agree with the FUTO philosophies. That is a reasonable thing given the Linux market share, and for "Build Version: 2" that I'm seeing the app info, I'm grateful that linux is included this early. This looks like it can probably replace freetube for me. However, it would go a long way if things are done to make sure they are done the "right way" on Linux (ie, on packaging and on directory specs).

Thanks for the work you've done on freeing up the web.

replies(3): >>42476055 #>>42477386 #>>42478673 #
1. gf000 ◴[] No.42478673[source]
Well, ideally I would like the OS solving this problem by simply chrooting/sandboxing apps to their own little worlds, with a proper API giving them optionally a way to the user's file system, similarly to android and iOS.
replies(2): >>42479201 #>>42479359 #
2. doodlesdev ◴[] No.42479201[source]
That is possible on Linux [0], but this kind of separation comes with its own can of worms. However, if your only worry is access to folders, Flatpak applications keep all of their data in a folder away from your home directory and use "portals" to access your system [1]. The security of the sandbox is debatable [2], but I would say if your biggest goal is containing non-malicious but badly behaving applications from messing with your system, then it's a very good solution, given you are comfortable with using Flathub (as most distributions won't build Flatpaks) and with the performance/integration impact this distribution method has.

[0]: https://docs.flatpak.org/en/latest/basic-concepts.html

[1]: https://docs.flatpak.org/en/latest/sandbox-permissions.html

[2]: https://flatkill.org/2020/

3. isametry ◴[] No.42479359[source]
…and macOS. Sandboxed Mac apps get their own little home directory in `~/Library/Containers/`. To access anything else, they need to ask through system APIs.