Live data from Hacker News

Tips on how to structure your home directory (2023)

unixdigest.com

91–100 of 172 posts

Re: Tips on how to structure your home directory (2023)

#91
post #49
post #35

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, te…

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

I can’t tell if this is sarcasm or not.

$HOME is the one directory which belongs to the user. In some cases, it might even be encrypted with a user-owned key. I can’t imagine being comfortable putting my files anywhere _outside_ of the home directory. That feels like going back to the DOS / Win3.x days where hard drives were the wild west.

Re: Tips on how to structure your home directory (2023)

#92
post #53

Earlier quoted context omitted.

>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, `And…

"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 crea…

I don't worry about where my distro package manager installs files.

Some install methods are outside of your package manager, but try to touch /usr or /opt or /var, like NVIDIA sh scripts and the likes.

Re: Tips on how to structure your home directory (2023)

#93
post #44

Earlier quoted context omitted.

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.

[flagged]

> XDG is not a thing on Windows either afaik. Is a convention on one operating system something other operating systems should be faulted for not following?

GP is saying they should follow XDG on Linux not do it anywhere else!

Re: Tips on how to structure your home directory (2023)

#94
post #44

Earlier quoted context omitted.

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.

[flagged]

I guess the ire towards macOS-created apps comes from the fact that you can write macOS things that work on Linux without doing the “proper” things for the platform.

Windows is SO different that you have to do real porting work.

When something requires a minimal amount of porting effort to do 100% perfectly, or zero effort to do 99% it seems a lot of apps go for that 99%.

For my part writing cross platform apps I never actually realized there was a standard for arranging dotfiles so I wouldn’t have even realized I was leaving something out. XDG was one of those things I was vaguely aware existed and figured had something to do with the house of cards that is Linux desktop environments.

Re: Tips on how to structure your home directory (2023)

#95
post #72

Earlier quoted context omitted.

> No need for pom.xml, requirements.txt, cmake.txt, or any other kind of dependency configuration. It just works. ...until the project decides to switch to another hosting provider. Which has happened more than once in the past; it used to be common to host projects in Sourceforge, for a while Google Code was common, now many projects are on GitHub, and it won't surprise me at all when another forge becomes the popul…

> It's better to have an indirection layer to map the project name to the project location, like most other languages do. Who takes care of the indirection layer when the upstream decides to switch to another hosting provider?

The upstream who manages their name::location mapping?

Re: Tips on how to structure your home directory (2023)

#97
post #49

Earlier quoted context omitted.

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

I can’t tell if this is sarcasm or not. $HOME is the one directory which belongs to the user. In some cases, it might even be encrypted with a user-owned key. I can’t imagine being comfortable putting my files anywhere _outside_ of the home directory. That feels like going back to the DOS / Win3.x days where hard drives were the wild west.

[deleted]

Re: Tips on how to structure your home directory (2023)

#98
post #35

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, te…

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.

Re: Tips on how to structure your home directory (2023)

#99
post #49

Earlier quoted context omitted.

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

I can’t tell if this is sarcasm or not. $HOME is the one directory which belongs to the user. In some cases, it might even be encrypted with a user-owned key. I can’t imagine being comfortable putting my files anywhere _outside_ of the home directory. That feels like going back to the DOS / Win3.x days where hard drives were the wild west.

I follow the above advice. My personal stuff is in $HOME/$MY_FIRSTNAME.

I can organize this directory any way I want to, e.g. by project, time, purpose, whatever. It’s my stuff.

The stuff in $HOME is then more “the computer’s stuff.” (E.g., on MacOS, Photos, Desktop, Downloads - that’s where the computer dumps that stuff.) The other place is where I put things.

This turns out to work quite well. It allows me to be unconcerned when some application wants to put something in $HOME.

Re: Tips on how to structure your home directory (2023)

#100
post #72

Earlier quoted context omitted.

> 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/$PROJECTNA…

> No need for pom.xml, requirements.txt, cmake.txt, or any other kind of dependency configuration. It just works. ...until the project decides to switch to another hosting provider. Which has happened more than once in the past; it used to be common to host projects in Sourceforge, for a while Google Code was common, now many projects are on GitHub, and it won't surprise me at all when another forge becomes the popul…

Go already supports an indirection layer, commonly known as vanity URLs. It works by making a request to a domain owned by the project and parsing a meta tag in the response that points to the actual repository location. Of course, the problem is that few projects bother to set this up.
Post reply on HN