The Limits of Pi

Preface - I Heart Pi

I love my Rasperry Pi. It is completely awesome for the price. The power consumption is absurdly low. It is paying for itself keeping my Heroku apps up, already. It’s set up for coding, completely, as a backup to my mac. Soon it will be serving another site.

But it Can’t Browse The Internet

What it isn’t, however, is a machine that can browse the internet. It completely fails at running browsers. Ok, it has a browser and if you open it, it will load But try using that search window and clicking on some links… good luck!

I’m not saying I need to watch Netflix–like some Pi users are doing. Getting that set up on Ubuntu 12.4 was enough of a headache although pipelight eventually got a lot easier to use. No, even regular websites can crash and hang on the Pi. And that is just pretty unfortunate on a machine designed to teach people how to code – how is one supposed to get going started without access to Stack and video tutorials?

Why Doesn’t it Work?

Good question, Dear Reader. It has a few things to do with software bugs in the primitive built-in browser and it’s lack of flash support. But that problem is not solved with other software, as seems apparent in the way both icefox/chromium’s tendency throw errors and crash soon after loading up–even without any extra flash support packages installed, or video viewing attempted.

It is also a hardware problem, in no small part. Low ram combined with lack of SD card space for virtual memory is simply a losing combination for any system. Worse, low free memory for read-writes will limit the SD card lifespan, because SD cards have a limited number of read/write functions before they physically lock up (~10,000), and these be concentrated over the limited available free space.

So it is even actually possible that the absence of browser functionality in the Pi is practical and intentional; the excessive amount of read/writing involved in heavy browsing would brick a low-memory system fairly qucikly. Indeed, I have read quite a few are horror stories of users bricking high use Pi devices, like servers, in as little as 3 months.

OK, So Maybe Just Get a Bigger SD Card?

Sure you could get a bigger SD card to minimize this problem, but throwing extra money at the issue is antithetical to the very concept of the Pi being a low cost platform. The Pi concept is already undermined by the need for peripherals like an HDMI cable, keyboard, display, and mouse–assuming you didn’t have these lying around, they’re not exactly free. At the point of shelling money out for a 16/32g SD you might begin to wonder why you didn’t get a relatively cheap linux powered laptop in the first place.

Hardware Workarounds

This is a good reason to consider configuring a USB drive to use for re-write intensive activities and to back up your data to the cloud frequently. USB flash memory has the same issues as SD memory in terms of write limitations, but the cards are cheaper, more portable, and separating the concerns of what data you have, and what configurations/installs you have made to your system, will make recovery from failure a mere issue of restoring data, instead of a labor-intensive matter of re-installation and re-configuration.


Compression, whenever possible, is a must. Deleting unnecessary files is a must. Ad-blockers that stop unnecessary loading of content are definitely useful too. Further configuration of browsers to avoid graphics intensive elements, etc. are a larger matter, worthy of some thought.

It might make good sense to move permanently installed files at least once, during the operating lifetime of the machine, to allow for load distribution across areas that were only written to during install. How one might do this in a reasonable manner leaves a few things to be considered… but it is not the most complicated system administration problem in the world.

comments powered by Disqus