3 ms·

> I think the "just as easily" is highly debatable. Heads up, you're talking about a different thing. You want to run these things as normal operations, but gu

by dozzie 10y ago

> I think the "just as easily" is highly debatable. Heads up, you're talking about a different thing. You want to run these things as normal operations, but gunnihinn was talking about deploying an application to check if it is of any value. Chroot is just enough to make a mess as the application's developer instructed in INSTALL.txt without the need to worry about cleaning up afterwards. And by the way, you seem to be confusing containers and Docker.

hamburglar 10y ago
I disagree. Just google "doesn't work in chroot" and you'll be reminded of a litany of issues that come up when trying to build/run things in a chroot, and a container containing a linux distro makes a tidy little sandbox which generally avoids those issues. It's somewhere on a spectrum between a chroot and a VM, which I think a lot of people find value in. And I'm not confusing containers and Docker, I'm just speaking a bit imprecisely. In my experience, conversations about "containers" are rarely about raw containers, but rather some specific containerization scheme and tools (e.g. docker). I suspect everyone in this entire subthread means "docker containers" when they says "containers."
- dozzie 10y ago
  > Just google "doesn't work in chroot" and you'll be reminded of a litany of issues that come up when trying to build/run things in a chroot Yeah, some newbie forgot to mount-bind a necessary directory like /proc or /dev, didn't provide sensible /etc/resolv.conf, or messed up host's and chroot's paths, either in request or in configuration. Nothing that would render chroot unviable. Is this what you meant?
  - jstarks 10y ago
    Why would anyone want to get all that right manually when containers manage all that automatically?
    - dozzie 10y ago
      Good question. Why anyone presented with fancy and fashionable third party software would use a mechanism that has been present for decades, ships with the operating system, works reliably and predictably, doesn't change substantially every quarter, doesn't do any magical things to network configuration, and is easy to inspect, debug, and adjust for an outsider? Why indeed?

by dozzie 10y ago

hamburglar 10y ago

I disagree. Just google "doesn't work in chroot" and you'll be reminded of a litany of issues that come up when trying to build/run things in a chroot, and a container containing a linux distro makes a tidy little sandbox which generally avoids those issues. It's somewhere on a spectrum between a chroot and a VM, which I think a lot of people find value in. And I'm not confusing containers and Docker, I'm just speaking a bit imprecisely. In my experience, conversations about "containers" are rarely about raw containers, but rather some specific containerization scheme and tools (e.g. docker). I suspect everyone in this entire subthread means "docker containers" when they says "containers."

dozzie 10y ago
> Just google "doesn't work in chroot" and you'll be reminded of a litany of issues that come up when trying to build/run things in a chroot Yeah, some newbie forgot to mount-bind a necessary directory like /proc or /dev, didn't provide sensible /etc/resolv.conf, or messed up host's and chroot's paths, either in request or in configuration. Nothing that would render chroot unviable. Is this what you meant?
- jstarks 10y ago
  Why would anyone want to get all that right manually when containers manage all that automatically?
  - dozzie 10y ago
    Good question. Why anyone presented with fancy and fashionable third party software would use a mechanism that has been present for decades, ships with the operating system, works reliably and predictably, doesn't change substantially every quarter, doesn't do any magical things to network configuration, and is easy to inspect, debug, and adjust for an outsider? Why indeed?