I missed the previous posts about Sandstorm and I'm glad this was posted. It's a very interesting technology and the team behind it is very talented.
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.
This looks interesting. I have been using App Engine for a while, but getting a little sick of the restrictive environment. I think I will give this a try.
I haven't played with it yet, no, but I work close to the bottom of the stack (in the nitty gritty bits of virtualization stuff); modern Linux kernels all look more or less the same from way down here :)
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:
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.
I was really excited to see (emerging) support for docker on GCE; I went to check it out and started setting things up but slowly realized the system administration burden wasn't going to make sense for a small userbase, i.e. me.
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.
I haven't heard about Sandstorm before and while I'm not sure how it works yet, from the brief look at the project page I can tell one thing - they have their philosophy in the right place. I'll be following it closely because I appreciate someone finally noticing that the web and the cloud is frikkin' backwards and doing something about it.
Thanks! Hoping you'll find we know what we're doing technically as well. :)
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!
The biggest challenge to Sandstorm on the desktop would be that Sandstorm is very much tied to Linux. We make extensive use of Linux features that no other OS currently has, and Sandstorm apps are built as Linux binaries.
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.
> ... you can run Sandstorm locally today. It should work just fine, except that it will be harder to share your things with other users.
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.
I wonder if Sandstorm has a chance of being broadly adopted by NAS vendors as an alternative to their own packaging mechanisms for 3rd-party software (e.g. QNAP's qpkg).
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.
But see, those are kernel features, not Docker features. We use them in different ways from Docker. You wouldn't say that two apps should obviously share code just because they both open files. But using a file is honestly at least as complicated as setting up a namespaces.
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.
Thanks for posting this, as it made me aware of your service.
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've thought about this sort of thing for a long time, it's always been possible, but I think the corporate cloud companies have distinctly tried to prevent anyone from realizing it. The cloud era has led users to sacrifice so many freedoms they never even realized they lost, making compromises they never should've been forced to.
Personally, I think copyleft licenses are somewhat abusive by nature. It's not really making a contribution to society if you leave a bunch of strings attached to tell people how they can use it.
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.
28 comments
[ 2.8 ms ] story [ 76.2 ms ] threadA 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.
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....
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.
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.
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.