5 ms·

Thanks for the experimentation and report, would love to have more details. I've been wondering myself about using docker for user stuff, and not just develope

Thanks for the experimentation and report, would love to have more details. I've been wondering myself about using docker for user stuff, and not just developer stuff, like I do currently. Biggest problems I've figured: * the memory usage must be very high, unless you have a hybrid system where only some apps run in container and smaller ones do not * programs basically can't operate with each others, like accessing ssh agent or using dbus for ipc * finding files using locate now requires a script that will run locate in each container Are those things you already addressed, or at least you have ideas how you could address them? Or maybe, once used to a docker based system, they're not that a big deal?

Daviey 10y ago
I'm not convinced the memory usage would be very high.. but doing some measurements would be interesting. Avoiding network namespace and by using --net=host should allow dbus to run. Allowing updatedb to look in /var/lib/docker/ (and any attached volumes) should mean that the host mlocate can see all the files within the container.
- oelmekki 10y ago
  Awesome, thanks Daviey. So it seems to me that, while there's indeed some heavy coding to do for things like keeping apps up to date, containerizing what haven't been yet and managing data containers / mounted volumes, there's nothing preventing such setup to be viable, with hard work. There probably should be some grouping done at some point I guess, to work around apps that expect to live in the same place to work together, but that's still doable. Do you see any big blocker?
jacobush 10y ago
I associate to how IBM ran everything in virtual machines on their 360 architecture. And how you typically assign memory to virtual machines today reminds me of how you in MacOS < 10 had to do that on a per program basis before starting it.
- oelmekki 10y ago
  Sounds like interesting prior work for the problem at hand (granted, docker is not VM, but I guess they needed to solve the same kind of problems regarding ipc). Do you know of any literature about IBM results?
  - jacobush 10y ago
    Not really. Maybe start here if you are curious: https://www.ibm.com/support/knowledgecenter/en/SSAV7B_633/com.ibm.director.systemz.helps.doc/fqm0_c_z_zvm_op_sys.html https://www.ibm.com/support/knowledgecenter/en/SSAV7B_633/co... Look for service machines.
    - oelmekki 10y ago
      Thanks! So it seems they prefer to run groups of applications as services rather than totally isolating each program. This makes sense : docker bundles could be the next level of meta packages. You could say "I want to write some react-native code" and have the jvm, react-native and android sdk pulled at once and ready to use. Regarding ipc, they take a good part of this page to describe their z/VM networking features, so I guess it's indeed something needing solving. The interesting part is that docker networking already allows tcp networking, and mounting volumes could help sharing sockets or regular files, kind of like the "single system image feature" they mention.
bisby 10y ago
* 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)
- oelmekki 10y ago
  Very good points. I guess it would need some kind of standardization for `/etc` files, because I definitely want those to be lookable.
  - bisby 10y ago
    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.
    - oelmekki 10y ago
      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.

Daviey 10y ago

I'm not convinced the memory usage would be very high.. but doing some measurements would be interesting. Avoiding network namespace and by using --net=host should allow dbus to run. Allowing updatedb to look in /var/lib/docker/ (and any attached volumes) should mean that the host mlocate can see all the files within the container.

oelmekki 10y ago
Awesome, thanks Daviey. So it seems to me that, while there's indeed some heavy coding to do for things like keeping apps up to date, containerizing what haven't been yet and managing data containers / mounted volumes, there's nothing preventing such setup to be viable, with hard work. There probably should be some grouping done at some point I guess, to work around apps that expect to live in the same place to work together, but that's still doable. Do you see any big blocker?

jacobush 10y ago

I associate to how IBM ran everything in virtual machines on their 360 architecture. And how you typically assign memory to virtual machines today reminds me of how you in MacOS < 10 had to do that on a per program basis before starting it.

oelmekki 10y ago
Sounds like interesting prior work for the problem at hand (granted, docker is not VM, but I guess they needed to solve the same kind of problems regarding ipc). Do you know of any literature about IBM results?
- jacobush 10y ago
  Not really. Maybe start here if you are curious: https://www.ibm.com/support/knowledgecenter/en/SSAV7B_633/com.ibm.director.systemz.helps.doc/fqm0_c_z_zvm_op_sys.html https://www.ibm.com/support/knowledgecenter/en/SSAV7B_633/co... Look for service machines.
  - oelmekki 10y ago
    Thanks! So it seems they prefer to run groups of applications as services rather than totally isolating each program. This makes sense : docker bundles could be the next level of meta packages. You could say "I want to write some react-native code" and have the jvm, react-native and android sdk pulled at once and ready to use. Regarding ipc, they take a good part of this page to describe their z/VM networking features, so I guess it's indeed something needing solving. The interesting part is that docker networking already allows tcp networking, and mounting volumes could help sharing sockets or regular files, kind of like the "single system image feature" they mention.

bisby 10y ago

* 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)

oelmekki 10y ago
Very good points. I guess it would need some kind of standardization for `/etc` files, because I definitely want those to be lookable.
- bisby 10y ago
  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.
  - oelmekki 10y ago
    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.