Category: Ubuntu

may raspberry pi

whbeebe

My work with the Raspberry Pi has slowed of late, due in no small part to a lot of travel so far this year. When I got back this weekend, powered up the Raspberry and updated Arch Linux ARM to the latest packages, as least as of Saturday 3 May. I then went through my usual of cleaning up the file system and creating a compressed image. It was at the end of that process I discovered my biggest problem to date: the size of the compressed ZIP file. It had grown over 500MB to roughly 1.5GB compressed.

I tried to upload it to Sourceforge, only to find out they had a 1GB file size limit. So I pushed it out to the only place I have that would accept it, Goggle Drive. Please note that the older images have been deleted from Sourceforge, and for all intents and purposes, I’m done with using Sourceforge. From now on I’ll use Google Drive to hold publicly accessible compressed images, and Github to hold any source.

Furthermore, the link to Sourceforge on the main menu has been replaced with a link to my Raspberry Pi category. Simply click on it to read everything I’ve published on the subject, including posts like this one. It will help you quickly find what I’ve been doing as well as links to resources.

Here is the link to the compressed image zip file:

Link https://drive.google.com/file/d/0B3akRjoJF444SXA5dEJUeWJTdWc/edit?usp=sharing

I did download the file and found it took me, on my Brighthouse Networks connection, approximately 45 minutes.

And here is the link to the README.TXT file:

Link https://drive.google.com/file/d/0B3akRjoJF444cE9SV2R5R1ZvNGM/edit?usp=sharing

I’m going to repeat a good bit of the README, with additional comments.

Release Notes for my personal El Cinco de Mayo RPi Arch Linux Arm release

  1. The primary reason for this release is to fix Heartbleed in the OpenSSL libraries.
  2. The secondary reason is to remove unneeded applications, clean up work areas, and reduce as much as possible overall disk image usage.

The TWM-based X Windowing Arch Linux Raspberry Pi image has been updated

ArchLinuxARM-2014.05.05-rpi-twm08G.zip, located on my Google Drive location, contains ArchLinuxARM-2014.05.05-rpi-twm08G.img, a 7,948,206,080 byte file that can be flashed to an 8GB or larger SDHC or micro SDHC card. To use this image unzip and then copy the resultant 8GB file to your target SDHC or equivalent card.

This image has the TWM X window manager installed with custom configurations. All TWM related files are located in the subdirectory twm and its related subdirectories.

All Arch Linux ARM packages are updated as of 3 May 2014. NOTE: This includes updated ssl libraries to fix Heartbleed bug/exploit.

Note for future reference: My Raspberry Pi support system is a Samsung R580 with Ubuntu 14.04 LTS installed.

Node.js and Web Applications on the Raspberry Pi

Node.js is still installed, and updated from the Arch Linux Arm repositories.

Local node.js work directories have been cleaned out, leaving only two:

  • express.jade (for web framework work)
  • node_modules (for GPIO and I2C work)

To start the example node.js and Express web app:

  1. cd into express.jade
  2. type node app.js

You do not need to be root to run app.js. The web app listens on port 8080.

Security

Security has been scaled back with this image.

  • the firewall is now inactive

I determined that my ruleset for the firewall (iptables) was incorrect. This resulted in less than ideal remote access. Furthermore, it was determined that iptables.service (see systemctl) had an adverse impact on performance. Therefore the iptables.service has been disabled and the link in /etc/iptables has been removed. If you wish to enable this on your own the various iptables files are still on the image for you to work with. Good luck.

  • root login via ssh is still blocked, however.
  • sudo pi now requires a password again.

Other Applications

Java 8, which was installed local to pi, has been removed, along with all Java tools, such as ant. It will not be re-installed.

Future application development will be via Javascript (node.js), Python (2.7.6 and 3.4.0 or later), and gcc (8.4.2). These, along with bash scripting, give you four different ways to develop. Adding Java 8 to the mix provided no real benefit to such a small machine, and proved to be a major resource consumer that the Raspberry Pi did not need to support. The four current languages also have the advantage of being supported out of the Arch Linux Arm repositories; Java 8 was downloaded direct from Oracle.

pacman

The pacman cache (/var/cache/pacman) has been cleaned up with pacman -Sc. This has removed all unnecessary package references, reducing pacman’s cache disk footprint by more than half (over 400MB).

Python

RPi.GPIO has been updated to 0.5.5. It is built and deployed in this image.

Note that ~/RPi.GPIO-0.5.5/test/test.py will not work as-is with Python 3.4.0. The print statement in that version of Python is a fully qualified function (see PEP 3105) and is fully enforced. I  have included a patch in these release notes that you can cut and pasted into an individual patch file and apply to test.py.

Note to everyone: The fix is already in the test directory as test34.py, for Python 3.4.0. Even the patch is there as patch.txt. I bring this up in case you want to apply it to another installation on another distribution.

--- test.py 2014-04-21 08:45:14.000000000 -0400+++ test34.py 2014-05-03 00:54:50.910000000 -0400@@ -123,13 +123,13 @@ GPIO.setup(LED_PIN, GPIO.OUT) pwm = GPIO.PWM(LED_PIN, 50) pwm.start(100)-print "\nPWM tests"+print("\nPWM tests") response = raw_input('Is the LED on (y/n) ? ').upper() self.assertEqual(response,'Y') pwm.start(0) response = raw_input('Is the LED off (y/n) ? ').upper() self.assertEqual(response,'Y')-print "LED Brighten/fade test..."+print("LED Brighten/fade test...") for i in range(0,3): for x in range(0,101,5): pwm.ChangeDutyCycle(x)@@ -224,14 +224,14 @@ def cb(self,chan): self.switchcount += 1-print 'Button press',self.switchcount+print('Button press',self.switchcount) def setUp(self): GPIO.setup(SWITCH_PIN, GPIO.IN, pull_up_down=GPIO.PUD_UP) def test_switchbounce(self): self.switchcount = 0-print "\nSwitch bounce test.  Press switch at least 10 times and count..."+print("\nSwitch bounce test.  Press switch at least 10 times and count...") GPIO.add_event_detect(SWITCH_PIN, GPIO.FALLING, callback=self.cb, bouncetime=200) while self.switchcount < 10: time.sleep(1)@@ -239,12 +239,12 @@ def test_event_detected(self): self.switchcount = 0-print "\nGPIO.event_detected() switch bounce test.  Press switch at least 10 times and count..."+print("\nGPIO.event_detected() switch bounce test.  Press switch at least 10 times and count...") GPIO.add_event_detect(SWITCH_PIN, GPIO.FALLING, bouncetime=200) while self.switchcount < 10: if GPIO.event_detected(SWITCH_PIN): self.switchcount += 1-print 'Button press',self.switchcount+print('Button press',self.switchcount) GPIO.remove_event_detect(SWITCH_PIN) def tearDown(self):

Accounts:
Console only: root, password: root
Console and ssh: pi, password: pi

As pi, to start the TWM X Windowing desktop, type startx at the prompt.

teaching an old dog updated languages

whbeebe

For reasons I won’t get into just yet, I’ve been looking at cleaning up my moldering Python skills. It’s been years since I coded anything of significance in Python, and “back in the day” I did it because I had few other options, one of them being Perl. I refuse to write anything in Perl anymore, even though I started my long journey into interpreted languages with the pink Perl book published in 1991.

In the early days I fell upon Perl like a man dying of thirst falls upon an oasis in a desert. In my case, the desert was a mix of bourne and AWK scripting (and I came away positively loathing TCL). With Perl 4 I could build highly sophisticated tooling completely in Perl, and just use my shell scripts to launch my more sophisticated Perl scripts. I started with Perl sometime around 1993 and kept using it until 2000 when I upgraded to Perl 5. With Perl 5, Perl fell out of favor with me, and Python began to rise in its place. I found that Python, in spite of its FORTRAN-like use of spaces to determine scope, was close to C++ and Java than Perl. I found it easier to user Python, both as wrapper for Java and C++ applications as well as being a powerful development language in its own right.

But time moved on and the reasons for using Python fell away. I stuck with C++ and Java, with occasional forays into JavaScript.

And then, for reasons as I said I won’t go into just yet, I had a need to brush up on my Python skills. Except this time, rather than staying in Python 2, I decided to jump whole sale into Python 3, or 3.4.0. I grabbed a copy of the source tarball off the Python website, unpacked it in my Ubuntu 14.04 VM, built it with the configure/make/make install kabuki dance, and started to work with it.

To refresh my skills I started with simple apps, to get a feel for the basics in Python 3. I quickly put together a factorial application, the source and output of which follows:

#!/usr/bin/env python3import sysdef fact(n):a = 1print( n, end="! = ")while n > 0:a, n = a * n, n - 1print(a)if __name__ == '__main__':if len(sys.argv) <= 1:print("Factorial calculator. Must call with at least one number as argument.")sys.exit()for i in range(1, len(sys.argv)):fact(int(sys.argv[i]))

There’s not much to say about this application. It has one function (fact()). It can test for command line arguments and print out a message with no arguments. It has a tight, simple iteration in main to walk through any and all arguments. The output shows that Python can easily handle arbitrarily large numbers without invoking special features. That alone is one reason it’s used in scientific computing.

While I don’t like how spacing is used to delineate scope, it does remove the need for curly braces used in other languages such as C++, Java, and Ruby, to name but three. What follows is the same application, this time written in Java 8.

import java.math.BigInteger;public class Fact {public static void fact(String num) {System.out.print(num + "! = ");BigInteger a = new BigInteger("1");BigInteger n = new BigInteger(num);while (n.compareTo(BigInteger.ZERO) > 0) {a = a.multiply(n);n = n.subtract(BigInteger.ONE);}System.out.println(a.toString());}public static void main (String[] args) {if (args.length < 1) {System.out.println("Factorial calculator. Must call with at least one number as argument.");System.exit(1);}for (String number : args) {fact(number);}}}

The syntax is radically different between the two, which is to be expected. Of significant difference is the use of java.math.BigInteger to match Python’s ability to use numbers of arbitrary size and precision. When I first wrote this I used regular integers (int) and could only calculate factorial 11 (11!) before the integer product became negative (sign overflow) and then went to zero. Using BigInteger solved that problem, but introduced a far more complex coding method. While the Java application is only six lines longer, its fact() function is a lot more complex than the fact() function in the Python example. Whereas the Python code can handle the numbers with the same old syntax, special functions within the BigInteger class have to be used to perform basic math (multiplication and subtraction) and the while loop comparison is a somewhat obscure big class function in Java, while with Python its the straightforward comparison we’ve all come to know and love.

In this specific example, the Python code wipes the floor with the Java code, or at least it does for me. There’s a certain sparse (dare I say beautiful?) elegance with the Python code not needing all the matching curly braces that Java requires (and C++, too, for that matter). From a purely coding standpoint, and with this very very narrow example, I find I prefer writing in Python. Maybe larger, more complex coding projects will continue to favor Python over Java, and then again, maybe not. While I want to continue working this kind of duality and comparison, it’s going to reach a point where I’ll need to make a decision when to use which, and stick to it.

I’m surprised, however, how much I like coding in Python. Have I reached a point in my coding life where I should do the majority of my work in Python, moving on from C++ and Java? Maybe even from JavaScript as well.