271–280 of 534 posts
I have been fighting this but I gave up: people just don't care or are somewhat opposed, even when presented with a backword compatible patch. Now I just mount the home directory with rewritefs and try make the mess more or less compliant to the spec. It's not ideal: it's a hack and it causes a performance hit but I can be at peace in my ~.
Earlier quoted context omitted.
That’s what the article talks about. How applications should use $XDG_DATA_HOME, $XDG_CONFIG_HOME and $XDG_CACHE_HOME and some defaults if they’re not set.
I'm not seeing it. Where does XDG define when and how an app should use: /home/user/Documents/ /home/user/Downloads/ /home/user/Pictures/ /home/user/Videos/ Let me know what I'm missing.
To me, the real problem is not the dotfiles, but the regular (i.e. non-hidden) files that applications surreptitiously create in my home folder. (Which the author does mention as being particularly bad.) dotfiles in the home folder are not a new thing on Linux (e.g. .bashrc, .profile, .emacs, etc.), even if it would be better if more applications used the XDG folders. And if I don't see them when I "ls", they don't b…
This is particularly weird, since click (snap's "predecessor" at Canonical/Ubuntu) was fully XDG compliant, even encouraging developers to separate data from cache etc. (unlike flatpak which just dumps everything in ~/.local/share/[...], though that is still infinitely better than using ~/snap).
I have huge amounts of cache files in both .cache and .config. It's supposed to make my life easier by being able to backup .config and dump everything. but in reality this doesnt happen.
Backing up .config for just the user defined configs is a massive PITA. you have to put so many gitignore exceptions and I'm not even talking about the gigs of data all the chromium derivatives put into that folder.
Earlier quoted context omitted.
Same for the default gopath. That was horrifying the first time. At least you can override it.
On Windows Golang defaults to install to C:\. Had no problems running it from Program Files instead. It's crazy that a new programming language cannot follow decades-old conventions!
To me, the real problem is not the dotfiles, but the regular (i.e. non-hidden) files that applications surreptitiously create in my home folder. (Which the author does mention as being particularly bad.) dotfiles in the home folder are not a new thing on Linux (e.g. .bashrc, .profile, .emacs, etc.), even if it would be better if more applications used the XDG folders. And if I don't see them when I "ls", they don't b…
The real problem is that any app I run accesss all files I own with equal permissions. App1 and App2 shouldn’t write their data to my home, or read each other’s data, or, please, be able to write each other’s data. A video game can read my tax forms. WTF. Mobile & tablet OSs solve this. Everything has to follow. Until then, basically every app should run in a docker container. Then it can do what it wants.
But -- speaking from experience -- they are painful to use; most users prefer convenience over heightened security.
Earlier quoted context omitted.
It's senseless to store files that don't have user-facing meaning in My Documents. I know games that use it varyingly for web caches, shader caches, binary config files, debug logs, Lua scripts, downloaded mods, and even executables . And while arguably most gamers understand what save files are , they can't be double-clicked to open them, so I don't consider them documents (Maybe this is pedantic). All this kind of…
Save games is a poor example. Users often need to back them up. Backup systems often include Documents by default but not AppData. Files in AppData are hidden, and you would not expect users to find them. Further, many save games can be opened with a text editor just fine :)
End developer is inexperienced, temporary, not valued and hence his deliverables
Earlier quoted context omitted.
There's an entire research field dedicated to the information flow control which could solve just that (if it were actually used). In my research team, we used a tainting tracing mechanism to understand the behavior of malware. Basically, we installed a malware on a clean phone and we then traced all information flow originating from the APK to processes, to files, to sockets, etc. It helped reverse-engineering the m…
I'd love something like this on program level. Given contents of a variable, I'd like to know where they came from - which pieces of code contributed to the result. I'd also love to be able to mark a piece of data, and see what code touched it or derived new data from it. A programming equivalent of injecting radioisotopes into the body.
To me, the real problem is not the dotfiles, but the regular (i.e. non-hidden) files that applications surreptitiously create in my home folder. (Which the author does mention as being particularly bad.) dotfiles in the home folder are not a new thing on Linux (e.g. .bashrc, .profile, .emacs, etc.), even if it would be better if more applications used the XDG folders. And if I don't see them when I "ls", they don't b…