Beyond organization, I want to concisely back up and port between machines. The `.config` folder is a big headache when trying to be strategic about backups due to apps putting gigs of session data there. "session data" is not "config", consarnit! An app's "config" shouldn't be gigs large. Grumble grumble, grouse grouse, and so on. :^)
Tips on how to structure your home directory (2023)
111–120 of 172 posts
Re: Tips on how to structure your home directory (2023)
#112Earlier quoted context omitted.
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!
This has led me to formally maintaining significant metadata in the filename, for certain kinds of files; everything else gets lost or diverges. For instance, a book file might be named `Title [a=Jim Smith; isbn=9781234567890].pdf`.
Re: Tips on how to structure your home directory (2023)
#113Re: Tips on how to structure your home directory (2023)
#114Beyond organization, I want to concisely back up and port between machines. The `.config` folder is a big headache when trying to be strategic about backups due to apps putting gigs of session data there. "session data" is not "config", consarnit! An app's "config" shouldn't be gigs large. Grumble grumble, grouse grouse, and so on. :^)
Re: Tips on how to structure your home directory (2023)
#115Earlier quoted context omitted.
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.
Why have owner in there? Isn't the clear from the filesystem metadata, which also has the benefits of shared ownership groups etc.?
Re: Tips on how to structure your home directory (2023)
#116I think it's a nice idea, but don't like the media structure into family and so on. Looks like he's going to have a ton of problems with duplicates and then edited duplicates down the line, which can easily be mixed up, and then you lose your edits and so on. Pictures are better sorted with EXIF keywords. So, metadata stored in the picture itself, perhaps even in the MIME type. Thus, if a picture is family related, j…
I think photoprism and photostructure don't really care about your directory structure or organization, but paperless(-ngx, or whatever is the most current iteration) is "notorious" for being opinionated about organization / not wanting to respect your organization.
I used camlistore/perkeep for photos for a while, but google photos has an absolutely killer feature of knowing who is in every picture, even accounting for age: although two of my boys who are 8 years apart look really similar at similar ages, it knows who is who. I don't know if it uses facial analysis or photo metadata or what, but it has never mistaken one for the other. I don't have a reasonable way of getting that tag information out of google photos (even though I'm paying for the service).
It might be time to revisit this, though.. I don't recall whether photostructure / photoprism try to do facial recognition, but even if they don't already, I bet they'll soon be roughly on par with google photos (or good enough that I can stop depending on google for this).
That's documents and photos / videos, what about music? For better or for worse, It's been at least a ~decade since I tried keeping my own music collection as files. Are there things these days like paperless / photoprism, a library system for music that has deeper integration with the content than just "files on disk"?
Re: Tips on how to structure your home directory (2023)
#117Earlier 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()}…
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
Re: Tips on how to structure your home directory (2023)
#118Earlier quoted context omitted.
[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)
#119Anyway I don't worry about organization as much because a hand search might take five minutes. Organizing files is never done because nobody understands someone else's organization. When it comes to file organization, present self quickly becomes someone else and the Documents folder contains an oldDocuments folder contains a Documents folder with an oldDocuments folder and so on.
Date is the most reliable way to organize files. It is monotonic.
Re: Tips on how to structure your home directory (2023)
#120Earlier 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…
Or decides their github username looks better with an upper case letter (https://github.com/sirupsen/logrus/issues/570). Or for people who use their real name as their github name, updating their username after marriage, divorce, gender transition or whatever.