It's creating the VirtualBox of Linux Containers. Docker image files are extremely light weight when compared to VirtualBox images and use Union File systems to allow for complete isolation rather than using VM volumes.
An example scenario for when you'd want something like this is if you want to load an experimental library for a specific application that some part of your system depends on the stability of. Fire up a docker image for just that application with the experimental library replacing the stable library and just the applications inside the docker image will see it. No need to even play around with library versions or links. And since the Docker images are so light weight and incur extremely little performance penalty (I think it is limited to just the cost of using the Union FS over your normal FS), you can do this for dozens of scenarios at once.
Eventually, there may be some way to merge images together, though I imagine that will always be a little harry compared to a simple stack up.
Documentation is more than a little sparse right now, unfortunately. It took me a few days to figure out how all the pieces work together.
lxc is a tool for sysadmins to deploy and configure virtual servers on their machines.
docker is a tool for developers to package their application into a deployable object without worrying about how the sysadmin will deploy it, and for sysadmins to deploy applications without worrying about how they were packaged.
When you tinker long enough with lxc, eventually you start building something like docker on top of it, because it just makes sense. Now instead of reinventing the wheel you can just use docker.
No no no. Do NOT do this. Kids these days...
Edit: Ironically Docker itself has the potential to help solve the problem of running untrusted open source code. I think every open source project should include either a Dockerfile or Vagrantfile to help users get up and running quickly, and safely run untrusted projects.
For example, I would notice that it requires apt-get
echo "Ensuring basic dependencies are installed..."
apt-get -qq update
apt-get -qq install lxc wget bsdtar
Then it downloads some binary into /usr/local/bin, at this point, I'd probably configure a VM to review this further.How is this different, other than a graphical installer being completely unauditable, whereas curl|sh is quite trivially auditable? Both run code as root.
But the URL should be HTTPS.
Of course, don't do this on your most beloved production machine, if you can package it properly, test it, etc
But rendering a font gives execution with your user, so don't be so afraid of a installer "you can read" and has an interesting purpose.
Would you point us to a reference, or a further explanation for this claim ? I am genuinely interested...
The usability of the curl pipe approach is here to stay, so the least we can do is help people be safe with it.
Anyone have other ideas for making curl pipes safer?
Food for thought: http://www.cs.dartmouth.edu/~sergey/langsec/
p.s. I know, that there should not be direct copy-paste from browser to console and this method leaves a file in /tmp on installation failure
I don't think this is true. It's just going to take a very popular project getting their DNS hijacked before everyone wakes up.
Well, you are right about the usability part. That part is amazing. It's just that curl-pipe is not the answer.
Gtk+, the widget toolkit used to develop GNOME and many free software applications, supports rendering applications via HTML5. One of the developers has demonstrated using it to run desktop applications on OpenShift, Red Hat's PaaS, that you then access via your web browser.
http://blogs.gnome.org/alexl/2013/03/19/broadway-on-openshif...
http://blogs.gnome.org/alexl/2013/04/03/more-gtk-in-the-clou...
The idea behind NX is to "fake" an X client on the server side and fake a NX server on the client side. This reduces the number of roundtrips required for each action. The improved responsiveness is dramatic -- even on a low speed and high-latency link, using the remote desktop feels like a local machine...
http://en.wikipedia.org/wiki/NX_technology
Unfortunately, the two open source projects which aimed to reproduce the NX functionality seem to have been abandoned. http://freenx.berlios.de/
http://code.google.com/p/neatx/source/list
Is anyone using NX these days? Perhaps, people stopped developing these because they work well already?Is there any open-source equivalent to things like Citrix's XenApp, VMWare's ThinApp, Microsoft's App-V, or independent tools like Sandboxie? http://alternativeto.net/software/sandboxie/
how is this any better than simply running virtualbox on your OS to begin with?
http://stackoverflow.com/questions/16296753/can-you-run-gui-...