3 ms·

Maybe docker had a little bit of hype? But openvz n lxc have been around for a long time..

by lazylizard 7y ago

itsmefaz 7y ago
Was there a reason why they didn't take off like docker did?
- znpy 7y ago
  Usability/ergonomic. Docker was/is a lot simpler to grasp. That eases adoption.
- lowdose 7y ago
  Docker came with the container metaphor.
- rumanator 7y ago
  IIRC, the main problem was UI/UX. Docker containers in essence are a bit like running isolated Linux processes in a chrooted and cgrouped environment. Chroot exists for decades, and so does cgroups. Yet, Docker came up with a UI and UX which, among other things, let you download and run isolated Linux processes by simply running 'docker run <container name>', thus shoving everything well under the rug and practically eliminating the need to pull any arcane trick to get Linux processes to run in isolation.
  - kazen44 7y ago
    running processes in isolation has been happening for a long time. (jails for instance, have existed for a very long time and freebsd has been used a lot for hosting services in the past). while i agree docker solved the UI/UX problem, it also introducted a massive security risk, as running unverified binaries in production is very easy for developers. Most shops don't have any private repository in use nor do they have the people (anymore) to build proper processes and systems around running code in production.
    - rumanator 7y ago
      > also introducted a massive security risk, as running unverified binaries in production is very easy for developers. Truth be told, that has nothing to do with Docker and everything to do with how said teams operate.
  - monoideism 7y ago
    > IIRC, the main problem was UI/UX Best container UX I've had so far was with `lxd`, which is Ubuntu's `lxc` container manager (which is why the GP was asking about). I found it more pleasant to work with than Docker, particularly early Docker.
contingencies 7y ago
Actually lxc only appeared a few years before. It was based on original work in the kernel donated by IBM, who had originally intended it to be used to safely segregate the mega-resources on their mega-mainframes to individual non-mega workloads. (Source: I was using lxc a few years before, circa 2010, which is now 10 years ago. I had direct communications with the authors. I also submitted issues to docker outlining significant security issues early on, and made this summary of the space with skepticism around docker's already marketing-hype unreality: 'original post' and rest of page for context at http://stani.sh/walter/pfcts/ http://stani.sh/walter/pfcts/ ... the amusing thing is, the core solution identified (virtualization/topology/OS/local-remote paradigm neutral orchestration with CI/CD integration friendliness as a first class feature) is still painfully relevant and unfulfilled today, even as https://microk8s.io/ https://microk8s.io/ and similar make local work and some deployment easier, and the money in cloud IaaS services reaches 'staggering')

Maybe docker had a little bit of hype? But openvz n lxc have been around for a long time..

itsmefaz 7y ago

Was there a reason why they didn't take off like docker did?

znpy 7y ago
Usability/ergonomic. Docker was/is a lot simpler to grasp. That eases adoption.
lowdose 7y ago
Docker came with the container metaphor.
rumanator 7y ago
IIRC, the main problem was UI/UX. Docker containers in essence are a bit like running isolated Linux processes in a chrooted and cgrouped environment. Chroot exists for decades, and so does cgroups. Yet, Docker came up with a UI and UX which, among other things, let you download and run isolated Linux processes by simply running 'docker run <container name>', thus shoving everything well under the rug and practically eliminating the need to pull any arcane trick to get Linux processes to run in isolation.
- kazen44 7y ago
  running processes in isolation has been happening for a long time. (jails for instance, have existed for a very long time and freebsd has been used a lot for hosting services in the past). while i agree docker solved the UI/UX problem, it also introducted a massive security risk, as running unverified binaries in production is very easy for developers. Most shops don't have any private repository in use nor do they have the people (anymore) to build proper processes and systems around running code in production.
  - rumanator 7y ago
    > also introducted a massive security risk, as running unverified binaries in production is very easy for developers. Truth be told, that has nothing to do with Docker and everything to do with how said teams operate.
- monoideism 7y ago
  > IIRC, the main problem was UI/UX Best container UX I've had so far was with `lxd`, which is Ubuntu's `lxc` container manager (which is why the GP was asking about). I found it more pleasant to work with than Docker, particularly early Docker.

contingencies 7y ago

Actually lxc only appeared a few years before. It was based on original work in the kernel donated by IBM, who had originally intended it to be used to safely segregate the mega-resources on their mega-mainframes to individual non-mega workloads. (Source: I was using lxc a few years before, circa 2010, which is now 10 years ago. I had direct communications with the authors. I also submitted issues to docker outlining significant security issues early on, and made this summary of the space with skepticism around docker's already marketing-hype unreality: 'original post' and rest of page for context at http://stani.sh/walter/pfcts/ http://stani.sh/walter/pfcts/ ... the amusing thing is, the core solution identified (virtualization/topology/OS/local-remote paradigm neutral orchestration with CI/CD integration friendliness as a first class feature) is still painfully relevant and unfulfilled today, even as https://microk8s.io/ https://microk8s.io/ and similar make local work and some deployment easier, and the money in cloud IaaS services reaches 'staggering')