281–290 of 534 posts
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.
One thing I’ve been thinking about is that it would be nice to tag files with the program that created them. Aside from the clutter in my home directory, I have a lot of files that I have to guess as to where they originated from based on metadata like modification timestamps or permissions, but it would be nice to see something like “~/.config was created by some-tool”.
>One thing I’ve been thinking about is that it would be nice to tag files with the program that created them. Isn't what you describe basically the file extension? Not so much what program created the file, so much as what program is meant to handle/open the file.
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.
Earlier quoted context omitted.
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!
Python did this until very recently too. Windows has a problem, because people expect to use those programs in the command line and the %PATH% has a size limit and is a bit difficult to set-up properly.
If you do deeply nested paths (as npm used to do) then you can run against the old MAX_PATH limit that limits paths to 260 characters, but the correct solution is to either choose a flatter directory structure or use the newer APIs that allow paths with 32,767 characters.
Earlier quoted context omitted.
Also on macOS, where [~]/Library/ApplicationSupport is the designed and recommended place to store config files, logs, preferences and all kinds of persistent data, the home directory still gets cluttered. It's a laziness issue, it won't be solved solely by making is easier to access the right locations on each system/platform, but that would be a step in the right direction.
At this point the right solution is to just not allow applications to choose. Give each their own view of the file hierarchy but keep all the crap they spew out in a location obviously related to them from the user's view of the file hierarchy.
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).
Here you are referring to separating the config and data? Is this actually a problem? I can see how for things like games it would be valuable to have a special location for thing like saves games, like how you can move the roaming save for minecraft from a computer to another; but I never understood the net gain from splitting the application files in config/data
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…
I don't understand the whole Snap thing. Not a single snap has ever worked in any of my computers in the past 5 years (I've tried maybe 5 or 6), and they always say they'll add themselves to the system. Add where? Where are these beasts hiding?
Earlier quoted context omitted.
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!
Python did this until very recently too. Windows has a problem, because people expect to use those programs in the command line and the %PATH% has a size limit and is a bit difficult to set-up properly.
I also have C:\CMD for my own batch files.
Every single program should be fully contained in its own directory including all the settings,logging,configuration etc...
No touching of any common resource or repository.
It should be enough to delete single tree to fully uninstall program with all the garbage it created along the way
This isn't just a Linux problem. In Windows, the users /documents folder is polluted in exactly the same way these days.
It's often worse on Windows, since dotfiles aren't hidden and meny dev tools assume they'll be running on *nix even when they support Windows. https://imgur.com/a/Im6G20B capture from my windows box of my $HOME.
(I never used MacOS, but from the article it seems not the case for MacOS?)
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.
It’s a shame Unix doesn’t have a chhome utility that functions like chroot.