Why doesn't Sandstorm just run Docker apps?
blog.sandstorm.io
blog.sandstorm.io
Platforms like Sandstorm are exactly the reason why we opened up libcontainer: so that others can benefit from the firehose of engineering that goes into Docker, without having to buy into the entire platform. Once the C implementation is complete it should be even easier to use libcontainer in other languages.
That said, I think some of the new Docker APIs we are working on would be a good match for Sandstorm as well. But thanks to the beauty of small, loosely coupled components, we can have that conversation some other time :)
I'm glad you're making libcontainer, but I'm still not sure what Sandstorm would gain from it. At the end of the day, most of the work going into libcontainer is all about making containerization totally transparent to the app and supporting a wide range of Linux platform features. These are obviously key features of Docker and useful to many other uses of containers, but simply not a goal for us. E.g. I see selinux and apparmor mentioned in libcontainer's code, but Sandstorm's security model does not need nor want them. For our case, a couple dozen syscalls to set up our container is really all we need. Sandstorm's own code base actually even contains three different components that set up different kinds of containers, but we don't share code between them because there's just not much worth sharing.
Funny thing: I think I get your e-mail sometimes. I'm temporal at gmail, you appear to be temporal.pl. I get all kinds of e-mail from people who simply strip off anything after a '.' because they apparently don't realize it's important!
Anyway, so you're the guy who's taking my nickname on all the services, forcing me to add _PL or .pl everywhere?!... :D. Nice to finally meet you!
Do you think this could scale down to desktops as well? There could be two ways of doing it:
1. Have user locally install apps-with-web-frontends on the desktop. Use P2P technologies for communication between the apps.
2. Have user locally install apps with native UIs. They either communicate to a sandstorm cloud backend or use local sandstorm instance.
#1 will be easier for you but a little harder for developers (web-apps are a little difficult to develop compared to native apps).
That said, if you have a Linux desktop or are willing to run a VM, then you can run Sandstorm locally today. It should work just fine, except that it will be harder to share your things with other users.
For #2, there are two possibilities:
1. The app runs outside of Sandstorm, but talks to your Sandstorm server. We intend to make this possible soon.
2. The app runs inside Sandstorm. It's theoretically possible to design something like this on top of Sandstorm, but it would take some engineering work to define the protocol that the app uses to talk to the display / window manager while keeping it properly sandboxed. This would be a fun project, but it's not something we have any plans to work on.
True, that's why it would be nice to design a P2P system into Sandstorm.
On the technical front, the Java run-time is actually pretty well designed and has a solid sand-boxing model too. If only it were fully open-source and wasn't guarded with over-zealous lawyers.
for example... http://www.eros-os.org/pipermail/e-lang/2009-February/012983...
and a historical perspective... http://www.eros-os.org/pipermail/e-lang/2001-January/004030....
A few of the projects I'm working on involve hosting applications for many customers but I'm also a firm believer in the rights of a user to take their data and move to another platform.
Seeing the one-click demo to spin up a working Roundcube email installation, Ghost or Wordpress installation, or web-based office application makes this inspire the imagination.
It's certainly a technology that I want to play with over the coming weeks.
It's early stages (and I'm not involved -- I work on Compute Engine), but some of the devs lurk around HN from time to time.
Also, closer to the existing App Engine mindset: https://developers.google.com/appengine/docs/managed-vms/
Having choice is generally a good thing, but it makes the water a little murky given how similar the goals seem :).
Have you had a chance to play around with CoreOS + Docker on compute engine?
We do provide public images for CoreOS on GCE, though, and I think there are some public blog posts on getting it up and going with Kubernetes (if you wanted to go that route). From the Core OS folks:
CoreOS on GCE: https://coreos.com/docs/running-coreos/cloud-providers/googl...
And Kubernetes + CoreOS (not GCE specific): https://coreos.com/blog/running-kubernetes-example-on-CoreOS... https://coreos.com/blog/running-kubernetes-example-on-CoreOS...
Hope the helps get you going if you're looking to give things a go. If you do run into issues I'll probably forward you along to our containers folks who are much better informed about that end of the stack than I am.
That's perhaps sandstorm's biggest--or at least most visible--contribution: getting an app installed and going is just a few clicks for end-users.
Plus, for a new platform like Sandstorm to be able to meet as many use cases as possible, it does need to be something that corporations can actually build business models and proprietary systems on top of as well.
Also, about 1% of Sandstorm's code is actually dealing with those things, while the other 99% deals with implementing all the high-level features in my bullet list, none of which Docker does at all.
I just donated as I really want to see alternatives to the current web model that is, in my opinion, utterly broken.
I'm also glad to see containerization tackling so many hard problems. It has the potential to change everything (as it is the perfect sandbox, and independent of programming language).
I'm excited about this.