Earlier quoted context omitted.
Why have owner in there? Isn't the clear from the filesystem metadata, which also has the benefits of shared ownership groups etc.?
The "owner" could be multiple directory levels depending the hosting service. Gitlab lets you have arbitrary sub levels. The owner of the files also isn't necessarily related to the owner of the repo on Github.
Tips on how to structure your home directory (2023)
161–170 of 172 posts
Re: Tips on how to structure your home directory (2023)
#162Earlier quoted context omitted.
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 un…
Exactly, or simply "$HOME/a" for less typing.
Re: Tips on how to structure your home directory (2023)
#163Earlier quoted context omitted.
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
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?
Re: Tips on how to structure your home directory (2023)
#164Earlier quoted context omitted.
I feel like you're probably kidding, but I kind of like this. Maybe not psyched about the shell-interpreted brackets, semicolons, and spaces. But the idea is interesting!
No, I'm serious. There's no portable filesystem metadata, and while a few kinds of media files have facilities for internal metadata (e.g. EXIF and ID3), most don't. A file name is the only non-content that is easy to keep associated with any kind of file. The syntax is definitely an imperfect compromise, but most of the things I use this for have titles that frequently contain spaces (books, papers, music, etc.) so…
Although I have to warn you that ISBNs are not a perfect guid and they sometimes get reissued. Good enough if you aren't hoarding the world I guess.
Re: Tips on how to structure your home directory (2023)
#165I 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…
Re: Tips on how to structure your home directory (2023)
#166Earlier quoted context omitted.
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.
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 ~.
Re: Tips on how to structure your home directory (2023)
#167Earlier 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.
No. You got it backwards. If you put your stuff in a folder (not in the $HOME folder, but practically anywhere else), then your stuff will be in 1 place, there won't be any name collision with the system, it won't be polluted, and such.
Putting your stuff in $HOME is exactly what you want to avoid.
Re: Tips on how to structure your home directory (2023)
#168Earlier quoted context omitted.
I use “/Code”.
I once accidentally did an `rm -rf ~/` on a machine without backups and it removed everything alphabetically up until `~/Coding` (everything else being unimportant). So I fixed that by setting up backups and renaming it `~/Zoding` lol. Haven't been foolish enough to make that same mistake again, though.
Re: Tips on how to structure your home directory (2023)
#169Earlier quoted context omitted.
Now I'm wondering what month "19" is named...
Well the 8th month ain't October
calvin@bison:~/work$ tree -d | head
.
├── 2022
│ ├── 04
│ │ ├── 19
?Re: Tips on how to structure your home directory (2023)
#170I 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…
You may want to try TagSpaces https://www.tagspaces.org/ or TMSU https://tmsu.org/ which provide mechanisms for managing tags of arbitrary files (not only EXIF or ID3 ones).
I've also been on the lookout for an AI assisted duplicate finder. Like, it'll compare pictures and then rate similarity between pictures on some scale, by appearance, colour or topic, perhaps with an auto-tagging feature as well. Ofc it should also compare dates, file sizes and the usual MIME type or hash based similarities as well.