4 ms·

What about LXC? Is there just no community interest for this feature?

by gagdad 10y ago

colemickens 10y ago
I would hope/expect to see systemd-nspawn support before LXC directly.
themgt 10y ago
If you've ever looked at the underlying code of "LXC" it's basically a bunch of spaghetti scripts that utilize cgroups. It was awesome for its time, but it's really not something worth supporting in 2016 vs. the new container runtimes.
- throw2016 10y ago
  This is extremely misinformed. When did you last look at it? Can you post some examples of the spagetti scripts mentioned? What features do the 'new 2016 container run times' have that the LXC project did not provide initially and does not have? Really? It's sad to see this level of dimissive reductive fud being used against the LXC project liberally and consistently especially here on HN to promote other container solutions. A quick visit to linuxcontainers.org or the LXC github repo will quickly and dramatically dispel such notions. The LXC project is written in C and has been in development since 2009 along with cgroup and namespace support in the kernel. It's mature, robust and easy to use. It provides advanced container networking options from veth to macvlan and supports aufs, overlayfs, btrfs, LVM thin, ZFS for snapshots and clones, since at least 2011. It was also the first to support unprivileged containers with its 1.0 release in 2013. It's this work that Docker was based on and its unfortunate the ecosystem far from highlighting the benefits they got many choose to downplay and misrepresent the LXC project leading to comments like the above. LXC is now on 2.0 with multiple improvements from proper display of cgroup controls and container resource usage inside containers with the lxcfs project to initial support for live migration. It is also significantly easier to use than single app containers especially for multiple processes and networking without needing to create custom process managers, run apps in specific ways or network workarounds. LXC runs the container OS's init in the container, Docker and others do not. There are reasons for both approaches. Hope for better informed discussions on Linux containers here.
  - rdtsc 10y ago
    Some of it is powered by fans and those who bought into the hype of some of the commercial entities pushing their containerization. I think at some point to make what they bought in look good, they have to put down what others have. That happens pretty much with any popular technology. Remember, how Javascript on the server was "async", and therefore better, and was going to kill all the other languages and frameworks? Kinda the same idea.
  - SEJeff 10y ago
    Well the big one that LXC does and has always lacked is a story for how to ship code. Docker has distribution / hub, rkt has quay, LXC has... nothing. If LXC had a registry long ago, I suspect you'd see a lot more people using it directly. Now the big difference is that LXC is mostly (as of right now) a Canonical project and they have a habit of trying to compete with the world. LXD looks interesting from a technology POV, somewhere between Intel's Clear Containers (where they seem to have gotten the idea from), and Docker. I don't see it really gaining any traction however. A few examples that spring to mind of them competing with the world and for the most part, failing: * bzr - if you want a python vcs, use mercurial * Upstart - we all know how well that worked out * Dekko - their fork of the lightweight email client Trojita * juju for config management. This one is arguably one of the best things Canonical has produced tech wise * Unity/hacked up GNOME - because working with upstream is boring, and the world wants lots of Ubuntu phones * Their own window manager, Mir, because they can do it better than Xorg developers who are writing Wayland with decades of experience. The list goes on and on.
    - colemickens 10y ago
      Huh? LXD is Canonicals, but I don't think LXC is in any sense a "Canonical" project? (I thought) LXC's primitives are what Docker is actually using. Why would LXC need a registry any more than say Rkt? scp a tarball, or host the tarball on an https endpoint? Done, no?
      - natermer 10y ago
        Docker stopped used LXC stuff a while ago. Sure docker uses Linux namespaces and such, but that has a lot more to do with OpenVZ then LXC. People seem to like LXC because they want to treat containers as 'light weight virtual machines' and run full stack Linux OSes in them with init systems and multiprocesses and such things. However that isn't the direction the industry is moving, which is focusing on containers as simple runtime packaging were you have the absolute minimum needed to run a single application. RKT is interesting because it doesn't depend on a a separate daemon to manage containers. Instead you use the host's systemd daemon to manage containers in a similar way you manage everything else in a system. It simplifies things like managing cgroups and improves reliability.

What about LXC? Is there just no community interest for this feature?

by gagdad 10y ago

What about LXC? Is there just no community interest for this feature?

colemickens 10y ago

I would hope/expect to see systemd-nspawn support before LXC directly.

themgt 10y ago

If you've ever looked at the underlying code of "LXC" it's basically a bunch of spaghetti scripts that utilize cgroups. It was awesome for its time, but it's really not something worth supporting in 2016 vs. the new container runtimes.

throw2016 10y ago
This is extremely misinformed. When did you last look at it? Can you post some examples of the spagetti scripts mentioned? What features do the 'new 2016 container run times' have that the LXC project did not provide initially and does not have? Really? It's sad to see this level of dimissive reductive fud being used against the LXC project liberally and consistently especially here on HN to promote other container solutions. A quick visit to linuxcontainers.org or the LXC github repo will quickly and dramatically dispel such notions. The LXC project is written in C and has been in development since 2009 along with cgroup and namespace support in the kernel. It's mature, robust and easy to use. It provides advanced container networking options from veth to macvlan and supports aufs, overlayfs, btrfs, LVM thin, ZFS for snapshots and clones, since at least 2011. It was also the first to support unprivileged containers with its 1.0 release in 2013. It's this work that Docker was based on and its unfortunate the ecosystem far from highlighting the benefits they got many choose to downplay and misrepresent the LXC project leading to comments like the above. LXC is now on 2.0 with multiple improvements from proper display of cgroup controls and container resource usage inside containers with the lxcfs project to initial support for live migration. It is also significantly easier to use than single app containers especially for multiple processes and networking without needing to create custom process managers, run apps in specific ways or network workarounds. LXC runs the container OS's init in the container, Docker and others do not. There are reasons for both approaches. Hope for better informed discussions on Linux containers here.
- rdtsc 10y ago
  Some of it is powered by fans and those who bought into the hype of some of the commercial entities pushing their containerization. I think at some point to make what they bought in look good, they have to put down what others have. That happens pretty much with any popular technology. Remember, how Javascript on the server was "async", and therefore better, and was going to kill all the other languages and frameworks? Kinda the same idea.
- SEJeff 10y ago
  Well the big one that LXC does and has always lacked is a story for how to ship code. Docker has distribution / hub, rkt has quay, LXC has... nothing. If LXC had a registry long ago, I suspect you'd see a lot more people using it directly. Now the big difference is that LXC is mostly (as of right now) a Canonical project and they have a habit of trying to compete with the world. LXD looks interesting from a technology POV, somewhere between Intel's Clear Containers (where they seem to have gotten the idea from), and Docker. I don't see it really gaining any traction however. A few examples that spring to mind of them competing with the world and for the most part, failing: * bzr - if you want a python vcs, use mercurial * Upstart - we all know how well that worked out * Dekko - their fork of the lightweight email client Trojita * juju for config management. This one is arguably one of the best things Canonical has produced tech wise * Unity/hacked up GNOME - because working with upstream is boring, and the world wants lots of Ubuntu phones * Their own window manager, Mir, because they can do it better than Xorg developers who are writing Wayland with decades of experience. The list goes on and on.
  - colemickens 10y ago
    Huh? LXD is Canonicals, but I don't think LXC is in any sense a "Canonical" project? (I thought) LXC's primitives are what Docker is actually using. Why would LXC need a registry any more than say Rkt? scp a tarball, or host the tarball on an https endpoint? Done, no?
    - natermer 10y ago
      Docker stopped used LXC stuff a while ago. Sure docker uses Linux namespaces and such, but that has a lot more to do with OpenVZ then LXC. People seem to like LXC because they want to treat containers as 'light weight virtual machines' and run full stack Linux OSes in them with init systems and multiprocesses and such things. However that isn't the direction the industry is moving, which is focusing on containers as simple runtime packaging were you have the absolute minimum needed to run a single application. RKT is interesting because it doesn't depend on a a separate daemon to manage containers. Instead you use the host's systemd daemon to manage containers in a similar way you manage everything else in a system. It simplifies things like managing cgroups and improves reliability.