Err, that should read: Particularly non standard Debian. Debian is fine( great ), until people start screwing around it . . .
william@beaglebone:~/node$ wget http://nodejs.org/dist/v4.2.6/node-v4.2.6.tar.gz
william@beaglebone:~/node$ tar xzvf node-v4.2.6.tar.gz
william@beaglebone:~/node$ cd node-v4.2.6
william@beaglebone:~/node/node-v4.2.6$ ./configure --without-snapshot
william@beaglebone:~/node/node-v4.2.6$ make
william@beaglebone:~/node/node-v4.2.6$ ./node -e ‘console.log(“Testing . . .”);’
Testing . . .
william@beaglebone:~/node/node-v4.2.6$ ./node -v
v4.2.6
william@beaglebone:~/node/node-v4.2.6$ uname -a
Linux beaglebone 4.4.8-ti-r22 #1 SMP Wed Apr 27 22:23:10 UTC 2016 armv7l GNU/Linux
Arrrr . . . depends . . .
$ sudo apt-get install build-essential automake autoconf libtool pkg-config libcurl4-openssl-dev intltool libxml2-dev libgtk2.0-dev libnotify-dev libglib2.0-dev libevent-dev libssl-dev checkinstall python wget
Is gtk required? What if I'm just making a server with no display?
No Rick gtk is not required. Most of these dependencies came directly off the Nodejs github readme.md
for Nodejs v0.10.35, and I have not changed these dependencies in my notes since ( around 2 years ago or whatever ).
Anyway, if you look at the list of actual packages required by my small list here, and you start seeing all kinds of garbage like xwindows stuff, etc. You realize that package maintainers are either delinquent in maintaining a proper dependency list, OR these maintainers actually use these libraries because they already know them.
Anyway, this was compiled on a console image that started out at just under 200M in size. ssh . . .
william@beaglebone:~$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p1 1.7G 1004M 536M 66% /
Thats also why I recommend to anyone who will listen. That they should create two different beaglebone images when developing.
- One production image with only te bare minimum installed for the given project.
- One development image with all the necessary dev packages installed. Like this one here that bloated from less than 200M to 1004M . . .
Two main reasons.
Why would you want to boat a production system needlessly. It can impact performance.
- It’s a potential added security risk. As the more you have installed, the more that is potentially exploitable. Merely a potential concern, and not necessarily fact.
I’ll argue the opposite unless you have enough customer volume to have a technical support department behind you.
For most of my working career my product was generally a custom system for a specific purpose and six instances would be a raging success, but the systems were located on all three coasts. Having the development and deployment images be the same has definite advantages when trying to troubleshoot/repair issues via a phone call to the users, and prevents “missing pieces” if rushing out to the remote site – not quite so big an issue now that about everything is available via Google & github, but most of these systems were on an isolated network for security.
I only worry about image size if it forces the next cost increment in capacity, but in these days or $10-20 32GB uSD cards its not worth much of my time to worry about keeping it small. If you need to stay in the eMMC then its important, but in the short life of the Beaglebone Black its already doubled once and likely will again at the next major revision.
I’ll argue the opposite unless you have enough customer volume to have a technical support department behind you.
For most of my working career my product was generally a custom system for a specific purpose and six instances would be a raging success, but the systems were located on all three coasts. Having the development and deployment images be the same has definite advantages when trying to troubleshoot/repair issues via a phone call to the users, and prevents “missing pieces” if rushing out to the remote site – not quite so big an issue now that about everything is available via Google & github, but most of these systems were on an isolated network for security.
I only worry about image size if it forces the next cost increment in capacity, but in these days or $10-20 32GB uSD cards its not worth much of my time to worry about keeping it small. If you need to stay in the eMMC then its important, but in the short life of the Beaglebone Black its already doubled once and likely will again at the next major revision.
This is why I’d have a “test jig” to duplicate exactly what’s going on. If you control the hardware, and software. You should not need a large technical support group to figure the problem out. Then when you find the problem locally, you test locally on an exact production system by installing an apt package, if needed for the situation.
now fixed:
sudo apt-get update ; sudo apt-get install bb-cape-overlays
Regards,
now fixed:
sudo apt-get update ; sudo apt-get install bb-cape-overlays
Regards,
–
Robert Nelson
https://rcn-ee.com/
Thanks Robert, but it was not my intention to create more work for you . . . after all the bb.org-overlay git is there and is pretty self explanatory. Simply having a /lib/firmware directory on the image would have eliminated my questions all together 
Handy, thanks!
Robert,
Do you have any tips to help this console image boot up faster ? Keep in mind I’m running sysv . . .