- extensibility - you can adapt other apps, open source or commercial, to run on sandstorm. As far as I'm aware you can even upload them to the hosted version.
- security seems to be taken good care of by pragmatic and experienced people.
- the fact that I can pay a small amount monthly for it depending on my storage and computing needs, making sure incentives are aligned (although last time I checked I think Sandstorm hadn't even started the billing machine I think.)
Furthermore it seems to be completely, real, free software, -I ran the OS version at a maching at home for months before oasis became available to me, and I haven't noticed any juicy parts missing or filed under "Enterprise only". The only difference between the versions seems to be the storage and compute resources available. (OK, the billing system doesn't seem to be in the Open Source version, but that is OK to me. : )
Kenton, thanks for all of the work you and your contributors do on sandstorm.io; I have referred this project to many people wanting to get their feet wet "running a server" as a way to do something without instantly cutting yourself. Have you considered writing a how-to article on replicating ownCloud-like functionality within Sandstorm using apps? It might be a good first step, and I believe that it has the possibility to help people move onto (what I personally believe is) a superior platform.
The biggest things I see ownCloud still having a huge advantage on is contacts and calendars, nobody's ported or written good apps for Sandstorm to do that yet.
There's an awesome file storage app called Davros though, that's actually compatible with the ownCloud desktop client for file syncing!
AFAIK sandstorm self hosting only works on 64bit x86 machines and there's certain files I don't want hosted outside my own walls. The various ARMs are great for that use case, any future plans on supporting ARM?
Otherwise sandstorm looks pretty great overall. I always appreciate a focus on security :)
The primary problem with supporting ARM is that Sandstorm apps run native binaries. So in order to support ARM, every single Sandstorm app would need to be able to also be recompiled for ARM, or you end up fragmenting the ecosystem.
I'm also not sure how many board PCs like a Raspberry Pi or what have you would handle Sandstorm well performance-wise, though I do think there's some 64-bit board PCs you can get now to try it on.
Curious, why the scripts to install a simple series of binaries? If you packaged it natively then all the stuff you're doing with both GPG and install.sh simplifies dramatically from 2k lines of bash. With added benefit of pushing out security updates or releases becomes pretty simple.
- There is sadly no universal package manager on Linux.
- A lot of that 2k-line bash script is implementing an interactive setup that configures your server, optionally claims a hostname and obtains SSL certificates, etc. A package manager wouldn't replace any of that.
- Sandstorm's auto-updater will automatically update your server within 24 hours of any release. That's actually pretty hard to achieve with package managers. Most are not designed to auto-run in a cron job. Worse, many distros have long release cycles (6 months, 2 years, etc.) during which they only accept bugfixes.
- Most package managers don't verify PGP signatures back to the upstream author, but rather to the distro maintainer (which in Debian's case is any one of thousands of people). It's debatable which is preferable, but note in any case that it's a very different property from what our installer implements.
- Sandstorm self-containerizes in its own corner of the filesystem, basically avoiding any dependency on the rest of your system other than the kernel. This strategy works well for us -- it relieves us from having to test on every distro separately, and it avoids messing up the user's system -- but it probably wouldn't meet the guidelines required to get a package into a distro. So we'd still have to distribute our packages direct from our own server, or do a _lot_ more work.
With all that said, when Sandstorm stabilizes more we do plan to figure out a way to let people "apt-get install sandstorm", since a lot of people are more comfortable with this.
Unfortunately probably not any time soon, for the same reason as ARM: Sandstorm app packages include binaries built for x86-64. We'll need a lot of tooling to make it easy for developers to package for multiple architectures. :/
Sandstorm works decently on mobile browsers, they do test it. But how well different Sandstorm apps work on mobile depends on those apps.
It's also possible to use native apps that sync to Sandstorm. My Tiny Tiny RSS instance on Sandstorm I can access through a native Android app, for instance.
At present, apps can implement HTTP and WebDAV APIs but not SFTP nor SMB. In the future we plan to generalize things so that apps could potentially implement any protocol, but we want to be careful to do it in a way that lets us keep our strong security guarantees.
Especially enjoy
- the usability of Sandstorm, -it just works.
- extensibility - you can adapt other apps, open source or commercial, to run on sandstorm. As far as I'm aware you can even upload them to the hosted version.
- security seems to be taken good care of by pragmatic and experienced people.
- the fact that I can pay a small amount monthly for it depending on my storage and computing needs, making sure incentives are aligned (although last time I checked I think Sandstorm hadn't even started the billing machine I think.)
Furthermore it seems to be completely, real, free software, -I ran the OS version at a maching at home for months before oasis became available to me, and I haven't noticed any juicy parts missing or filed under "Enterprise only". The only difference between the versions seems to be the storage and compute resources available. (OK, the billing system doesn't seem to be in the Open Source version, but that is OK to me. : )