Hey I’m a Linux beginner and I just wanted add something I had trouble with in the hopes that I can spare someone a headache. I was having trouble adding arm-none-eabi-gcc to my$PATH variable. Turns out I needed to add the following line to my ~/.bash_rc instead of ~/.bash_profile as instructed above to save the path permanently:
I think we need a new place to find this source, this is asking for a username and password
This whole thing is already quite the bundle of steps never mind signing up for new version control services
... I'll look around
I ended up just downloading the dfu-utls zip from sorceforge, and compiling from that.
Unfortunately all in vain, flashed the latest build of the firmware, but no dice on my network,
I have no router access where I’m at right now, only wireless AP access,
port or protocol the spark is using is probably blocked, just like everything else here…
works with my phone hotspot… but that doesn’t help me make my own lockatron.
Anyhow on to the next project.
Just a note though: an hour plus to set up the particle-cli is a bit excessive, most folks would give-up, maybe 5 steps in.
I second the motion for not needing the second repo, my running instance of node worked, unless the repo is
for other things?
Might want to make a shell script for this whole thing and just wait for folks to report back when it enviably stops working two months later.
also - git clone git://**** has never worked for me, the https links always work. (when the repo still exist)
Thanks for the detailed instructions! I appreciate it
As TJ has pointed out - there might (to say the least ) be vulnerabilities in that script that could be exploited by not-so-well-meaning beings.
So everybody is free to use that script, but please handle with care - it’s a question of convenience vs. security
Anyone who manages to compromise your server and replace your downloadable shell scripts (which are getting piped straight into bash) with malware would be the not-so-well-meaning beings.
A) The complexities of finding and building the correct arm sources yourself, and verifying all the code and installing it as root
B) Installing private PPA’s which allow full access to your server and all your packages, even when signed
C) Using Node with NPM, where anyone can post malicious packages and where they are also installed with sudo nine times out of ten
D) Or, as you recommend in this article, just blindly downloading a GCC toolchain and installing it as root.
I’d say there has to be a balance between furthering a new technology and easing it’s adoption, and dealing with security. And while I agree that this form of shell script manipulation CAN be dangerous, so are all those other options.
In the meantime the po-util script can be pulled down from github, actually read through, and installed manually.
Githubs servers are going to be much more secure. The default installation instructions should be to download directly from github for anyone that wants to use poutil. Otherwise existing package managers are much more preferred as they do the work to make sure packages aren’t interfered with and can blacklist bad packages. There is a level of trust that comes from running any software if you don’t read the source yourself. Mitigating the risks using a proper distribution method is the next best thing for those that don’t have the time to review everything.
/usr/lib/node_modules/npm/node_modules/npm-package-arg/npa.js:6
let url
^^^
SyntaxError: Unexpected strict mode reserved word
at Module._compile (module.js:439:25)
at Object.Module._extensions…js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object. (/usr/lib/node_modules/npm/node_modules/npm-registry-client/lib/access.js:5:11)
at Module._compile (module.js:456:26)
at Object.Module._extensions…js (module.js:474:10)
at Module.load (module.js:356:32)