I finally got my Raspberry Pi yesterday, and wanted to ramble about it for a bit under the fold.
- The board is tiny and adorable.
- It uses several incredibly cheap connectors (Especially noticeable in the SD Slot and power MicroUSB). Not necessarily a bad thing (Don’t bitch, it cost $35), but they sure aren’t top of the line mechanical parts for how much they get manipulated.
- There are no screwholes/alignment tabs/etc. I’d like some holes to screw standoffs through, it would make encasement and dev-board use more convenient.
- The SD card sticks way out from under the end of the board when inserted. I’ve seen this griped about elsewhere, it really is pretty irritating, and possibly could have been avoided via clever layout. I personally would have preferred they just use MicroSD, but I appreciate the reasoning for a full card.
- It is (legitimately) a bit fussy about power. It powers from USB, and there are a lot of terrible USB power supplies out there – it is reported to misbehave with anything under ~750mA available on the 5V rail, and some of my cheap knockoff “1A” bricks were inadequate.
- The GPIO connector is, as my advisor put it, almost as good as a parallel port. I haven’t messed with it yet, but the API seems usable.
- There are a pair of flat-flex connectors exposing DSI and HDMI-CEC signals. I haven’t seen either used, it isn’t even clear if the software support for DSI is complete, and there aren’t drivers for the CEC device, so they are kind of useless headers at this point.
- It has a fairly opaque early boot process (the first stage bootloader is part of the GPU’s binary blob) which kind of gets in the way of openness. Having an open platform designed for teaching and understanding computers invoke blackbox magic as it’s first act after power on sucks.
- For example, you symlink in one of several blackbox pieces of init code to select CPU/GPU RAM allocation.
- Almost all OS distribution is being handled by the “DD this system image to an SD card to get started, and work from there” mechanism, with varying levels of scripts and automated behavior following the first boot, which is really a very convenient way of going about things.
- I’m really impressed by the level of polish for a young hobby platform. Don’t get me wrong, it does all kinds of quirky and terrible things, but the level of “Just works” with regard to common software and hot-plugging and the like is pretty remarkable.
- Various GPU features (link includes discussion) are disabled for licencing reasons, most irritatingly the hardware MPEG2 decoder required for smooth playback of most common sorts of all but the newest web distributed SD video. There has been some talk of a purchasable codec pack or some-such to remedy this problem, and I’m fairly confident it will be worked around legally or otherwise, but right now there are some stupid gaps in media playback capability.
I’ve tried a couple system images (when you can swap out a SD card to swap OSes, how could you not play?), and am generally pretty impressed. There are already a whole bunch of OS images available, and I expect more soon. There are some noteworthy things about the three I’ve fiddled with in the first day.
It really is just Archlinux, like the rest of my computers run. It boots into 50MB of RAM and is more responsive than some old P4’s I’ve drafted for experiments recently. I’ve run into a little bit of funnyness about the project’s build habits (ex: mplayer in the repositories is linked against an older libx264 than is provided). I also hit an irritating bug from upstream that didn’t get my big computers (see these example threads where the forumites were just bitchy about it to the OP, and this post that explains the issue from a user perspective.)
The Raspbmc installer is impressively automated, until it doesn’t work. Insert SD card into computer, run script, pick SD card from list, move SD cart into network-connected RPi… and it just kind of magics the rest, with a stream of pleasant status messages. Then it reboots and video out never comes back. Seems to be an OS image on the SD card, but it sure doesn’t look like it boots. My best guess is their install system makes some bad assumptions about SD card geometry, because I’m finding mostly success stories, mixed with lots of tales of models of card that don’t work on the ‘net. Hopefully I’ll get to play with it later.
The default installation is a full desktop environment, and it’s surprisingly snappy (probably because it does ARMv6 hardware floating point). The installer sort of splits the difference on techniques I’ve seen, images a full system, and runs a curses script on first boot to guide you through setup. The default desktop has shortcuts to system documentation and python interpreters (With sample code!) and Scratch, so it is clearly intended to encourage programming at whatever level one is ready for, and a bit of poking around reveals a full GCC tool-chain pre-installed. The amount of preinstalled software in this image is actually pretty remarkable – in addition to the selection of development tools, there is a well-featured modern *nix command-line userland, a fiarly complete LXDE environment, and a bunch of “light alternative” software, including three web browsers. This is probably the right starting point for most people.
Of the things haven’t messed with and would like to, the OpenELEC-derived XBMC system and the RISC OS image look like the most fun – I’ve never had OpenELEC actually work on anything in several tries, and never had hardware suitable for fiddling with Risc OS on hand before, so they should be interesting.
If you want a baby computer to play with, it’s as good as you can find anymore (stupid blobs…). If you want a media appliance that isn’t designed to lock you in to some vendor’s ecosystem, it’s well on it’s way to being competitive. One of the use cases I would most like a Raspberry Pi to be suitable for is as a cheap, small, silent storage server + media playback device, and I’m quite hopeful that I’ll be able to mold it into one – so it may be useful in addition to being fun.