151–160 of 209 posts
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!
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!
Earlier quoted context omitted.
Their base layer needs to specify exact versions of libraries. Deploying from images should be much faster and less fragile (oops, is Github down?) than from scripts.
Absolutely. Think of a Docker container as a universal build artifact. Your build step can be an arbitrary sequence of unix commands (download dependencies, build libssl, run shell scripts etc.). Docker can freeze the result of that build and guarantee that it will run in a repeatable and self-contained way, no matter where you run it. So you get clean separation of build and run, which is a hugely important part of…
Not to be a stick in the mud, but you're using a copyrighted image as your logo without any attribution or acknowledgement of the original owner of the copyright (the Lego Group). You should probably fix that.
You're right! We put it up there when it was an internal project, it's probably time to take care of that. Taking it down until we found a correct way to do it. I'm a copyright noob: would simply acknowledging the copyright owner be enough and fall under fair use, or should we not use it unless we get written permission?
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!
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!
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!
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!
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!
Is this linux-vserver or openvz re implemented with lxc and cgrougs?
Earlier quoted context omitted.
Absolutely. Think of a Docker container as a universal build artifact. Your build step can be an arbitrary sequence of unix commands (download dependencies, build libssl, run shell scripts etc.). Docker can freeze the result of that build and guarantee that it will run in a repeatable and self-contained way, no matter where you run it. So you get clean separation of build and run, which is a hugely important part of…
So docker container ABI is basically the kernel? You just create a filesystem image and docker starts that as LXC guest. You could build a statically compiled binary and put that as /bin/init into the container image, right?
You wouldn't need to save it as /sbin/init. You would just type:
$ docker run MYIMAGE /path/to/my/static/binary