Create kosmosbackupfilter.txt

[pato-pan]

review this at a later date. Should be finished.

This should only serve as an example of an rsync exclusion list, with some good exclusion suggestions.

[pato-pan]

I have my doubts on including "/drives/HD" and "drives/SD" for two reasons

1. It's better to let the script include both, so it can adapt to people preferring everything on the SD or on the HD
2. If you remove them, rsync could exclude some false positives. Files with the same name to the ones you want to exclude. (This wouldn't happen if I followed my phylosophy to the fullest, but then it would be harder to understand)

I was considering adding the default system paths instead, or make them more universal, but I believe that to share this backup script and this filter sharing part of my file structure philosophy as well is required. If you want to follow it yourself: My philosophy is to come up with names that are unlikely to be understood by someone else (example Downloads->Dablouds) and not restrict yourself to the home folders from linux or user folders from Windows. I take inspiration from them but I took my own liberties.

I don't store some of my programs on the default linux paths, and I don't store any of my media among other "home" files in the home folder. It's all on something like "/drives/HD" etc. That's starting on the root folder. A program is less likely to know what a folder in the root folder
The purpose is to remove the standard, to become unpredictable and prevent abuse or unforeseen consequences. Your computer should be you, and should adapt to you, and the names need to be like this to make filters like this more effective and prevent programs from predicting where your files are located, this prevents them from using those files without your consent or privacy in mind. But don't do this obsessively or strictly because you can break some things (I leave flatpak alone for example).

Part of this is to never share my personal file structure. This prevents others from copying my homework without making it different enough. I don't want my naming conventions and personal way to structure my files to become the standard. You should always come up with your own. I only suggest you follow my philosophy when creating your own folder structure.
I personally also find this more efficient and it has made some things easier to find and work through. I had never liked the standard that linux has, where one program will have files on /var and /usr and /home. Windows also has this issue but it's easier while making less sense (No one respect what the appdata folders, they just put it in any of those folders and it never makes sense and if it's not there. It's documents, or program files. But at least it's all in one location)
You should also accept that this leads to less compatibility. This means, other guides and other people have no idea where you store your files. You have to piece things together yourself.

So far, I haven't had a single problem following this philosophy. This could also be done on Windows by creating a partition for this purpose. Take caution there.
My way is not perfect, but it's what I prefer and it has advantages over others.

[pato-pan]

requires #7

Never merge. Create a new pull request and merge, or commit final version directly.

[pato-pan]

This is done unless I want to make up my mind on "to drives/HD or not to drives/HD".

I think it should only be done if it's too likely to get a false positive.