* if you are using light enough images, this shouldn't be a huge issue. if you have 16/32gb of ram this is a complete non issue for most desktop scenarios
* Thats entire the point. Only programs that you WANT to operate with each other can. This may be inconvenient, you may need to set up a socket or something for ssh-agent to handle and then programs that need the agent would have to hook into it.
* Any files in the container should 100% be program data. Any persistent/user data should be volumized to the host. Which means you can just find files on the volumes rather than in the containers. This may make files MORE centralized (if you use some sort of convention for /volumes/<program> or something)
Depending on your stance on how configs should be set up for desktop stuff... /etc should be a base part of the image. Any customizations you need in there should be injected at build time. That would be your customized etc configs would be sitting in the directory with your docker file, which would then be searchable.
That's the kind of standardization I had in mind :) Building such a system, we must make sure to have all the etc files in repos, even if we do not edit them, and copy them on build, instead of just having them in repos if we want to make a change, or using `sed` in dockerfile to edit them.
That is, for people who want their etc files easily lookable, of course.
* Thats entire the point. Only programs that you WANT to operate with each other can. This may be inconvenient, you may need to set up a socket or something for ssh-agent to handle and then programs that need the agent would have to hook into it.
* Any files in the container should 100% be program data. Any persistent/user data should be volumized to the host. Which means you can just find files on the volumes rather than in the containers. This may make files MORE centralized (if you use some sort of convention for /volumes/<program> or something)