Hacker News new | past | comments | ask | show | jobs | submit login

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.



LXC has always had a registry of base os images. LXC is a normal open source project and is not VC funded and does not have a lot of the building wall kinds of features like the hub and tons of others things that others would embrace.

LXC's problem is near zero marketing and the significant muddying of the waters about containers by the vc funded docker ecosystem which launched off LXC. How does one position LXC or LXD as 'NIH' when others based off it, or misrepresent it as low level when it has far more sophisticated tools, features and maturity?

Isn't it an irony for all the criticism of bash scripts from the docker ecosystem the Dockerfile is actually a bash script. There still remains way too much misinformation about containers here on HN and it damages informed discussion and credibility. VC funded companies should not be allowed to hijack open source projects in this manner without due credit and proper information.

Lets talk about overlayfs, aufs, namespaces, cgroups and all the Linux components that are containers. Are these projects to work in anonymity without any credit or rewards while VC funded companies suck the value and momentum. Is this the 'open source model' hn wants to support. Compete on value not disinformation. This only leads to low quality discussions.

Ubuntu tends to do their own thing and I don't particularly see anything wrong with diversity. What I find more galling is this underhanded positioning of anything not controlled by Redhat as NIH. Is systemd, nspawn criticised as nih. Flatpak is not dimissed as NIH but Snappy is. How does this kind of brazen manipulation happen? I can't fathom ordinary unbiased users thinking in this way and this kind of politics is becoming a problem for informed discussion and wider choice in Linux. Unity is surprisingly polished for a Linux project and I would not have even tried if I didn't look beyond the prevailing prejudice. Let's not do this.


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?


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.


I do believe the latter two are another case of "we have commit rights, you don't so go away" from the Gnome and Wayland teams respectively.

https://plus.google.com/+TheodoreTso/posts/4W6rrMMvhWU




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: