Wow! Did not expect this to show up on HN before actual release! (I work at dotCloud). We're still polishing a few rough edges. If you want early access add your github ID to this thread and we'll add you right away!
alexchamberlain
Docker - the Linux container runtime
91–100 of 209 posts
Re: Docker - the Linux container runtime
#92Wow! Did not expect this to show up on HN before actual release! (I work at dotCloud). We're still polishing a few rough edges. If you want early access add your github ID to this thread and we'll add you right away!
github: tomjohnson3
Re: Docker - the Linux container runtime
#93Wow! Did not expect this to show up on HN before actual release! (I work at dotCloud). We're still polishing a few rough edges. If you want early access add your github ID to this thread and we'll add you right away!
kolektiv on GH too.
Re: Docker - the Linux container runtime
#94Wow! Did not expect this to show up on HN before actual release! (I work at dotCloud). We're still polishing a few rough edges. If you want early access add your github ID to this thread and we'll add you right away!
github: fgrehm
Re: Docker - the Linux container runtime
#95Earlier quoted context omitted.
I'm just presuming, but: 1. every one of those attributes would be fixed against a given version of the (coming) Docker spec, and a given host would specify what version(s) of the spec they were compatible with. 2. Go is, I think, just the language the glue code is written in; not the language your own things-deployed-using-Docker must be written in. 3. It might support other Linux distros (Fedora, probably), but it…
The trick here is that their xmame (Docker) may not be the same build on all hosts, so it may not play the ROMs all in the same way or support all ROMs. A standard works to improve interoperability between different builds/hosts/etc as well as provide an expected set of operations and their results. If all they provide is just one version of one product and call that standardized, that's like releasing a new version…
Well, this is a good first step in the "free market" standardization process, though: get a public implementation out of what you would imagine standard-conformance to look like. Then, let the other guys (e.g. Heroku) get out their competing implementations. Then, find the similarities, resolve the differences, and write it down. Now you've got a standard.
Re: Docker - the Linux container runtime
#96Wow! Did not expect this to show up on HN before actual release! (I work at dotCloud). We're still polishing a few rough edges. If you want early access add your github ID to this thread and we'll add you right away!
github: mharris717
Re: Docker - the Linux container runtime
#97Wow! Did not expect this to show up on HN before actual release! (I work at dotCloud). We're still polishing a few rough edges. If you want early access add your github ID to this thread and we'll add you right away!
Github: jwhitlark
Looks really useful.
Re: Docker - the Linux container runtime
#98Wow! Did not expect this to show up on HN before actual release! (I work at dotCloud). We're still polishing a few rough edges. If you want early access add your github ID to this thread and we'll add you right away!
github.com/radim
Re: Docker - the Linux container runtime
#99Earlier quoted context omitted.
(Copying my answer to a similar question) Yes, you probably don't want to run untrusted code with root privileges inside a container if anything valuable is running on the same host. However if that code is trusted, or if you're running it as an unprivileged user, or if nothing else of importance is sharing the same host, then I would not hesitate to use them. Containers are awesome because they represent a logical c…
you're trying to justify the use of lxc for security, IMO. Your webpage does state "strong guarantees of isolation" if you're sharing nothing of importance on the host, then, you don't really need LXC, unless you don't know how to setup mysql with more than one database, nginx with more than one virtual host, yada yada. Here's the trick: you CAN use LXC and SUPPLEMENT it by something providing security such as SELinu…
or use OpenVZ which has been designed with security in mind ;)
Re: Docker - the Linux container runtime
#100Note that LXC DOES NOT PROVIDE SECURITY. It provides resource separation (to a point) and so on. Breaking out of a filesystem container is as easy as creating a root block device. Breaking out of a network container is as easy as creating a network device And in all cases, you can just inject memory, load lkms, etc. That's without mentioning the amount of weekly CVEs for Linux namespaces.
> LXC DOES NOT PROVIDE SECURITY
This is out of date. As of Linux 3.8, or with out-of-tree patches in older kernels, LXC puts each container in its own user namespace, so that root in the container has no privileges outside. LXC also uses network namespaces, so the user inside the container can only do on the network what the admin allows them to do.
Because root inside a user namespace is unprivileged outside it, it can't scribble on memory or load modules, etc., either.
See https://wiki.ubuntu.com/LxcSecurity for a decent summary of the situation in Ubuntu's releases. Several Ubuntu contributors are also among the main drivers of LXC upstream.
It's true that user namespaces and other kernel features LXC relies on are beginning to get much more use than they used to, and probably still have flaws, though I think you exaggerate how many CVEs are actually being found. Ubuntu's LXC support also uses apparmor and seccomp to provide further isolation. Conservative users will probably wait a while more to see what bugs get shaken out.