3 ms·

From my initial skimming of the source code, this is not just a web interface in front of the package manager of your favourite distro -- the apps need not be t

by plq 12y ago

From my initial skimming of the source code, this is not just a web interface in front of the package manager of your favourite distro -- the apps need not be trusted and work isolated from the host operating system. But why not use docker instead of reinventing things like namespace instrumentation? EDIT: Answering my own question: https://groups.google.com/forum/#!searchin/sandstorm-dev/docker/sandstorm-dev/_I7cHARMrZA/chEWWcIo600J https://groups.google.com/forum/#!searchin/sandstorm-dev/doc...

kentonv 12y ago
Setting up Linux namespaces using the raw syscalls is actually not very hard. Sandstorm does this in a few dozen lines of code. Adding Docker as a dependency would add a whole lot of complication without actually buying us much. There is a big difference is use case here: Docker aims to be configurable enough that you can take arbitrary off-the-shelf Linux apps -- or even entire distros -- and make them run in a container. Sandstorm, on the other hand, requires apps to be ported to a very specific environment. The porting isn't usually very hard, but it means Sandstorm doesn't need so much configurability and can make stronger assumptions about how an app behaves which lets us do more interesting things with it. For example, Sandstorm can implement unified login and sharing across all apps, it can enforce security between apps, it can transparently update an app without potentially disrupting its storage, and it can selectively give apps access to each other's semantic APIs rather than just low-level ports. All that said, using Docker as a tool to assist in building app packages may make sense; we actually build some of our apps this way. This -- and the general difference between Docker and Sandstorm -- was discussed a bit in this blog post: https://blog.sandstorm.io/news/2014-05-12-easy-port.html https://blog.sandstorm.io/news/2014-05-12-easy-port.html

by plq 12y ago

kentonv 12y ago

Setting up Linux namespaces using the raw syscalls is actually not very hard. Sandstorm does this in a few dozen lines of code. Adding Docker as a dependency would add a whole lot of complication without actually buying us much. There is a big difference is use case here: Docker aims to be configurable enough that you can take arbitrary off-the-shelf Linux apps -- or even entire distros -- and make them run in a container. Sandstorm, on the other hand, requires apps to be ported to a very specific environment. The porting isn't usually very hard, but it means Sandstorm doesn't need so much configurability and can make stronger assumptions about how an app behaves which lets us do more interesting things with it. For example, Sandstorm can implement unified login and sharing across all apps, it can enforce security between apps, it can transparently update an app without potentially disrupting its storage, and it can selectively give apps access to each other's semantic APIs rather than just low-level ports. All that said, using Docker as a tool to assist in building app packages may make sense; we actually build some of our apps this way. This -- and the general difference between Docker and Sandstorm -- was discussed a bit in this blog post: https://blog.sandstorm.io/news/2014-05-12-easy-port.html https://blog.sandstorm.io/news/2014-05-12-easy-port.html