9 ms·

Until well into the 2000s we deployed all our services as chroots. I even sold a server side product successfully which was distributed as chroot so it would in

Until well into the 2000s we deployed all our services as chroots. I even sold a server side product successfully which was distributed as chroot so it would install almost on any Linux distro without having to care about dependencies. It worked really well and felt quite a bit more accessible and lighter than docker. We just had a script which basically did: wget https://bla/image.tgz tar xzf image.tgz rm image.tgz chroot image/start and the product would be installed and up & running. A lot of clients thought it was magic. No Apache install? No MySQL install?? It works on Fedora & Centos & Debian & Ubuntu & ... ? I use this currently still a lot to run new software on unsupported hardware/kernels. For instance, I run a lot of new (Ubuntu) software on my OpenPandora under the default OS on that device; I have an SD with a chroot with Ubuntu and things like dotnet core. Runs fine. Gives devices like that a second youth.

somesortofsystm 7y ago
ISP's all over the valley did this in the 80's and early 90's as a way of supporting multiuser systems .. We should never forget that at the root of containerization is a desire to keep everyones shit sorted. That's been a Unix thing forever. EDIT: "Gives devices like that a second youth." Hell yeah, long live the OP!
- lukevp 7y ago
  Anyone interested in buying a first batch OP? I ordered it early in the process and then didn’t end up using it much
  - somesortofsystm 7y ago
    Still got my two first-batch OP's, keeping an eye on the Pyra situation, but oh .. what a ride its been ..
    - tluyben2 7y ago
      Yeah, waiting for the Pyra as well. I got to test the Gemini which was crap (imho), the Pocket 1 (excellent machine imho), Pocket 2 (no nub and thus, quite shit; worse battery life too). I only bought the Pocket 1 because I liked it so much when testing, but the OpenPandora is still really one of my favorite machines for one the go hacking because I can just hold it in my hands instead of having to put it down on a surface.
      - somesortofsystm 7y ago
        hehe, yeah .. the Pocket1 is my current favourite handheld, there's just nothing quite like it .. plus, paired with a couple of iControlPad's, its kind of badass. Been keeping an eye on GPD's other thingies, but I'm just jaded now. I just want a revised version of the Pocket1 that doesn't suck.. totally with you on the track-pointer.
  - tluyben2 7y ago
    Could do: drop me a mail; in profile.
- dreamcompiler 7y ago
  > We should never forget that at the root of containerization is a desire to keep everyones shit sorted. That's been a Unix thing forever. That's literally the point of operating systems: To allow many people to share the resources of one machine without being able to interfere with each other. Modern containers and VMs are just reinventing operating systems, and unfortunately they're doing it on top of existing operating systems rather than building -- you know -- a better operating system.
  - zanderwohl 7y ago
    I have been interested in an OS that would better implement virtualization and containers better, "closer to the hardware." I know most users aren't terribly interested in that sort of thing, but I think a lot of hacker-types would enjoy easily sorting projects into different areas. How nice would it be to easily spin up a couple different machines to test a server-client relationship on the same machine, without a handful of slow VMs? I feel I don't know enough to see the issues with an approach like that, or know why it's not already mainstream.
    - celticmusic 7y ago
      it's known as a "bare metal hypervisor" and is the most commonly used hypervisor. If you look into things like vmware ESXi you'll see it in action. https://www.vmware.com/products/esxi-and-esx.html https://www.vmware.com/products/esxi-and-esx.html
      - zanderwohl 7y ago
        Thanks for the link! Looks to be a little steep learning cliff, but I'll see what I can teach myself.
Orphis 7y ago
I used that for build machines. Had a btrfs filesystem on a loopback device I could just download as needed to seed the agents and then make a subvolume to work in. When all was done, I could just drop it. A lot of was automated with "schroot" and definitely faster than spawning a new instance of a VM every time!
- tluyben2 7y ago
  Yeah, it's very nice (and fast) for creating all kinds of build and test environments without messing up the machine. Language like Python recommend virtual envs like that, but this is more consistent and you can actually install whatever around Python as well without messing up the parent system.
- kakwa_ 7y ago
  A similar approach is used by distributions such as Debian/Fedora/Ubuntu/RHEL. In these distributions, you have tools ("pbuilder/*builder" in deb base distributions, "mock" in rpm based distributions) which create a chroot, grabs the build dependencies and install them from the repo, build the package and then throw away the chroot. It's really convenient for many reasons: 1) tracking and referencing build dependencies is far better as you have to declare them explicitly, no more "but it used to compile on the old machine... what am I missing". 2) you don't add kludge on the host running the build as you start from a fresh chroot every time. 3) you can target many distributions/versions from one building host (I'm regularly building RHEL 7 and 8 rpms and Debian 7, 8, 9, 10 debs from my Debian sid for example, without too much worry of weird side effects due to my particular setup. The downside is that builds can take a bit more time, but that's clearly something I'm willing to trade-off for more systematic and (semi-)reproducible builds. I even spent a few nights a month ago to have a newer version of mock that supports EL8 available on my Debian (for those interested: https://github.com/kakwa/debian-rpm-build-tools https://github.com/kakwa/debian-rpm-build-tools)
Wowfunhappy 7y ago
This is basically AppImage, right?
- AnIdiotOnTheNet 7y ago
  AppImage doesn't chroot, or as far as I'm aware even use namespacing. Most of the dependencies are packaged with the application in a squashfs image that is then mounted in tmp when it is run, so that's the only similarity.
Riverheart 7y ago
Any notable downsides to using chroots?
- rotten 7y ago
  1) There were/are sometimes ways to break out of them. 2) The process table is mixed in with your OS process table - making it hard to tell what is running chrooted and what isn't. 3) The network stack is shared 4) They share an OS You can make a "spectrum" of environments where you run code. One one side is everything running on a single server in a single OS, on the right is everything having its own machine and OS. In between you have chroot, docker, blade servers, virtual machines, and other isolation techniques. chroot falls somewhere between everything running in one system, and everything running in docker containers on one system.
  - organsnyder 7y ago
    I'm curious as to why blade servers are in your mix—aren't they essentially separate physical machines sharing a common backplane for I/O? Seems basically identical (from a software perspective) as servers hosted in the same rack.
    - kbenson 7y ago
      They also often share power among some number of blades. When the spectrum is how co aolidated software and hardware are, it is a bit apart from separate physical instances, as the fault tolerance isn't quite the same.
    - linuxdude314 7y ago
      Blade servers are purchased for their density.
  - seba_dos1 7y ago
    1) should actually be "there are ways to break out of them, period". chroot isn't a security feature, it doesn't even try to be one.
eleitl 7y ago
I've been using Linux vserver patch since times immemorial.
- canada_dry 7y ago
  Hopefully not a dumb question, but why not use QEMU? Also... can someone weigh in on why the likes of Linux VServer and OpenVZ became dormant??
  - B4F3F891 7y ago
    Before KVM appeared, VServer performance was way better than QEMU. After KVM appeared, it was a little better, so people who were already using it continued to do so.
maest 7y ago
This sounds juicy - are there any good resources on this/is the product still available?
m4rtink 7y ago
You had a checksum check there as well, right ? (I see it's over https, but still.)
bapcyk 7y ago
chroot, lol. In 2000s FreeBSD already had jails, SunOS had zones. And I remember, to use Linux in early 2000s was very risky and weird.
- coldtea 7y ago
  So, where are those two (SunOS, FreeBSD) now? Still going strong? /s
  - supermatt 7y ago
    SunOS became Solaris, which was forked into Illuminos which is the basis for SmartOS - Joyents virtualization platform used by many top tech platforms. FreeBSD is probably used to serve more data over the internet than any other OS distribution. All Netflix streams go through FreeBSD. So yeah, still going strong.
    - coldtea 7y ago
      So, one got sold at an auction sale and now is part of a second tier platform, the other has as its major modern success story that Netflix runs its servers with it?
      - supermatt 7y ago
        Second tier platform? What are you comparing it to exactly? SmartOS is an open source operating system that is widely used commercially as a kubernetes node (among others). It has native ZFS and DTrace, in addition to zones, etc. So is kubernetes second-tier? I don't understand your point. FreeBSDs success is invalid because its Netflix that heavily use it? Get real...
        coldtea 7y ago
        That Linux has been eating the world (server, mobile, even embedded) whereas SunOS died, Solaris is mostly forgotten. The SmartOS is just yet another OS with limited adoption. Whether it's "used commercially as a kubernetes node" doesn't mean much. Itself is second-tier, not Kubernetes (an OS doesn't magically adopt the success/adoption rate/etc of the tools it's used with. Most Kubernetes nodes remain Linux). As for FreeBSD, which I use to run back in the day for a spell, it has hugely declined in use from the late nineties. >FreeBSDs success is invalid because its Netflix that heavily use it? You got it backwards. Your argument that "Netflix uses it" as proof for FreeBSD success in 2020 is what is invalid. One company (however big) using an OS doesn't mean the OS is a success, or hasn't declined in adoption.
idoubtit 7y ago
Nowadays, creating a raw chroot is far from simple. Last time I tried, I had to handle the special mount points like /proc and /sys. I can't remember the details, but I believe there were other problems. In my experience, systemd-nspawn provides a nice alternative. It's mainly a chroot that abstracts the low-level details, and it fixes some security concerns (with cgroups, etc) and adds some nice features: e.g. networking, or `systemctl status` from the host that will display the sub-tree for the processes of the sub-host.
- znpy 7y ago
  Last time I tried to recover an ubuntu system by booting from a live sub, mounting the drive and chrooting into the target device i was surprised to find out that systemd refuses to work if it detects being run in a chroot. I was left puzzled.
  - Spivak 7y ago
    If you're talking about what happens when you mount the root filesystem, chroot into it, and run systemctl then you're essentially asking to break out of the chroot and communicate to the service manager outside the chroot which almost always doesn't make sense. The only time this is reasonable is when a container needs to manage services on the host a la what Portainer does for Docker. You have a lot of options for accomplishing what you want. * To run a service with a given root filesystem add RootFilesystem=/path to your unit file. * Run a service from an image of a root filesystem use systemd portable services. * To run your service using the init system in your root filesystem (could be systemd but doesn't have to be) use systemd-nspawn --boot.
    - znpy 7y ago
      you know, I just wanted to run services from within the chroot, like you could do in the pre-systemd era. I mean, as long as you have /proc, /sys and etc bind-mounted you should be okay, right ?
      - 7y ago
jrockway 7y ago
Docker has mostly succeeded in making this simple concept complicated. A "container image" is just a tape archive of some files. The runtime is just like your chroot, but with namespaces and cgroups. That's about it. On top of all this, they designed a new programming language / build system for making those tar files. They invented a container registry so that instead of just "downloading a file", you have to use their particular protocol to download a file. They have their own version of systemd so you can see what programs are running. They tacked on some very complicated networking stuff. They tried to build a couple of container orchestration frameworks on top of all this. I think all the "extra stuff" is where people run into problems, and it's isn't even the core of the value it provides. People have realized that it's all a little much and the good bits have been distilled into their own projects. Many build systems can just generate an OCI registry file directly (remember, it's just a tar file, and you don't need all that 1970s JCL stuff to make a tar file). Various runtimes (containerd/CRI-O) exist for running containers. And there are orchestration layers on top, for actually managing sets of containers, network rules, etc. (ECR, Kubernetes, etc.). (Worth noting is that Docker itself does use all these spin-offs. It uses containerd as the runtime, it uses buildkit for building containers now, etc. They even ship a Kubernetes distribution, at least on Mac and Windows.)
- krick 7y ago
  I never thought about that. Is it really just that? Then how come Docker is this huge innovation that conquered the world and nobody can live without it anymore?
  - vimda 7y ago
    The innovation was the layered distribution system. Suddenly it was more efficient to distribute images to hundreds or thousands of hosts
    - jroroooepjro 7y ago
      It was the right UX at the right time. Personally, I preferred my home brew “Kube” that would ssh updates to cgroups from a central control server. Which is basically the Chef model, and Salt model of clients pulling desired state. Docker & Kube aren’t novel and weren’t as specific things. Tons of home brew options operating in roughly the same style existed around the net. Their adoption in industry, use at scale, simply gives them a grander appearance of somehow being truly novel
inopinatus 7y ago
Most folks have two requirements: 1. Put files on a device 2. Start a process The scale at which containerised scheduling of this outcome saves more time than it consumes is much higher than many have been led to believe. I measure it in sysadmin FTE. If you have >0.5 FTE dedicated to managing deployments then there may be a payoff, because (amortized over a reasonable period e.g. 12 months) it takes at minimum half an FTE to setup, manage, and maintain a PaaS properly. I've become accustomed to folks claiming things like, "I spend 5 minutes a week managing my kubernetes cluster". Then it turns out it took them a solid month to get it going properly, two weeks to containerise their application reliabily, and then next quarter they're stuck for days on some weird networking or logging issue, and nothing else progresses. Basically, they either don't value their time, or they're misjudging how much they've actually allocated. It's often the same people who boast about how cheap their bare-metal servers are vs public cloud instances.
rocho 7y ago
For me, Docker is important because it lets me use Kubernetes. That's what I really want to use. If Docker used chroot instead of their own thing, I would be fine as well.

somesortofsystm 7y ago

ISP's all over the valley did this in the 80's and early 90's as a way of supporting multiuser systems .. We should never forget that at the root of containerization is a desire to keep everyones shit sorted. That's been a Unix thing forever. EDIT: "Gives devices like that a second youth." Hell yeah, long live the OP!

lukevp 7y ago
Anyone interested in buying a first batch OP? I ordered it early in the process and then didn’t end up using it much
- somesortofsystm 7y ago
  Still got my two first-batch OP's, keeping an eye on the Pyra situation, but oh .. what a ride its been ..
  - tluyben2 7y ago
    Yeah, waiting for the Pyra as well. I got to test the Gemini which was crap (imho), the Pocket 1 (excellent machine imho), Pocket 2 (no nub and thus, quite shit; worse battery life too). I only bought the Pocket 1 because I liked it so much when testing, but the OpenPandora is still really one of my favorite machines for one the go hacking because I can just hold it in my hands instead of having to put it down on a surface.
    - somesortofsystm 7y ago
      hehe, yeah .. the Pocket1 is my current favourite handheld, there's just nothing quite like it .. plus, paired with a couple of iControlPad's, its kind of badass. Been keeping an eye on GPD's other thingies, but I'm just jaded now. I just want a revised version of the Pocket1 that doesn't suck.. totally with you on the track-pointer.
- tluyben2 7y ago
  Could do: drop me a mail; in profile.
dreamcompiler 7y ago
> We should never forget that at the root of containerization is a desire to keep everyones shit sorted. That's been a Unix thing forever. That's literally the point of operating systems: To allow many people to share the resources of one machine without being able to interfere with each other. Modern containers and VMs are just reinventing operating systems, and unfortunately they're doing it on top of existing operating systems rather than building -- you know -- a better operating system.
- zanderwohl 7y ago
  I have been interested in an OS that would better implement virtualization and containers better, "closer to the hardware." I know most users aren't terribly interested in that sort of thing, but I think a lot of hacker-types would enjoy easily sorting projects into different areas. How nice would it be to easily spin up a couple different machines to test a server-client relationship on the same machine, without a handful of slow VMs? I feel I don't know enough to see the issues with an approach like that, or know why it's not already mainstream.
  - celticmusic 7y ago
    it's known as a "bare metal hypervisor" and is the most commonly used hypervisor. If you look into things like vmware ESXi you'll see it in action. https://www.vmware.com/products/esxi-and-esx.html https://www.vmware.com/products/esxi-and-esx.html
    - zanderwohl 7y ago
      Thanks for the link! Looks to be a little steep learning cliff, but I'll see what I can teach myself.

Orphis 7y ago

I used that for build machines. Had a btrfs filesystem on a loopback device I could just download as needed to seed the agents and then make a subvolume to work in. When all was done, I could just drop it. A lot of was automated with "schroot" and definitely faster than spawning a new instance of a VM every time!

tluyben2 7y ago
Yeah, it's very nice (and fast) for creating all kinds of build and test environments without messing up the machine. Language like Python recommend virtual envs like that, but this is more consistent and you can actually install whatever around Python as well without messing up the parent system.
kakwa_ 7y ago
A similar approach is used by distributions such as Debian/Fedora/Ubuntu/RHEL. In these distributions, you have tools ("pbuilder/*builder" in deb base distributions, "mock" in rpm based distributions) which create a chroot, grabs the build dependencies and install them from the repo, build the package and then throw away the chroot. It's really convenient for many reasons: 1) tracking and referencing build dependencies is far better as you have to declare them explicitly, no more "but it used to compile on the old machine... what am I missing". 2) you don't add kludge on the host running the build as you start from a fresh chroot every time. 3) you can target many distributions/versions from one building host (I'm regularly building RHEL 7 and 8 rpms and Debian 7, 8, 9, 10 debs from my Debian sid for example, without too much worry of weird side effects due to my particular setup. The downside is that builds can take a bit more time, but that's clearly something I'm willing to trade-off for more systematic and (semi-)reproducible builds. I even spent a few nights a month ago to have a newer version of mock that supports EL8 available on my Debian (for those interested: https://github.com/kakwa/debian-rpm-build-tools https://github.com/kakwa/debian-rpm-build-tools)

Wowfunhappy 7y ago

This is basically AppImage, right?

AnIdiotOnTheNet 7y ago
AppImage doesn't chroot, or as far as I'm aware even use namespacing. Most of the dependencies are packaged with the application in a squashfs image that is then mounted in tmp when it is run, so that's the only similarity.

Riverheart 7y ago

Any notable downsides to using chroots?

rotten 7y ago
1) There were/are sometimes ways to break out of them. 2) The process table is mixed in with your OS process table - making it hard to tell what is running chrooted and what isn't. 3) The network stack is shared 4) They share an OS You can make a "spectrum" of environments where you run code. One one side is everything running on a single server in a single OS, on the right is everything having its own machine and OS. In between you have chroot, docker, blade servers, virtual machines, and other isolation techniques. chroot falls somewhere between everything running in one system, and everything running in docker containers on one system.
- organsnyder 7y ago
  I'm curious as to why blade servers are in your mix—aren't they essentially separate physical machines sharing a common backplane for I/O? Seems basically identical (from a software perspective) as servers hosted in the same rack.
  - kbenson 7y ago
    They also often share power among some number of blades. When the spectrum is how co aolidated software and hardware are, it is a bit apart from separate physical instances, as the fault tolerance isn't quite the same.
  - linuxdude314 7y ago
    Blade servers are purchased for their density.
- seba_dos1 7y ago
  1) should actually be "there are ways to break out of them, period". chroot isn't a security feature, it doesn't even try to be one.

eleitl 7y ago

I've been using Linux vserver patch since times immemorial.

canada_dry 7y ago
Hopefully not a dumb question, but why not use QEMU? Also... can someone weigh in on why the likes of Linux VServer and OpenVZ became dormant??
- B4F3F891 7y ago
  Before KVM appeared, VServer performance was way better than QEMU. After KVM appeared, it was a little better, so people who were already using it continued to do so.

maest 7y ago

This sounds juicy - are there any good resources on this/is the product still available?

m4rtink 7y ago

You had a checksum check there as well, right ? (I see it's over https, but still.)

bapcyk 7y ago

chroot, lol. In 2000s FreeBSD already had jails, SunOS had zones. And I remember, to use Linux in early 2000s was very risky and weird.

coldtea 7y ago
So, where are those two (SunOS, FreeBSD) now? Still going strong? /s
- supermatt 7y ago
  SunOS became Solaris, which was forked into Illuminos which is the basis for SmartOS - Joyents virtualization platform used by many top tech platforms. FreeBSD is probably used to serve more data over the internet than any other OS distribution. All Netflix streams go through FreeBSD. So yeah, still going strong.
  - coldtea 7y ago
    So, one got sold at an auction sale and now is part of a second tier platform, the other has as its major modern success story that Netflix runs its servers with it?
    - supermatt 7y ago
      Second tier platform? What are you comparing it to exactly? SmartOS is an open source operating system that is widely used commercially as a kubernetes node (among others). It has native ZFS and DTrace, in addition to zones, etc. So is kubernetes second-tier? I don't understand your point. FreeBSDs success is invalid because its Netflix that heavily use it? Get real...
      - coldtea 7y ago
        That Linux has been eating the world (server, mobile, even embedded) whereas SunOS died, Solaris is mostly forgotten. The SmartOS is just yet another OS with limited adoption. Whether it's "used commercially as a kubernetes node" doesn't mean much. Itself is second-tier, not Kubernetes (an OS doesn't magically adopt the success/adoption rate/etc of the tools it's used with. Most Kubernetes nodes remain Linux). As for FreeBSD, which I use to run back in the day for a spell, it has hugely declined in use from the late nineties. >FreeBSDs success is invalid because its Netflix that heavily use it? You got it backwards. Your argument that "Netflix uses it" as proof for FreeBSD success in 2020 is what is invalid. One company (however big) using an OS doesn't mean the OS is a success, or hasn't declined in adoption.

idoubtit 7y ago

Nowadays, creating a raw chroot is far from simple. Last time I tried, I had to handle the special mount points like /proc and /sys. I can't remember the details, but I believe there were other problems. In my experience, systemd-nspawn provides a nice alternative. It's mainly a chroot that abstracts the low-level details, and it fixes some security concerns (with cgroups, etc) and adds some nice features: e.g. networking, or `systemctl status` from the host that will display the sub-tree for the processes of the sub-host.

znpy 7y ago
Last time I tried to recover an ubuntu system by booting from a live sub, mounting the drive and chrooting into the target device i was surprised to find out that systemd refuses to work if it detects being run in a chroot. I was left puzzled.
- Spivak 7y ago
  If you're talking about what happens when you mount the root filesystem, chroot into it, and run systemctl then you're essentially asking to break out of the chroot and communicate to the service manager outside the chroot which almost always doesn't make sense. The only time this is reasonable is when a container needs to manage services on the host a la what Portainer does for Docker. You have a lot of options for accomplishing what you want. * To run a service with a given root filesystem add RootFilesystem=/path to your unit file. * Run a service from an image of a root filesystem use systemd portable services. * To run your service using the init system in your root filesystem (could be systemd but doesn't have to be) use systemd-nspawn --boot.
  - znpy 7y ago
    you know, I just wanted to run services from within the chroot, like you could do in the pre-systemd era. I mean, as long as you have /proc, /sys and etc bind-mounted you should be okay, right ?
    - 7y ago

jrockway 7y ago

Docker has mostly succeeded in making this simple concept complicated. A "container image" is just a tape archive of some files. The runtime is just like your chroot, but with namespaces and cgroups. That's about it. On top of all this, they designed a new programming language / build system for making those tar files. They invented a container registry so that instead of just "downloading a file", you have to use their particular protocol to download a file. They have their own version of systemd so you can see what programs are running. They tacked on some very complicated networking stuff. They tried to build a couple of container orchestration frameworks on top of all this. I think all the "extra stuff" is where people run into problems, and it's isn't even the core of the value it provides. People have realized that it's all a little much and the good bits have been distilled into their own projects. Many build systems can just generate an OCI registry file directly (remember, it's just a tar file, and you don't need all that 1970s JCL stuff to make a tar file). Various runtimes (containerd/CRI-O) exist for running containers. And there are orchestration layers on top, for actually managing sets of containers, network rules, etc. (ECR, Kubernetes, etc.). (Worth noting is that Docker itself does use all these spin-offs. It uses containerd as the runtime, it uses buildkit for building containers now, etc. They even ship a Kubernetes distribution, at least on Mac and Windows.)

krick 7y ago
I never thought about that. Is it really just that? Then how come Docker is this huge innovation that conquered the world and nobody can live without it anymore?
- vimda 7y ago
  The innovation was the layered distribution system. Suddenly it was more efficient to distribute images to hundreds or thousands of hosts
  - jroroooepjro 7y ago
    It was the right UX at the right time. Personally, I preferred my home brew “Kube” that would ssh updates to cgroups from a central control server. Which is basically the Chef model, and Salt model of clients pulling desired state. Docker & Kube aren’t novel and weren’t as specific things. Tons of home brew options operating in roughly the same style existed around the net. Their adoption in industry, use at scale, simply gives them a grander appearance of somehow being truly novel

inopinatus 7y ago

Most folks have two requirements: 1. Put files on a device 2. Start a process The scale at which containerised scheduling of this outcome saves more time than it consumes is much higher than many have been led to believe. I measure it in sysadmin FTE. If you have >0.5 FTE dedicated to managing deployments then there may be a payoff, because (amortized over a reasonable period e.g. 12 months) it takes at minimum half an FTE to setup, manage, and maintain a PaaS properly. I've become accustomed to folks claiming things like, "I spend 5 minutes a week managing my kubernetes cluster". Then it turns out it took them a solid month to get it going properly, two weeks to containerise their application reliabily, and then next quarter they're stuck for days on some weird networking or logging issue, and nothing else progresses. Basically, they either don't value their time, or they're misjudging how much they've actually allocated. It's often the same people who boast about how cheap their bare-metal servers are vs public cloud instances.

rocho 7y ago

For me, Docker is important because it lets me use Kubernetes. That's what I really want to use. If Docker used chroot instead of their own thing, I would be fine as well.