7 ms·

I hate having a polluted home directory, especially when an application thinks it should get a non hidden directory in my home! The one that upsets me the most

by l72 2y ago

I hate having a polluted home directory, especially when an application thinks it should get a non hidden directory in my home! The one that upsets me the most is the default directory for go modules `~/go`. This frustrates me so much. I refused to install any go apps or use it for development for years. I've unfortunately had to give in, and it can at least be overridden by setting `GOPATH`, but it is a terrible, terrible default.

Aardwolf 2y ago
Same thing, wish that from the start unix had some standardized "applications put everything they want here" home directory that's separate from the "here user chooses to put their own files" home directory
- yencabulator 2y ago
  At the start, unix commands didn't need or use configuration files. The world really was that simple, for a while. Now we have even simple desktop apps, that I have not changed a single setting in, insisting to write a whole directory tree of whatever data in my home. Or absolutely moronic things like ~/.config/VSCod*/*Cache* -- really, cache in config?
  - Aardwolf 2y ago
    Or ending up with multi-gigabyte ML models somewhere in deeply nested hidden directories in your homedir
sph 2y ago
The worst offenders are CLI tools written by people on Macs that do not respect XDG, because it's not a thing over there. So every tool gets to pollute your dotfiles with its own stupid directory. .rustup, .mix, .npm, .yarn, etc. But polluting your home directory like ~/go, without even the decency to hide it, is extremely rude and offensive.
- sevagh 2y ago
  >But polluting your home directory like ~/go, without even the decency to hide it, is extremely rude and offensive. Counterpoint: I actually like having visible directories, versus having to figure out where in /usr/share or /usr/local/ or ~/.local or /var an installer chose to sneak their files in. I got used to it and in HOME I put some of my manually installed tools like `AMD_AOCL` for the AMD AOCL libraries, `Android/android-studio` for Android Studio, `intel` for IPP/OpenAPI, etc. Don't want it anymore? Easy rm -rf, no need to go digging for where it could be hidden.
  - KTibow 2y ago
    In theory, all applications following XDG would also solve the problem, as it has only 1 configuration directory. (Although I admit some apps use the data directory which brings it up to 2)
    - SAI_Peregrinus 2y ago
      XDG isn't enforced, it's voluntary. So there will always be lots of applications not following it.
  - AlecSchueler 2y ago
    The point of XDG is to take the guesswork out of it by having applications follow your stated preferences.
  - megadog3 2y ago
    "I actually like having visible directories, versus having to figure out where in /usr/share or /usr/local/ or ~/.local or /var an installer chose to sneak their files in." You seem to be mixing together two concepts here: 1. The files created by the installer, which are handled by the package manager. I can consult my package manager for files created by a specific package: pacman -Ql package_name. 2. The files created after installation (user preferences, plugins). The program should follow the XDG specification.
    - 2y ago
cesarb 2y ago
IMO, the GOPATH itself is a terrible design. It makes you mix together things from unrelated projects in the same directory structure, instead of each project having its own independent directory structure, like on every other programming language. The GOPATH design goes so much against the way I organize my projects, that it's the main reason I have never got interested into learning Go. Perhaps this design makes more sense for those who prefer to keep several unrelated projects together in a single monorepo, but that's not my preference.
- softirq 2y ago
  GOPATH actually made me realize that the ~/src/$host/$owner/$repo organization structure makes a ton of sense for every project and as long as you organize all of your languages into this one tree, everything just works.
  - sureglymop 2y ago
    Can you expand on this a bit please? What does $host mean? Why would I need that for a purely local project that is only created for my own use? And what about grouping projects? E.g. "personal", "work", etc. And where in the structure are languages? Is that the overarching directory?
    - bheadmaster 2y ago
      > What does $host mean? In Go parlance, it would be the remote host where the repository is hosted, e.g. github.com, dev.azure.com, golang.org, etc. > Why would I need that for a purely local project that is only created for my own use? If nobody else is using your purely local project, and you're sure nobody will ever use it until the end of time, then I guess you could just use "~/src/$HOSTNAME/$USERNAME/$PROJECTNAME". Otherwise, it would be wise to setup a remote repository ahead of time. Go has a strong opinion that, in this day and age of distributed computing, projects should be online-first, so they can be easily used as dependencies. One of the nice consequences of this opinion is that Go dependencies can just be specified in the import statement - e.g. using grpc dependency is just: import "google.golang.org/grpc" No need for pom.xml, requirements.txt, cmake.txt, or any other kind of dependency configuration. It just works (unless it doesn't, like with private repositories, in which case it requires some exotic configurations in ~/.gitconfig or ~/.netrc, but that's a whole other can of worms - for most public repositories I've used it works flawlessly). > And what about grouping projects? E.g. "personal", "work", etc. Assuming you only use one repository hosting service and have one username, all your personal projects would be under "~/src/$PERSONAL_HOSTING_SERVICE/$USERNAME/", and your work would be under "~/src/$WORK_HOSTING_SERVICE/$WORK_ENTITY/" or something like this. > And where in the structure are languages? It isn't. That's either a bug or a feature. If it's a bug, you could just do the whole thing by language, e.g. "~/src/go/", "~/src/java/", etc.
bmacho 2y ago
Pro tip: don't put your stuff in your $HOME directory. $HOME is for applications to pollute. Put your stuff literally anywhere else.
- computerfriend 2y ago
  $HOME is where my terminal and file manager start. It's not reasonable to give up on this prime directory real estate.
  - bananskalhalk 2y ago
    That's only two applications to configure though.
    - hunter2_ 2y ago
      The `~` path (and `cd` with no arguments, to get there) are also part of the prime real estate. It's as if these polluters think you'll enjoy accessing their stuff via `~/<tab>` which might or might not be true.
      - deleted 2y ago
        [deleted]
      - eternityforest 2y ago
        Polluters probably assume you'll never access anything at all except through dedicated apps, and bookmarks. In my case it's mostly true but it's still icky and ugly to see a crowded home dir.
      - bananskalhalk 2y ago
        Yeah, but that is still one application. You might come fr enough with CDPATH and configuring .inputrc to do something smart with ^m and the %-character (for the root of your document folder). If it will be enough, I don't know. It might be enough for some, but it is still something which can be done without getting the maintainers of openssh to agree with the idea of a clean ~.
jmbwell 2y ago
I wish more developers would seek out and embrace libraries for saving things in sensible locations. Python has one called “platformdirs” that takes the guesswork out of where to save things automatically for the user’s platform. I have no doubt all the other major environments have something similar. If you ask me, this should all be built-in, but even then (because on many platforms, it is), people can’t help rolling their own. Standards XKCD I guess.
dorfsmay 2y ago
I have given up on the idea of a clean home dir a long time ago. I have "networked" directories (pCloud,Dropbox) in my home for everything I care for, and those are organized "perfectly". Additionally I symlink .vimrc and .gitconfig to a git repos. Then everything else in my home dir can be total garbage, it no longer matters. The big plus is that if a machine dies I can be back in business in minutes on another one.

by l72 2y ago

Aardwolf 2y ago

Same thing, wish that from the start unix had some standardized "applications put everything they want here" home directory that's separate from the "here user chooses to put their own files" home directory

yencabulator 2y ago
At the start, unix commands didn't need or use configuration files. The world really was that simple, for a while. Now we have even simple desktop apps, that I have not changed a single setting in, insisting to write a whole directory tree of whatever data in my home. Or absolutely moronic things like ~/.config/VSCod*/*Cache* -- really, cache in config?
- Aardwolf 2y ago
  Or ending up with multi-gigabyte ML models somewhere in deeply nested hidden directories in your homedir

sph 2y ago

The worst offenders are CLI tools written by people on Macs that do not respect XDG, because it's not a thing over there. So every tool gets to pollute your dotfiles with its own stupid directory. .rustup, .mix, .npm, .yarn, etc. But polluting your home directory like ~/go, without even the decency to hide it, is extremely rude and offensive.

sevagh 2y ago
>But polluting your home directory like ~/go, without even the decency to hide it, is extremely rude and offensive. Counterpoint: I actually like having visible directories, versus having to figure out where in /usr/share or /usr/local/ or ~/.local or /var an installer chose to sneak their files in. I got used to it and in HOME I put some of my manually installed tools like `AMD_AOCL` for the AMD AOCL libraries, `Android/android-studio` for Android Studio, `intel` for IPP/OpenAPI, etc. Don't want it anymore? Easy rm -rf, no need to go digging for where it could be hidden.
- KTibow 2y ago
  In theory, all applications following XDG would also solve the problem, as it has only 1 configuration directory. (Although I admit some apps use the data directory which brings it up to 2)
  - SAI_Peregrinus 2y ago
    XDG isn't enforced, it's voluntary. So there will always be lots of applications not following it.
- AlecSchueler 2y ago
  The point of XDG is to take the guesswork out of it by having applications follow your stated preferences.
- megadog3 2y ago
  "I actually like having visible directories, versus having to figure out where in /usr/share or /usr/local/ or ~/.local or /var an installer chose to sneak their files in." You seem to be mixing together two concepts here: 1. The files created by the installer, which are handled by the package manager. I can consult my package manager for files created by a specific package: pacman -Ql package_name. 2. The files created after installation (user preferences, plugins). The program should follow the XDG specification.
  - 2y ago

cesarb 2y ago

IMO, the GOPATH itself is a terrible design. It makes you mix together things from unrelated projects in the same directory structure, instead of each project having its own independent directory structure, like on every other programming language. The GOPATH design goes so much against the way I organize my projects, that it's the main reason I have never got interested into learning Go. Perhaps this design makes more sense for those who prefer to keep several unrelated projects together in a single monorepo, but that's not my preference.

softirq 2y ago
GOPATH actually made me realize that the ~/src/$host/$owner/$repo organization structure makes a ton of sense for every project and as long as you organize all of your languages into this one tree, everything just works.
- sureglymop 2y ago
  Can you expand on this a bit please? What does $host mean? Why would I need that for a purely local project that is only created for my own use? And what about grouping projects? E.g. "personal", "work", etc. And where in the structure are languages? Is that the overarching directory?
  - bheadmaster 2y ago
    > What does $host mean? In Go parlance, it would be the remote host where the repository is hosted, e.g. github.com, dev.azure.com, golang.org, etc. > Why would I need that for a purely local project that is only created for my own use? If nobody else is using your purely local project, and you're sure nobody will ever use it until the end of time, then I guess you could just use "~/src/$HOSTNAME/$USERNAME/$PROJECTNAME". Otherwise, it would be wise to setup a remote repository ahead of time. Go has a strong opinion that, in this day and age of distributed computing, projects should be online-first, so they can be easily used as dependencies. One of the nice consequences of this opinion is that Go dependencies can just be specified in the import statement - e.g. using grpc dependency is just: import "google.golang.org/grpc" No need for pom.xml, requirements.txt, cmake.txt, or any other kind of dependency configuration. It just works (unless it doesn't, like with private repositories, in which case it requires some exotic configurations in ~/.gitconfig or ~/.netrc, but that's a whole other can of worms - for most public repositories I've used it works flawlessly). > And what about grouping projects? E.g. "personal", "work", etc. Assuming you only use one repository hosting service and have one username, all your personal projects would be under "~/src/$PERSONAL_HOSTING_SERVICE/$USERNAME/", and your work would be under "~/src/$WORK_HOSTING_SERVICE/$WORK_ENTITY/" or something like this. > And where in the structure are languages? It isn't. That's either a bug or a feature. If it's a bug, you could just do the whole thing by language, e.g. "~/src/go/", "~/src/java/", etc.

bmacho 2y ago

Pro tip: don't put your stuff in your $HOME directory. $HOME is for applications to pollute. Put your stuff literally anywhere else.

computerfriend 2y ago
$HOME is where my terminal and file manager start. It's not reasonable to give up on this prime directory real estate.
- bananskalhalk 2y ago
  That's only two applications to configure though.
  - hunter2_ 2y ago
    The `~` path (and `cd` with no arguments, to get there) are also part of the prime real estate. It's as if these polluters think you'll enjoy accessing their stuff via `~/<tab>` which might or might not be true.
    - deleted 2y ago
      [deleted]
    - eternityforest 2y ago
      Polluters probably assume you'll never access anything at all except through dedicated apps, and bookmarks. In my case it's mostly true but it's still icky and ugly to see a crowded home dir.
    - bananskalhalk 2y ago
      Yeah, but that is still one application. You might come fr enough with CDPATH and configuring .inputrc to do something smart with ^m and the %-character (for the root of your document folder). If it will be enough, I don't know. It might be enough for some, but it is still something which can be done without getting the maintainers of openssh to agree with the idea of a clean ~.

jmbwell 2y ago

I wish more developers would seek out and embrace libraries for saving things in sensible locations. Python has one called “platformdirs” that takes the guesswork out of where to save things automatically for the user’s platform. I have no doubt all the other major environments have something similar. If you ask me, this should all be built-in, but even then (because on many platforms, it is), people can’t help rolling their own. Standards XKCD I guess.

dorfsmay 2y ago

I have given up on the idea of a clean home dir a long time ago. I have "networked" directories (pCloud,Dropbox) in my home for everything I care for, and those are organized "perfectly". Additionally I symlink .vimrc and .gitconfig to a git repos. Then everything else in my home dir can be total garbage, it no longer matters. The big plus is that if a machine dies I can be back in business in minutes on another one.