<p>That is not a good argument and it shows a basic misunderstanding of what containers are and how they should be used. Containers are NOT virtual machines.</p>

<p>A container runs a (short lived) process. Think executable, like <code>ls</code>, or <code>top</code>, or a shell or Python script. When the process ends, the container is destroyed. The process is isolated from other processes running on the same machine. Basically the kernel reserves some space (memory/CPU) for that process, runs the executable inside that isolated space, then releases the reservation. The reserved space is the container.</p>

<p>A virtual machine on the other hand is an emulator. It pretends there is an entire computer and it needs an operating system to, well, operate it. It boots a kernel, starts an init system and then a whole bunch of processes to deal with every aspect of the emulated hardware.</p>

<p>A container is supposed to be small and fast. And it's not generally supposed to run for days, or even hours. Compared to a virtual machine, which gives the user more freedom, but also takes more resources. Packing an entire distribution like Debian or RedHat inside a container would defeat the purpose.</p>

<p>For example, you're not supposed to run a web server (say, Nginx + PHP) inside a container. When a page is requested, you run the PHP script inside a container to generate the page, hand the output over to Nginx running outside, then the container is destroyed. If you want Nginx+PHP in the same space, you're better off with a virtual machine. There may be reasons to set it up as a container, but technically speaking Nginx workers already do the work of containers, so you'd just be duplicating that.</p>

CC BY-SA 4.0
2019-02-18T14:31:43.490Z
why do you think container runs a short lived process? It is certainly not endless, but where do you get "its certainly not supposed to run for days or even hours" this from?
4c74356b41
CC BY-SA 4.0
2019-02-19T17:58:17.443Z
It's not **generally** supposed to. Still, I should probably edit that part out because it's mostly personal opinion. There are valid reasons to have long running containers. What I mean is that I _feel_ like containers are better suited for the FaaS way of doing things, where a container is regarded as a function, rather than a VM. That's more of an architectural opinion though, rather than a technical reason, as there are distributions packed as containers and plenty of people do use them.
bgdnlp
CC BY-SA 4.0
2019-02-19T18:00:44.733Z
literally all of my clients have their code running in containers. wtf are you talking about? :)
4c74356b41
CC BY-SA 4.0
2019-02-16T11:51:33.877Z
2019-02-16T11:51:33.877Z
bgdnlp
<p>I need to justify container adoption.</p>

<p>I have several solid arguments, but one is making me dubious. Is it correct to say software can "run better" or "worst" depending on the Linux distribution? Here is what I heard:</p>

<blockquote>
  <p>some software run better on RedHat-based distributions, other better on Debian-based distributions. With containers, you can run each software on its preferred environment regardless of the operating system installed on the host.</p>
</blockquote>

<p>Is it true? And if it is, do you have an example of such software?</p>

<containers><culture>
Is "running several Linux distributions on the same host" a good justification for container adoption?
Sylvain Leroux
# Is "running several Linux distributions on the same host" a good justification for container adoption?

(Asked by: username_0 on 2019-02-16)

I need to justify container adoption.

I have several solid arguments, but one is making me dubious. Is it correct to say software can "run better" or "worst" depending on the Linux distribution? Here is what I heard:

> some software run better on RedHat-based distributions, other better on Debian-based distributions. With containers, you can run each software on its preferred environment regardless of the operating system installed on the host.

Is it true? And if it is, do you have an example of such software?

**Tags:** containers, culture


---

## 1 answers

### Answer by username_1 on 2019-02-16. Score: 1

That is not a good argument and it shows a basic misunderstanding of what containers are and how they should be used. Containers are NOT virtual machines.

A container runs a (short lived) process. Think executable, like `ls`, or `top`, or a shell or Python script. When the process ends, the container is destroyed. The process is isolated from other processes running on the same machine. Basically the kernel reserves some space (memory/CPU) for that process, runs the executable inside that isolated space, then releases the reservation. The reserved space is the container.

A virtual machine on the other hand is an emulator. It pretends there is an entire computer and it needs an operating system to, well, operate it. It boots a kernel, starts an init system and then a whole bunch of processes to deal with every aspect of the emulated hardware.

A container is supposed to be small and fast. And it's not generally supposed to run for days, or even hours. Compared to a virtual machine, which gives the user more freedom, but also takes more resources. Packing an entire distribution like Debian or RedHat inside a container would defeat the purpose.

For example, you're not supposed to run a web server (say, Nginx + PHP) inside a container. When a page is requested, you run the PHP script inside a container to generate the page, hand the output over to Nginx running outside, then the container is destroyed. If you want Nginx+PHP in the same space, you're better off with a virtual machine. There may be reasons to set it up as a container, but technically speaking Nginx workers already do the work of containers, so you'd just be duplicating that.

> **Comments:**
> **username_2**: why do you think container runs a short lived process? It is certainly not endless, but where do you get "its certainly not supposed to run for days or even hours" this from?  
> **username_1**: It's not **generally** supposed to. Still, I should probably edit that part out because it's mostly personal opinion. There are valid reasons to have long running containers. What I mean is that I _feel_ like containers are better suited for the FaaS way of doing things, where a container is regarded as a function, rather than a VM. That's more of an architectural opinion though, rather than a technical reason, as there are distributions packed as containers and plenty of people do use them.  
> **username_2**: literally all of my clients have their code running in containers. wtf are you talking about? :)  

---

