4 ms·

Well you have to emulate almost the whole hardware in software when doing virtual machines. This costs lots of performance (less so if you do paravirtualisation

Well you have to emulate almost the whole hardware in software when doing virtual machines. This costs lots of performance (less so if you do paravirtualisation). A virtual machine software essentially is an operating system that offers emulated native hardware as an interface. You don't have to show both applications the same file, you can mount different filesystems for them for /etc/ for instance. Or maybe the applications shouldn't read /etc/hosts directly

taeric 12y ago
So, /etc/hosts is just a silly example. One that happens to be easy to consider. You want "backend" for one service to be a different machine than "backend" for another. (Again, simple example, not necessarily indicative of how things should be.) But, this really doesn't answer my question. Sure, emulating a full machine can be expensive. That is typically why you do it with a very powerful machine in the first place. If the losses are such that they are causing problems, you can always go to real hardware, even. More to the point, this implies that containers are somehow "free." I am skeptical that could be the case. You are adding a whole new layer onto the operating system to possibly present multiple copies of files or only subsets. Simply put, there can be no free lunches. The price is paid somewhere.
- laumars 12y ago
  Containers don't require a whole new layer since you're effectively using the kernel as a hypervisor. Very simplistically put, containers are a little bit like chroot processes - so a guest would have it's own /etc directory unique to the host (you don't need to build containers this way if you don't wish to, but this would be the standard type of set up). With LXC, the guest processes are separated via cgroups, which is the same way systemd separates processes on the same host during it's init.
  - taeric 12y ago
    For some reason, I just can't get past the thought that this overhead is more than just a little. And, again, my main concern is more of a cognitive one. It is fairly hard to "pull back the curtains" and think about a system that has different /etc files for each application/container on it. (Heck, the implication seems to be that it would be possible for malware to somewhat easily hide stuff from the other users on the machine.) I mean, I realize it can be done. And pretty soon it would become the more standard way to do things. Just seems a larger mental shift to me than you are making it sound.
    - laumars 12y ago
      Just out of interest, have you ever played around with chroot? eg for SFTP or perhaps you've installed ArchLinux lately (chrooting is the standard way to install ArchLinux these days) Having a different /etc doesn't require a hypervisor, you're just telling the kernel that a PID's "/" is actually "/usr/local/containers/guest01/". Linux / UNIX has been doing this stuff for years and years.
      - taeric 12y ago
        I've seen it done. Never done it. My main concern would still be the cognitive overhead of my looking at it. Or, is there a way to see a "global" / according to all processes? (That make sense?)

taeric 12y ago

So, /etc/hosts is just a silly example. One that happens to be easy to consider. You want "backend" for one service to be a different machine than "backend" for another. (Again, simple example, not necessarily indicative of how things should be.) But, this really doesn't answer my question. Sure, emulating a full machine can be expensive. That is typically why you do it with a very powerful machine in the first place. If the losses are such that they are causing problems, you can always go to real hardware, even. More to the point, this implies that containers are somehow "free." I am skeptical that could be the case. You are adding a whole new layer onto the operating system to possibly present multiple copies of files or only subsets. Simply put, there can be no free lunches. The price is paid somewhere.

laumars 12y ago
Containers don't require a whole new layer since you're effectively using the kernel as a hypervisor. Very simplistically put, containers are a little bit like chroot processes - so a guest would have it's own /etc directory unique to the host (you don't need to build containers this way if you don't wish to, but this would be the standard type of set up). With LXC, the guest processes are separated via cgroups, which is the same way systemd separates processes on the same host during it's init.
- taeric 12y ago
  For some reason, I just can't get past the thought that this overhead is more than just a little. And, again, my main concern is more of a cognitive one. It is fairly hard to "pull back the curtains" and think about a system that has different /etc files for each application/container on it. (Heck, the implication seems to be that it would be possible for malware to somewhat easily hide stuff from the other users on the machine.) I mean, I realize it can be done. And pretty soon it would become the more standard way to do things. Just seems a larger mental shift to me than you are making it sound.
  - laumars 12y ago
    Just out of interest, have you ever played around with chroot? eg for SFTP or perhaps you've installed ArchLinux lately (chrooting is the standard way to install ArchLinux these days) Having a different /etc doesn't require a hypervisor, you're just telling the kernel that a PID's "/" is actually "/usr/local/containers/guest01/". Linux / UNIX has been doing this stuff for years and years.
    - taeric 12y ago
      I've seen it done. Never done it. My main concern would still be the cognitive overhead of my looking at it. Or, is there a way to see a "global" / according to all processes? (That make sense?)