Live data from Hacker News

Tips on how to structure your home directory (2023)

unixdigest.com

101–110 of 172 posts

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

#101
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.

To me its a sane choice on my own single-user machine. I used to create a top level `/data` directory to put my stuff into (before Android was widespread :) ). Nowdays, my data resides in `/data/main`. This scheme has served me well for more than 10a and through various OS migrations (Windows -> Ubuntu -> Debian).

I don't want to have all this `.cache` and similar stuff to take up my expensive backup storage, nor do I want to waste time cleaning up after all the applications that create/expect files in `$HOME` or think this a sensible place to put executable files. I don't want arbitrary applications (heard of tracker?) to start indexing my files and waste CPU on that etc.

Also I don't believe in /home being portable across multiple Linux distributions because e.g. different application versions might require config files to be migrated. Hence I opt for `/data` that can safely be shared across multiple systems because it contains actual data and not some OS-related state files.

On multi-user systems, the `/data` approach doesn't scale. There, I prefer to do just as boomboomsubban writes: I create a subdirectory in $HOME (usually, I call it `wd`, the "working directory") and treat that like my local `/data/main`. For large/temporary files (e.g. application downloads etc.) I add a `$HOME/large` directory to keep the `wd` reasonably small in such cases such that I can again include it in backups without having to worry about the size.

YMMV

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

#102
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.

Weirdly, enough, golang is one of the only programming languages that actually has built-in support for a cross-OS config dir location: [os.UserConfigDir()][1]. I don't really ever program in golang, but whenever I write a Node.JS/Python tool that does need a user-global config file, I just write my own implementation of it: function userConfigDir() { switch (process.platform) { case 'darwin': return `${os.homedir()}…

os.UserConfigDir was added in Go 1.13, which explains why it wasn’t used earlier.

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

#103
post #94

Earlier quoted context omitted.

[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 nev…

[deleted]

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

#104
post #55
post #50

I actually have quite a simple structure that serves me well (your mileage might vary) projects/ 2023/ 2024/ 0000-something/ 0312-other-project/ 0419-hn-comment/ each year I make a year folder. And each project has a month + day prefix. Sometimes I want long term projects to pop up on top, so I prefix them with 0000 (or only make the day 00). It is simple, works on any OS. Although on Linux I do have some helper scri…

Why not use folder dates for that? It could be sorted. projects/ | 01.01.2017 something/ | 01.01.2024 other-project/ | 01.01.2023 hn-comment/ | 01.01.2022

My experience with metadata is that a lot of applications don't care about its integrity but will never mess with the filename unless that is the purpose of the application.

Demo a sync program and find that all the creation dates have changed to today!

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

#105

> Hyphen vs underscore in filenames and directory names? > Originally, when I stopped using Windows back in about 1998, I was used to using spaces between words in filenames and directories. As I progressed into the world of Linux and BSD, I changed all spaces to underscores, but since I have done (and still do) a lot of web development I eventually settled on hyphens. I not only think it looks better, but the fact i…

That’s a minor thing I dig about Lisps: variables can be named foo-bar-baz, with nary a shift to type.

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

#106
I hope someday we won't have to think about this anymore. I just want to write, code, and create without the overhead of organizing. I don't want to decide how to correctly "file" my cabinets, or undertake home dir refactors because my usage patterns changed.

I only have respect for the unixdigest author, but I can't imagine living in his shoes. My notes tend to have more than one "category" and I'm too indecisive to accept one folder structure for them. And my notes/categories morphs a lot too.

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

#107

Earlier quoted context omitted.

$HOME is where my terminal and file manager start. It's not reasonable to give up on this prime directory real estate.

That's only two applications to configure though.

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 `~/` which might or might not be true.

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

#108

Earlier quoted context omitted.

> 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?

Please refrain from using the awkward question mark, it's condescending and rude.

What do you do if they fail to update their name::location mapping, and the language doesn't provide a way to do it yourself?

At least in Go, when that happens we can just add a `replace` statement in the go.mod file:

    replace example.com/foo/bar v2.35.0 => example.org/baz/bar/v2 master

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

#109
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…

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.

Go also provides a replace directive in the go.mod file [0].

[0] https://go.dev/ref/mod#go-mod-file-replace

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

#110

For me the way I use is as follows: Capital names for GUI things, lowercase names for CLI things. I'd prefer ~/documents, etc, but GUI people insist on capitalizing, so whatever. Very rarely I have to mix those, so it's not a big problem. ~/dotfiles is my dotfiles directory with git. I create ~/.zshrc -> dotfiles/zshrc, etc. I don't use any software to manage that, I just create symlinks. In the past I've used ~/.dot…

I very much dislike capitalizing anything. I know it's only an extra key to hit, but it's annoying as all get out.
Post reply on HN