Distributions

Sandstorm personal cloud platform

By Jake Edge
June 25, 2014

Containerization is popular these days, with technologies like Docker having made a big splash recently. But earlier containerization efforts like LXC (which Docker was at one time based on) and OpenVZ laid the foundation, and newer efforts like Sandstorm may take the technique even further. Sandstorm is an early-stage project that bills itself as a "personal cloud platform". It is targeted at solving some of the same kinds of problems that FreedomBox is trying to solve, such as allowing users to take control of their own data.

Containers are not really Linux distributions per se, but they solve some of the same problems, particularly in the area of packaging. Both Docker and Sandstorm provide a mechanism to distribute Linux applications that is quite different from what users of traditional distributions have become accustomed to. Each Sandstorm container is, in some sense, a mini-distribution focused on providing just the environment needed by a particular application. All of the binaries, libraries, configuration, and so on, are collected up into the container so that they are available to a particular application instantiation, but not to other applications.

That isolation is why lead developer Kenton Varda (who developed the open source version of Protocol Buffers while at Google) calls the containers "sandboxes". The idea is to isolate each application instance in its sandbox so that it cannot affect any of the other applications running in sandboxes on the same host. There is still a fair way to go before that goal is realized. As the Caveats section on the Sandstorm GitHub page indicates: "At present, Sandstorm's sandboxing is incomplete. Malicious code probably can escape. Malicious code definitely can DoS your server by consuming all available resources."

For applications to work in this new, sandboxed world, they will need to be packaged up differently, using the Sandstorm tools. The porting guide shows how to use those tools. The basic mechanism is to install the application on a development server, which will observe an application in action while recording all of the files that it uses during its execution. That list of files, potentially with tweaks made by the developer, can then be used to create a container that will run the application when it gets installed on a Sandstorm server.

The vision is to have these applications available in an "App Store" of sorts, where the applications can be easily installed by users onto their own Sandstorm server (or as instances under their control on a shared Sandstorm server). There would be no command-line interaction required, as "the only way you ever interact with an app is through your web browser", Varda said in the Sandstorm Development Google Group. He was answering a question about the differences between Sandstorm and Docker, and continued:

The intent is that a non-tech-savvy end user should be able to operate their Sandstorm server intuitively. Moreover, Sandstorm is designed to allow much finer-grained containers. When running Etherpad on Sandstorm, each document actually lives in an isolated container.

This leads to several very different design choices:

Containers only run while you have them open in your browser. Once you close the browser, the container is shut down, and then restarted the next time you return. (This implies that containers have to start up very fast.)
Most of the container's filesystem is read-only, so that all containers can share common files (such as the application binary). Only /var is writable, and that's where it stores data specific to the particular document.
Containers do not usually run any background daemons. Just a web server for the app itself.
Containers do not use OS-level user accounts.
HTTP requests going into the container must pass through the Sandstorm front-end, which handles authentication and access control so that the application doesn't have to. Thus apps are easier to write and many kinds of possible security bugs in apps are avoided.

The project is quite new, as it was announced by Varda on March 24. The plan is for Sandstorm to use Varda's follow-up to Protocol Buffers, called Cap'n Proto, for remote procedure calls (RPCs) between the sandboxed applications. The permissions for doing so would be managed through a powerbox-like graphical user interface (GUI). Currently, Sandstorm's API only allows sandboxed applications to handle HTTP and WebSocket requests, but much more is planned.

The big picture is all about users taking control of their own data, so that it can't be misappropriated, spied upon, data mined, or simply vanish if the service where it is stored decides to close up shop. There's a lot to do to get there. Even with a platform that handles problems like security and authentication, as Sandstorm is envisioned to do, there will need to be a large number of cooperating applications to make for a viable ecosystem. The current crop of Sandstorm apps is small, with just a handful of simple apps that can be installed either on local Sandstorm servers or on the managed instances that those who have signed up and been invited to join the Alpha test can use.

Overall, Sandstorm is an interesting idea of what user-controlled services could look like down the road. It remains to be seen if enough users actually care about that control and are willing to do something about it. The promise of total app isolation, such that malicious apps can do no real damage, is intriguing, as is having a user-friendly way to set it all up and get it running. There's a lot of promise, but it may be difficult to nurture a robust, cooperating app ecosystem, which could make for a fairly large hurdle for the project. In any case, it is an ambitious vision and it will be interesting to watch where Sandstorm goes from here.

[ Thanks to Jim Garrison, who reminded us about a topic that has been on our list for a while now. ]

Comments (4 posted)

Brief items

Distribution quotes of the week

Wait.. I thought Sid was the long term support release all these years? I mean I know people who have been running Sid since 1999 or so.

-- smoogen

I think it’s reasonable that someone who is considering donating their time to a project would want to start doing something productive immediately. If someone has to spend many hours learning how things work before contributing anything of value they may decide that it’s not a good use of their time – or just not fun. Also if the project is structured to require a lot of background knowledge then that will increase the amount of time that long-term contributors spend teaching newbies which is another way of sucking productive energy out of a project.

-- Russell Coker

We'll use super cow powers to coerce CAs into trustworthiness.

-- Jakub Wilk

If you're not sure whether removing systemd or glibc is a bad idea, perhaps having root access isn't the best plan in the world.

-- Richard Hughes

Comments (17 posted)

Distribution News

Debian GNU/Linux

Debian switching back to Glibc

Aurelien Jarmo reports that the Debian Project is switching back to the GNU C Library and will no longer ship the EGLIBC fork. The reason is simple: the changes in the Glibc project mean that EGLIBC is no longer needed and is no longer under development. "This has resulted in a much more friendly development based on team work with good cooperation. The development is now based on peer review, which results in less buggy code (humans do make mistakes). It has also resulted in things that were clearly impossible before, like using the same repository for all architectures, and even getting rid of the ports/ directory."

Comments (6 posted)

Ubuntu family

Ubuntu 13.10 (Saucy Salamander) reaches End of Life

Ubuntu 13.10 was released on October 17, 2013 and will reach its end-of-life on July 17, 2014. The supported upgrade path from Ubuntu 13.10 is via Ubuntu 14.04 LTS.

Full Story (comments: none)

Newsletters and articles of interest

Distribution newsletters

Last Week in CyanogenMod (June 19)
DistroWatch Weekly, Issue 564 (June 23)
Ubuntu Weekly Newsletter, Issue 373 (June 22)

Comments (none posted)

Whatever Happened to These Red-Hot Linux Distros? (Linux.com)

Carla Schroder looks at three distributions that were once very popular. "Way back around 2003 entrepreneur and technologist Warren Woodford released the first version of SimplyMEPIS. Mr. Woodford felt that the popular desktop Linux distros had too many rough edges, so he built his own sleek distro based on Debian and KDE 3.1.2. New releases appeared every 6-12 months, and each release was more polished and user-friendly. Nice helper utilities like MEPIS X-Windows Assistant, MEPIS System Assistant, and MEPIS Network Assistant made system administration easier. It hit the upper range of the DistroWatch rankings and stayed there for several years."

Comments (2 posted)

A Linux distribution for science geeks (Opensource.com)

Amit Saha introduces Fedora Scientific, a Fedora spin. "If you use open source software tools such as GNU Octave, IPython, gnuplot, and libraries such as SciPy and GNU Scientific library in your work—and you write papers and reports in LaTeX—Fedora Scientific is for you. When you install it, you get these and a number of other applications that you may be using to get your scientific work done. The Fedora Scientific guide aims to help you learn about the included software. It features pointers to resources, so you can learn more about them."

Comments (none posted)

Linux Deepin Brings Mac-Like Sensibility to the Linux Desktop (Linux.com)

Over at Linux.com, Jack Wallen reviews Linux Deepin. "But then along comes Linux Deepin, a distribution from China that looks to upturn the Linux desktop with an almost Apple-like sensibility. Linux Deepin offers a keen UI design that outshines most every desktop you’ve experienced. Along with that total redesign of the UI, comes a few bonus apps that might easily steal the show from most default apps."

Comments (1 posted)

Page editor: Rebecca Sobol
Next page: Development>>