Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Sandstorm Team Is Joining Cloudflare

sandstorm.io

Post reply on HN
Print view View original

51–60 of 108 posts

Re: The Sandstorm Team Is Joining Cloudflare

#51

Post by kentonv »

shawn-butler wrote: post #50
kentonv wrote: post #46

Earlier quoted context omitted.

Correct. The CF people are cool and have no problem with us continuing to operate Sandstorm, as long as we're getting our Cloudflare work done. Cap'n Proto will presumably end up with mixed copyright, but it's MIT license anyway so who cares?

I'm sure you have already but look over that employment contract carefully. CF being "cool" shouldn't put your project and its users (me!) at risk.

Yes, we have made sure to add appropriate language to the appropriate paperwork (in addition to being protected by California law).

Re: The Sandstorm Team Is Joining Cloudflare

#52

Post by educar »

derefr wrote: post #35
the_common_man wrote: post #31

Best of luck, kenton! If anyone is looking for alternatives: http://alternativeto.net/software/sandstorm-io/ . I think Cozy, Yunohost, Cloudron, arkOS are the closest alternatives (Bitnami is about 1-click images and DO/linode are about cloud servers). Would be great to hear about other alternatives...

AFAIK Sandstorm was way out ahead of its competitors in this space; it was the only one HN ever deigned to pay attention to, at least. Given that, and given that it's FOSS, then as long as the community is still interested in the project, the project should keep seeing development, regardless of the amount of time the original developers can put in. Even if that means a LibreOffice- or MariaDB-like fork.

> AFAIK Sandstorm was way out ahead of its competitors in this space

I think of those listed projects only few are backed by for-profit entities (like sandstorm itself). Cozy in particular seems very well funded (https://www.crunchbase.com/organization/cozy-cloud#/entity).

I also think the alternatives link is a bit misleading because those projects aren't really direct alternatives. I have investigated a bit in this space (for my personal hosting):

* Cozy is simply for a personal server for email/contacts. This is more like ownCloud. It's not meant for hosting internet facing websites.

* Sandstorm is sort of trying to build a Google Docs style portal. People share these docs with each other. This is why it has a "frame" around every doc/app. It's also not meant for hosting internet facing websites (by this i mean, it is not optimized for hosting your personal public blog).

* Bitnami is 1-click images for opensource apps. I am guessing their main user base is people who want to install a stack quickly. It's a glorified docker pull or curl.

* Cloudron is about running apps on a server. This is automation (ssl, backup, install/update etc) of what you would be doing today, if you have to setup a server and install apps like rocket.chat, gitlab etc. Cloudron uses docker for the apps. Yunohost does the exact same thing without docker.

Re: The Sandstorm Team Is Joining Cloudflare

#53

Post by tracker1 »

diggan wrote: post #5

The people behind Sandstorm are joining Cloudflare and will now have less time to spend on Sandstorm. That's sad, because I was excited in general behind the idea of Sandstorm, and I hope it continues to be worked on, even if it's just during the weekend.

It definitely looks interesting.. may play with it on DO or Linode this weekend, if I remember to do so...

Re: The Sandstorm Team Is Joining Cloudflare

#54

Post by derefr »

educar wrote: post #52
derefr wrote: post #35

Earlier quoted context omitted.

AFAIK Sandstorm was way out ahead of its competitors in this space; it was the only one HN ever deigned to pay attention to, at least. Given that, and given that it's FOSS, then as long as the community is still interested in the project, the project should keep seeing development, regardless of the amount of time the original developers can put in. Even if that means a LibreOffice- or MariaDB-like fork.

> AFAIK Sandstorm was way out ahead of its competitors in this space I think of those listed projects only few are backed by for-profit entities (like sandstorm itself). Cozy in particular seems very well funded ( https://www.crunchbase.com/organization/cozy-cloud#/entity ). I also think the alternatives link is a bit misleading because those projects aren't really direct alternatives. I have investigated a bit in th…

> It's also not meant for hosting internet facing websites (by this i mean, it is not optimized for hosting your personal public blog).

It's an Intranet portal, essentially—like the one you get from setting up Apple's Server.app. But it could certainly be used to host an app that builds an Internet-facing website.

For example, you could launch an authenticated-users-only Wordpress instance on Sandstorm, to allow your team to collaboratively create a website. Then you'd install the Simply Static plugin in that Wordpress instance, and use it to shove a static-slug copy of the site out to a public web-enabled S3 bucket or wherever else you like.

In fact, there's probably a good nascent architecture involving Sandstorm + Minio + nginx where you use Sandstorm on the intranet-side, as a multi-product Content Management System for a public-facing site.

Re: The Sandstorm Team Is Joining Cloudflare

#55

Post by jgrahamc »

shawn-butler wrote: post #50
kentonv wrote: post #46

Earlier quoted context omitted.

Correct. The CF people are cool and have no problem with us continuing to operate Sandstorm, as long as we're getting our Cloudflare work done. Cap'n Proto will presumably end up with mixed copyright, but it's MIT license anyway so who cares?

I'm sure you have already but look over that employment contract carefully. CF being "cool" shouldn't put your project and its users (me!) at risk.

We've worked closely with Kenton on this. In fact, our lawyers wanted us to add language to ensure that it was clear that we don't own Kenton's IP around this.

Re: The Sandstorm Team Is Joining Cloudflare

#56

Post by StreamBright »

cstrahan wrote: post #48
kentonv wrote: post #9

Hi all, I'm not sure how responsive I'll be able to be on this thread since I'm in orientation today. :) But, here's the things I expect to be repeating a lot: - Sandstorm is still an independent company, under control of Jade and myself. - Sandstorm is "my baby" and I'm not going to stop working on it just because I have a day job. Yes, it will slow down a bit -- but on the bright side, we were previously spending t…

I'm pretty stoked about future cap'n proto developments. In the scenarios where I've brought up Cap'n Proto, all but the most senior/prolific developers have a near impossible time of ascertaining why one might want to use capnp over competing approaches (e.g. Protobuf). I think, despite a pretty decent description on the website and my own skills in explaining/teaching, such protocols are nearly impossible for the m…

Performance might be one reason to use Cap'n Proto over Protobuf.

http://dbeck.github.io/5-lessons-learnt-from-choosing-zeromq...

Re: The Sandstorm Team Is Joining Cloudflare

#57

Post by [deleted] »

cstrahan wrote: post #48
kentonv wrote: post #9

Hi all, I'm not sure how responsive I'll be able to be on this thread since I'm in orientation today. :) But, here's the things I expect to be repeating a lot: - Sandstorm is still an independent company, under control of Jade and myself. - Sandstorm is "my baby" and I'm not going to stop working on it just because I have a day job. Yes, it will slow down a bit -- but on the bright side, we were previously spending t…

I'm pretty stoked about future cap'n proto developments. In the scenarios where I've brought up Cap'n Proto, all but the most senior/prolific developers have a near impossible time of ascertaining why one might want to use capnp over competing approaches (e.g. Protobuf). I think, despite a pretty decent description on the website and my own skills in explaining/teaching, such protocols are nearly impossible for the m…

[deleted]

Re: The Sandstorm Team Is Joining Cloudflare

#58

Post by hueving »

cstrahan wrote: post #48
kentonv wrote: post #9

Hi all, I'm not sure how responsive I'll be able to be on this thread since I'm in orientation today. :) But, here's the things I expect to be repeating a lot: - Sandstorm is still an independent company, under control of Jade and myself. - Sandstorm is "my baby" and I'm not going to stop working on it just because I have a day job. Yes, it will slow down a bit -- but on the bright side, we were previously spending t…

I'm pretty stoked about future cap'n proto developments. In the scenarios where I've brought up Cap'n Proto, all but the most senior/prolific developers have a near impossible time of ascertaining why one might want to use capnp over competing approaches (e.g. Protobuf). I think, despite a pretty decent description on the website and my own skills in explaining/teaching, such protocols are nearly impossible for the m…

Can you provide a 'top 3' list of reasons to use Cap'n Proto over Protobufs?

Re: The Sandstorm Team Is Joining Cloudflare

#59

Post by xxdesmus »

ryanlol wrote: post #42
kentonv wrote: post #27

Earlier quoted context omitted.

FWIW I blogged more about it a couple weeks ago (editorial at the bottom): https://sandstorm.io/news/2017-02-28-cloudbleed

Your blog post doesn't seem to discuss their response very much. What leads you to believe that CloudFlare was impressively fast and transparent in this case? Especially since statements from Project Zero seem to imply that they were anything but.

"statements from Project Zero" -- nope, statement from one person. Also you're assuming those are facts.

Re: The Sandstorm Team Is Joining Cloudflare

#60

Post by doh »

hueving wrote: post #58
cstrahan wrote: post #48

Earlier quoted context omitted.

I'm pretty stoked about future cap'n proto developments. In the scenarios where I've brought up Cap'n Proto, all but the most senior/prolific developers have a near impossible time of ascertaining why one might want to use capnp over competing approaches (e.g. Protobuf). I think, despite a pretty decent description on the website and my own skills in explaining/teaching, such protocols are nearly impossible for the m…

Can you provide a 'top 3' list of reasons to use Cap'n Proto over Protobufs?

1) Cap'n Proto doesn't encode/decode messages thus it's nuch cheaper for processing and memory management

2) protobuf in the proto3 design doesn't cary default values. So if you have a bool field and want to explicitly send false, well you have to change it to some other type or use the default values all the time

3) protobuf generates incredibly large serialization/deserialization support coce for each template. For some languages like Python in can be in hundreds of kilobytes. Cap'n proto messages are significantly smaller

There is more for CnP but Protobuf has much better support and is by default used in projects like gRPC. Also new CnP is lacking speed in new development in comparison to Protobuf.

But I'm using in one of my side projects and I'm very happy with it

Post reply on HN