A few months ago, I spent a week or two testing out different GUIs that will run on the Raspberry Pi (RPi). These included: Universal Gcode Sender (UGS), Chilipeppr, GrblWeb, and bCNC. I tested these, because I wanted to get my nice laptop out of the dust and metal chips. Since the RPi is $30-$35, has DVI out/USB/Ethernet, and is fanless, this seemed like perfect solution. If it breaks, no big deal. Just swap it out. After testing, I found that only two of the four GUIs worked under stress-testing, which involved pushing Grbl to it's maximum limits. The test basically sent g-code lines every 5-6 milliseconds and running at 25,000mm/min and 5000mm/sec^2. - bCNC, a relatively new GUI, is the only one that ran perfectly on an RPi 2 (still ok on the RPi 1). It was responsive throughout the job and executed it without any hiccups or problems. bCNC, maintained by Vasilis Vladchoudis, a CERN researcher, is written in Python and TK, so it's fully cross-platform and doesn't require any additional libraries, except pyserial. While it looks Windows95-ish due to TK, it works fanastically and has a ton of powerful features, like macro programming of short g-code programs, auto-leveling, virtual pendant (web server for smart phnoes/tablets). It's still in development and Vasilis is currently working on re-organizing the GUI and decoupling the front end so people can add their own skins. - UGS ran acceptably well only on an RPi 2. The RPi 1 was too slow. Recent nightly releases have improved UGS' performance to where the stress-test job would run and remain responsive to holds and other controls, only if the auto-scrolling checkbox was disabled. For the vast majority of jobs, you'll likely never run as fast as the stress-test, so UGS will work great for most people and most jobs. - GrblWeb worked somewhat ok. The most recent release of GrblWeb helped tremendously with browser responsiveness during an aggressive job, but the RPi2 web browser was still too slow to really make it useful. GrblWeb did work well when the RPi was only the server and you connected to it through a remote computer. This model may work at some point, when the RPi gets even faster, and the interface is kept simple. - Chilipeppr did not work at all on the RPi locally. The RPi web browser was too slow to run even a simple job and remain responsive. Chilipeppr will only work on an RPi, if the RPi is only running the Serial Port JSON Server (SPJS) and you connect to it from a remote computer. Since Chilipeppr still requires a laptop near the machine to control it, it pretty much nullifies the reason why I was trying to use an RPi in the first place. Not to have it in the shop or covered up from the dust. In addition, Chilipeppr does not do well with the stress-tests at all, even in the best case scenario of running it on a fast MacBook Pro (no RPi involved). The browser interface becomes non-resposnive and eventually crashes during the stress test. Anyway, I hope that helps some people that are looking for a similar solution!