One barrier to community archiving smashed
|February 18, 2015||Posted by Stevan under Consultancy, Technical Comment||
January 2015 saw a major update to the tiny little raspberry Pi single board computer, which I have previously written about here. The Pi now has four times the number of “cores” on the same chip, and four times the amount of memory of the original, and is roughly six times as powerful. Yet it is the same astonishing price, just £25.
This puts the Pi well into the frame for establishing a community digital archive running Free and Open Source archiving software, with some caveats. Certainly, for a community concerned about the practicalities of establishing a digital archive, the initial hardware cost can now be contained to the cost of a pub meal. What is more, the power required to run a Pi (or several of them) is extremely low, around 2.5w by my tests, which is roughly what an electronic item on standby consumes. This makes ongoing electricity costs a rounding error rather than a major cost factor. Finally, the small size of the Pi makes tucking a community archive into a corner of a community building simple.
The biggest two caveats regarding running a community digital archive on a Pi are data security and multimedia processing, and these two issues need to be understood and the issues worked around.
Regarding data security, the biggest issue is that the Pi uses a small SD or micro-SD card, cheap, solid state storage, but with the drawback of the cards having a limited life, occasionally being slow, and with limited capacity. These issues can be worked around by taking regular backups, holding multiple SD cards on site, in case of failure, and by using a USB-connected conventional disk for the data. One would never use something like a Pi where absolute and constant data reliability was required, but in an archiving context, processes can be developed to make this issue by no means a show stopper.
While the new Pi is much more powerful than its predecessor, it remains a relatively underpowered device by modern standards. When used purely in the archiving context, this is of no great concern, but if the “server” is also used to manipulate multimedia files, a process which is usually processor-intensive, one would not be playing to the strength of the Pi. Having said that, the Pi as a multimedia playback device is quite amazing in its capability, and there is a real case for using them in interpretation and display contexts.
It is also a brilliant platform for prototyping, and for developing transportable archiving. It is possible to imagine a requirement where on-site archiving capabilities were required. The Pi makes this very easy.
Does this removal of a barrier interest your archiving requirement?