Re: [PLUG] Spark Core (corrected)

(sorry for the double post- I sent the wrong version out)

The whole "cloud" thing irks me. I get that most people don't have the resources or skills to run their own servers but for me, I'm always concerned with the obsession of public hosted solutions vs. non-hosted or private hosted. Let's also not forget security and privacy concerns (something that to this day is often not taken seriously). Personally I think many organizations are trying to mimic Google in the sense that, in 5 years, they want to be able to leverage user statistics (i.e. your data... even in the abstract or anonymously). I don't necessarily have a problem with that in the FOSS world- just be honest about it and let me opt-in.

One of the other projects I came across today was Pinoccio which is a similar project but has the additional ability of being able to integrate XBee (802.15.4) clients into the mix. This allows you to build an ultra-low powered mesh sensor network and then only use one of the nodes as your internet bridge. The developers there stressed that even though they have a web-based IDE (similar to SparkOS), you don't have to use it and you can develop without the whole cloud paradigm. That's the way forward for the whole IoT / Marker space. Give people the choice.

Both are still some good awesome sauce.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Keith C. Perry, MS E.E.

Owner, DAO Technologies LLC

(O) +1.215.525.4165 x2033

(M) +1.215.432.5167

www.daotechnologies.com

From: "Keith C. Perry" <kperry@daotechnologies.com>
To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org>
Sent: Friday, October 24, 2014 5:19:33 PM
Subject: Re: [PLUG] Spark Core

The whole "cloud" thing irks me. I get that most people don't have the resources or skills to run their own servers but for me, I'm always concerned with the obsession with public hosted solutions vs. non-hosted or private hosted. Let's also not forget security and privacy concerns (something that to this day is often not take seriously). Personally I think many organizations are trying mimic Google in that sense that in 5 years they want to be able to leverage user statistics (i.e. your data... even in the abstract or anonymously). I don't necessarily have a problem with that in the FOSS world- just be honestly about it and let me opt-in.

One of the other projects I came across today was Pinoccio which is a similar project but has the additional ability of being able to integrate XBee (802.15.4) clients into the mix so you can build a ultra-low powered mesh sensor network and then only use one of the node as your internet bridge. The developers there stressed that even though they have and web-based IDE (similar to SparkOS), you don't have to use it and in fact you can develop without the whole cloud paradigm. That's the way forward for the whole IoT / Marker space. Give people the choice.

Both are still some good awesome sauce.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Keith C. Perry, MS E.E.

Owner, DAO Technologies LLC

(O) +1.215.525.4165 x2033

(M) +1.215.432.5167

www.daotechnologies.com

From: "David Morfin" <david@morfin.name>
To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org>
Sent: Friday, October 24, 2014 2:26:28 PM
Subject: Re: [PLUG] Spark Core

On Fri, Oct 24, 2014 at 1:44 PM, Rich Freeman <r-plug@thefreemanclan.net> wrote:

On Fri, Oct 24, 2014 at 10:51 AM, Keith C. Perry
<kperry@daotechnologies.com> wrote:
> The big claim to fame for this devices is that it is already
> **shudder** "cloud connected". So out of the box, you can control things
> over the internet.

Interesting. I wonder how easy it is to:
1. Use their cloud utilities to develop/build/deploy code, but make
the code itself self-contained on the device so there is no impact if
it goes down (or just minor impact, like the clock can't set its own
time and so on).

It depends on what you mean. The way their API is implemented, to send commands TO the device, you send commands to spark.io/api/something (I don't remember off hand) and then the next time the device polls them for updates it gets the information (otherwise it wouldn't work behind NAT). The device itself doesn't go down anyway, and will happily run without internet indefinitely, but you won't be able to hit the API or deploy code. That said, I've been able to successfully send commands to my own

2. Run "cloud-based," but using your own server, which could possibly
be another box on the same subnet.

I like the idea, but I don't think it would be trivial to support as-is... they say everything is open source, but I don't recall seeing any way to set it up to hit your own implementation. Maybe I just missed that, but it would definitely be a nice feature if you're making a product and don't want to rely on a third party.

I also have a device from linino.org, which is a bit bigger (maybe twice as big) and a bit more expensive ($60?), but gives you full access to the ARM side (running linux) that is controlling the wifi. So with that device you have a huge amount more flexibility on what you can do. In that case, there is no easily exposed API system that you can hit from anywhere though, so you need to figure out how to talk to the device on your own. Also the setup for the sparkcore requires just an easy to use app on a smart phone (or connect serially over USB), while the linino requires that you reconfigure your wireless to talk to its default network, then reconfigure it there (or connect serially over USB).

I'd also point out that I'm seeing crashes from both devices with disturbing frequency. I think there is something leaking in the TCP code on the sparkcore (maybe not an issue if you're using API access instead of making direct outbound TCP sockets), and on the linino it seems like the linux side just randomly kernel panics and/or halts. I haven't had a chance to track it down yet, but when connected serially it seems like sometimes it drops the network connection and tries to re-establish, and something in that process is causing it to panic.

___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug