Ah i know there’s people who used bash script too 
Does that work across linux platforms? I usually install Wheezy which is a Debian
Bash is basically the de facto shell nowadays. Even FreeBSD and Mac OS X switched away from tcsh to Bash.
If you want to be safe you can use only sh standard commands as pretty much all shell interpreters will be compatible. If you go that route just shebang sh instead of Bash [#!/bin/sh] as that should either make the script execute in sh itself or—in the case of Bash—start it in sh compatibility mode:
timbmba:~ timb$ sh --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.
timbmba:~ timb$ sh
sh-3.2$ exit
exit
timbmba:~ timb$ bash --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.
timbmba:~ timb$ bash
bash-3.2$ exit
exit
timbmba:~ timb$
At the very least pretty much all off the shelf distros at least include Bash these days, so if it were me, I’d just stick with that (be sure to start your script off with #!/bin/bash). Remember, the user can always install Bash if they don’t have it (every package manager includes it and it’s easy to compile).
I spent 10 years writing Bash scripts, so I can throw together a skeleton example for you that will get you started, if you want! 
1 Like
Hey @timb,
I think the plan is to release a local Sparkulator as well down the road, as a GUI compliment to the CLI, but I’m not exactly sure what the timing of that is just yet.
Thanks!
David
That’s like the best offer ever!
Should I manually attempt to install 1st before making a bash script?
Or gather the commands to run, make it and run? 
@Dave I have some questions with regards to this matter:
-
This code soon-to-be-release is referring to a Local Spark IDE where we can flash our core via it?
-
Will the API server app be out as well. (sounds like a yes since the IDE depends on it to flash a new firmware, no?)
-
Can the API servers be scaled in future or how is it like for the Spark API server so far?
I’m getting excited over this cos i asked some stuff about this few months back and now that it’s getting nearer, i can’t help but to prepare for it!
Hey @kennethlimcp,
I have some answers
1.) You could flash your cores with a local build, or with the CLI
2.) I think the local cloud will be at the least a device service and api service in one, so it should have most API features of the one online, so your apps can easily switch between the two.
3.) I’m not sure about if / what local cloud scaling and commercial licensing would look like, this is more of a Spark business question. Part of the delay on the local cloud is that we want to give a balance of power and ease of use. There is a lot going on when you want to run a large service like this, managing multiple machines, load balancing, pagerduty alerts and monitoring, automatic updates, continuous integration / deployment, to name a few.
Thanks!
David
1 Like
Is there way to disable remote flashing the spark core? Is the spark core hardware fast enough to handle encryption, such as https request? Is the encryption hardware or software base.
-
The
core is definitely fast enough to handle encryption @ 72Mhz. -
Encryption is done on software on the STM32 microprocessor itself and not by an external security chip
-
Disable remote flashing… I guess you can do it by modifying the firmware somehow… Or maybe even the bootloader since OTA update is a out-of-the-box feature
Encryption is managed by the core so well that we don’t have to worry about it as an end-user. Like it’s well said…it just works!
Hi @sink88,
The overhead for something like TLS or HTTPS encryption is really high, so we have a special encryption solution that handles traffic from the core to the cloud. Each core has a unique 1024bit public/private keypair that’s only ever stored on the core, and a certificate for the server. These keys and a secure nonce are used to negotiate a signed session key for a 128-AES-CBC session with the core that is rotated bidirectionally after every message.
Because doing ‘normal’ https requests are so resource intensive, we were thinking about letting the core act as a proxy in those situations, or you could use a webhook to trigger secure web requests. Those features are still a few sprints away though.
If you wanted to disable remote flashing or anything, you can definitely setup a local build and change any firmware or disable any features you want: https://github.com/spark/core-firmware
all the communications stuff is here: https://github.com/spark/core-communication-lib
Thanks!
David
Hi @Dave,
any updates on this subject?
Also, if not tool late, please sign me up for beta testing too.
Thanks,
/N
1 Like
Hey @NaAl,
I’m sorry to say no updates yet, my last sprint was dedicated to the next manufacturing run. Consider yourself included in the beta!
Thanks,
David
I would like to be in the beta as well please.
1 Like
@Dave, thanks for the reply. What is
@Dave, why not just release the code base? No need to make everything perfect, that’s one of the point of Open Source? Software by crowd sourcing. And I like the lean approach, give the bare minimal to users, and add missing features incrementally. Release the beast, let the world help make it better.
I just got node.js and npm-gyp installed on my acer aspire one [ubuntu 14.04], which run on a 30W power supply. I think it is more efficient than the pi. Because I can also run google drive and bug tracker on the same box.
1 Like
Just notice my icon is a red dot, and I am talking to Dave. Maybe I should change my user tag to HAL.
1 Like
This just came out minutes ago!
I can’t imagine running my API server on these cool little blades in future
Interested parties, let’s work together and design a main board which can connect a couple of these blade computing modules up!!!
2 Likes
Heya @sink88,
Sorry about the delay in responding, I’ve been airborne a lot the past few days
The “rotated bidirectionally” description refers to keeping separate tx/rx initialization vectors for the aes session between the core and server, and that each IV (tx and rx) is rotated independently from the other after sending / receiving messages.
I really want the local cloud out there too, I’m sorry about the delay, if I can wrap up manufacturing prep this sprint, then I can get things moving hopefully next sprint. :\
Thanks!
David
Any updates on releasing the local cloud source?
Also, I’d love to be included in the beta, if not too late. Will you add me to the list?
Thanks!
@Dave, if still adding to the list of Beta Testers I would like to be included. Thanks.
1 Like