1 |
On Mon, Feb 17, 2020 at 1:21 PM Nikos Chantziaras <realnc@×××××.com> wrote: |
2 |
> |
3 |
> probably much slower.) A chroot or container on the other hand is |
4 |
> extremely lightweight. There's no virtualization involved (or very |
5 |
> little of it), so it should be pretty much as fast as a native system. |
6 |
|
7 |
Chroots and containers are exactly as fast as the native system, and |
8 |
don't involve any virtualization. |
9 |
|
10 |
In fact, on linux you can't NOT run a process in a chroot or |
11 |
container. Every process has a root directory and a set of namespaces |
12 |
applied to it, including init, and every new process just inherits the |
13 |
settings of the process that execed it. All linux users are |
14 |
essentially using at least one container. As such, running more than |
15 |
one container doesn't involve any kernel behavior that running a |
16 |
single container doesn't involve. |
17 |
|
18 |
Now, it is true that if you're running multiple containers you're more |
19 |
likely to have multiple copies of glibc and so on in RAM, and thus |
20 |
there is a memory overhead, though that applies system-wide, and not |
21 |
just to the processes running inside the additional containers. Maybe |
22 |
the one bit of overhead is the first time you launch a particular |
23 |
process in a particular container any shared libraries it uses will |
24 |
have to be loaded into RAM, while on the host there is a decent chance |
25 |
that some of them are already in RAM. We're really splitting hairs at |
26 |
this point, however. |
27 |
|
28 |
I wouldn't use a chroot for anything at this point - anything you can |
29 |
do with one you can do just as easily with a container, with more |
30 |
separation. They're just as easy to set up as well - I personally use |
31 |
nspawn to run my containers but I'm sure lxc is almost as simple and |
32 |
of course it doesn't require running systemd. |
33 |
|
34 |
Getting back to the original topic - you can just build binary |
35 |
packages for stuff like qt without using a container, but if you do so |
36 |
you won't be able to build more than one layer of dependencies. It |
37 |
still cuts down on the merge time considerably, but obviously not as |
38 |
much as it does if you build everything ahead of time. |
39 |
|
40 |
-- |
41 |
Rich |