For many years now, the OU has required students to have access to a computer in order to access online course materials and run course related software. A minimum specification computer is specified (2GB of RAM) and is supposedly platform neutral.
Putting together the headless TM351VM, which uses a virtual machine running on a host O/S, we needed to conform to this minimum spec; the VM we ended up with requires 1GB of RAM and takes up about 12-15GB of space (with gubbins), though it only needs at most about 8 GB of that.
In the previous post, I described how I recently got a Raspberry Pi Up and Running for the first time. And it got me thinking (again) about how we deliver software applications to students with the minimum of setup requirements.
1GB RAM…. 8-16 GB free space…
About the spec for a Raspberry Pi 3 with a cheap memory card?
So imagine this – students joining the university are given a Raspberry Pi 3 in a nicely branded box, along with an ethernet cable to attach it to their computer directly or to a wifi router; course software is designed to run as a service accessed via a browser, and to meet the Raspberry Pi 3 spec (which is on a par with what’s left over from a current min spec machine once its own O/S and background services have been taken into account).
The software for a particular course is issued on a course specific micro-SD card, supplied in a larger, OU and course branded SD card holder.
The micro-SD card contains a “course image” containing headless services that autorun on startup; the device is named with a suitably discoverable name – OU.local; a simple web server is found on the default http port and lists local URLs to locally running services on the PI and perhaps also links to the VLE and other online course resources. (This reminds me of the first browser based course materials I had a hand in in 1999 or so – an eSG – electronic study guide – that delivered locally installed HTML interactive content and linked applications, as well as links to online materials resources – for a mainly for print course (T396).)
The student plugs the course micro-SD card into the Pi, connects the pi to their computer or router via ethernet, switches the Pi on (i.e. plugs the power cable in) and goes to OU.local in their browser. Job done? [UPDATE: on a Mac, this is easy; in Windows… I’m not so sure? Bah…:-( Alternative is to plug pi into wifi router and then get student to try to find it’s IP address eg https://www.raspberrypi.org/documentation/remote-access/ip-address.md Or can a particular name alias (ou.local?) be requested from a wifi router (though that doesn’t feel very secure to me!)? Or we ship a tiny display such as the display-o-tron hat with Raspberry Pi that displays the IP address it’s allocated? That adds to the expense, but if it’s part of the packaging, that maybe offsets part of the case cost? UPDATE: or how about this – get the Raspberry Pi to speak it’s IP address [just in case…].]
To improve robustness, the micro-SD card image could also run a process monitor to check necessary services were always running, and perhaps a control panel to allow students to monitor/start/stop/restart services if and as required.
To persist student created files, a named course USB stick plugged into the Pi and mounted at a known location would allow portability of files.
For each new course, with its own software, we just mail out a new micro-SD card with a course Pi image on it.
For the research student who possibly needs to run some slightly heavier weight applications that the Pi still has the computational oomph to run, we ship them cards that just run the application or application suites they need on starting up the Pi.
I know this idea has been mooted several times by various folk in the OU before (my recent tinkering was prompted by TM351 course colleagues Neil Smith and Alistair Willis that we could try a Pi as an alternative offering for TM351 students struggling to get the course software installed), but having had a bit of a play recently, it feels pretty tractable…