It auto-powers on when the HDMI is connected. There's not a good way to get it to power off without just unplugging it.
You get roughly 3-4 hours of battery life.
The Raspberry Pi is woefully underpowered compared to modern PC's in terms of CPU performance. I'd put it in the same class as say middling Pentium III. The GPU is decent for a phone, if all you're doing is 2D/video stuff.
Some of the keyboard docks have a UK layout, which actually matches the default layout loaded by the Pi.
There's nothing that ties this to the Pi specifically - you could easily do the same with something like this quad-A9 board and get radically better performance (at the cost of battery life): http://www.hardkernel.com/renewal_2011/products/prdt_info.ph...
> The GPU is decent for a phone, if all you're doing is 2D/video stuff.
The lack of CPU power wouldn't be such a big issue, since the real computing power of the Pi is in the GPU anyways, except that you can't actually do anything else with the GPU, because you need to use Broadcom's driver blob.
As a side note, I think it's pretty disappointing to have an "educational", "open" computer that blocks you from actually using all the hardware.
It is a bit disappointing, but they have taken the pragmatic view, that it is better to have what they have delivered than nothing at all.
I would really like to see what the full capabilities of the chip are. The GPU seems to implement almost the full GLES driver itself. As I recall, it iss compiling the shaders GPU side. That's some considerable general purpose computing hidden behind the wall.
There are a few people targeting compilers and assemblers at the VPU. I think vbcc will probably come first, but I'm aware of people hacking on gcc and llvm.
I generate all assembly from emit() calls in C, but I may publish a better assembler soon.
The QPU work is not so advanced, but we actually have had a handle on the QPU instruction format for a while now, but we need more hands on deck to expose it in the open. There is also a challenge of hooking into the blob and dispatching QPU fragments. I would hope we have something working by the Q3.
The on/off problem exists throughout the new world of Arm devices. All the new low-cost mini-PC things coming from China suffer from this too... the good ones have a physical on/off switch, the bad ones are a huge pain to sleep/wake and are generally always-on. A handful of higher-end (over $100) devices actually support sleep and wake-on-airmouse-activity.
I already have one of those $100 Android netbooks[1] you can get from Alibaba.com, but it's Android[2]. I would pay $200 for an ultra-lightweight Raspberry Pi netbook that was in the same netbook shell as my android netbook. In fact, I've been looking everywhere for some steps to installing RaspberryPi(or any linux) onto my Android netbook.
2.Not that I don't like Android, I have 2 legit android devices that I use daily; Kindlefire with SimpleCM9 and the Samsung GalaxyPlayer50(not the phone). Just that, a hacked-together Android netbook isn't the best experience... but it's very lightweight and battery-life is like an iPad or better. After installing Chrome/Firefox and Google Keep(or evernote), it's at least good enough to take into meetings... and netflix works on it. But beware! It's headphone jack isn't stereo; you only get sound in the left-ear! Go buy mono-headphones.
Honestly, I think Google should be looking at ditching Chrome and making it into a skin on Android. They've over-fragmented their own market by having so many different platforms.
I guess - I do wonder what the performance of the chrome browser, rendering 'full' sites, might be like on Android compared to ChromeOS. Not that it should be that bad, the processor is a pretty decent dual-core exynos thing, and it has a couple of GB of RAM.
I actually really like ChromeOS. I bought the xe303 to run ubuntu on, but most of the time I end up booting ChromeOS because it turns out that 99% of my casual computing can be achieved in a browser or using the dev shell and ssh.
I'd settle for a Wayland driver running on SurfaceFlinger. run a chroot Linux distro and you can run Android apps and have an 'app' which behaves like a real computer.
I do wonder if the thing that is deterring Google from this path is that ChromeOs is designed to be Cloud and rather than give people what they want they are trying to give people something that would help their business model.
I always thought that they had the two platforms reversed. Chrome OS would make a better phone platform, since the always-online nature of phones is a better fit for an OS that needs to be always online (with the exception of the limited offline-mode of some apps). Whereas a laptop device usage pattern (sometimes-online, sometimes-offline) would fit Android better.
As mentioned by Nursie, the Samsung Chromebook XE303 is much faster, look better and has a better battery life while still having the same form factor. It's also a bit more expensive (still cheap). The Android netbook has a bit faster cpu then the Raspberry Pi netbook, although I don't know about battery life, does anyone know? The keyboard seems a tad to small, can you type on it more or less comfortably?
My Acer atom netbook (similar size) gets 3-4 hours with Linux and ssd.
I've got two of these Lapdocks, I bought them for $50 back when they first started being liquidated. I currently use one as the display for a BeagleBone Black for some project I'm working on.
This setup isn't really anything new, people were running this sort of thing a year ago, and there are lots of variations of it including embedding TV-HDMI-stick systems (like the RK3188) directly into the case hinge of the lapdock so you have something more like a standard laptop.
In any case, I highly recommend picking up the lapdock if you can find one for a good price. I'm not sure I'd pay close to $100 for one, but for $50 they were a great deal. They make great displays for Linux ARM SoC projects. If you actually want an ARM based laptop for general purpose laptop stuff, the Samsung ARM Chromebook already mentioned in this thread is a better all-around solution for not much more money.
The raspberry pi is absolutely not the cool thing about this set up[1]. The cool thing is that in 12 months you can switch out your SOC for a better one.
1. The pi is good because it has a large community and GPIO pins, it's a terrible choice for a 'PC' device today-- it's pretty much the weakest CPU you can get in the ARM/SOC world, with an out of date instruction set (v6 vs v7). You'd be much better off going with a beaglebone black or MK802, at the low end, with a world of more powerful options.
I have a budget (£99) Android phone from Samsung, non-contract (pay as you go/"pre-paid"). It has an 800MHz processor and web browsing on it is great. I have a Raspberry Pi, it has a 700MHz processor. The web browsing experience with more than one tab is awful. It can barely handle 2.
My boss told me about this on Friday. Looks cool. He's ordered the parts from E-bay. I have a Pi, and I'm using it to learn to teach breaking and fixing Debian.
(So far I've learned that ARMv7 is supported by debian armhf, and ARMv6 is the hardfloat support offered by the Pi. And that this difference is so important, that somewhere deep in the Perl modules of Debconf, is a breaking change that apt can't resolve for itself when you upgrade raspbian to plain debian armhf.)
I really was looking for help with this, I spent some time delving into the perl modules and tracing the errors, I came up onto some collection of Debconf modules that just did not seem to have a central "source" of the problem, just a lot of co-dependent requires and I could not trace back to find what needed repair.
It's somewhere there, in /usr/share/debconf/frontend. If I knew what package had problems, I could fix it with `dpkg` or even `ar -x`, since Apt-Get really wants Debconf and friends to work in order to do its job... but as-is, I can't even install any version of dash from the correct repositories without bombing out in post-install, and I feel really lucky to even have a shell to attempt a fix, at this point.
If anyone has a Pi and they're comfortable breaking it (to see for yourself, or to help me figure it out), change your apt-sources to like this:
deb http://ftp.debian.org/debian wheezy main
If you are on raspbian and your arch is armhf, proceeding through `apt-get update && apt-get -uy dist-upgrade` will almost totally hose your system. Reboot, log in, have a keyboard and mouse for the next part.
Network/interfaces will be broken so you'll need those, because you just ruined /bin/ip, it will segfault. Keep a copy of the old iproute package from raspbian, or be sure you know how to use ifconfig and route to get back online so you can download another one, since dhclient will also be hosed. It either segfaults or depends on /bin/ip.)
The only way to come back from this I've found is re-flashing the original raspbian image. I can't do it because my SD card does not read in my laptop / I'm stubborn and convinced that it can still be fixed.
You will not be able to install any packages that have Debconf post-install hooks, b/c illegal instruction in perl, some depended module. That's the part I can't figure out.
A lot of other things will be broken until you revert libc6 and libstdc++6 to the version provided by raspbian. At this point,
dpkg --get-selections|cut -f 1
and
apt-get --reinstall install
are your best friends. But it won't fix everything. It needs Debconf to be intact for some things to complete.
Some packages were not being downgraded because apt-get won't downgrade them without explicit directions on what version to download, even if it's the only version in pool for your target.
I needed either libalgorithm-diff-xs-perl, libpthread-stubs0, or libtext-charwidth-perl, and after that, only menu was the last remaining Segmentation fault. Extracting the package manually and replacing /usr/bin/update-menus enabled me to reinstall the remaining packages without errors from debconf and friends.
-- Sorry, spoiler, if anyone was following my awful example.
I definitely did not follow the shortest path thru this maze.
As far as I know, Debian armhf is compiled for ARMv7. This means that the compiled executables will sometimes use instructions that aren't implemented on older ARM cores. As the processor on RaspberryPi is ARMv6, don't expect to ever run the official Debian armhf. I think it is theoretically possible to compile for ARMv6 using hardfp, but at this point it seems unlikely distributions would put in the effort to improve FP performance on such old hardware.
I understand that now, but when you pull the trigger on dist-upgrade without that knowledge, you're going to want to revert it, and I needed to learn to read strace to figure it out.
I have put semi-instructions to go back in this thread, in case you want to try a foolish thing like I did.
I don't know of a good place to put this on the python.org site, but I (a PSF board member) can confirm that it is indeed a PSF project done in cooperation with the Caktus Group. This was something that was done by them to go along with PyCon 2013's wide promotion of the Raspberry Pi.
There are a bunch of people making portable pi systems.
This one is pretty easy. It's also weirdly expensive considering the power of the machine you end up with. Ignoring the cost of the Pi - something like this costing about $50 would be great. I guess you could scavenge parts together. It's useful for some forums and very light web work. I don't know if that's evidence of the web failing or succeeding - that a 750 MHz machine isn't powerful enough for it.
Other people are being a little bit more adventurous. Here's one with a 3d printed case (http://blog.parts-people.com/2012/12/20/mobile-raspberry-pi-...) It's not as sleek as, for example, an OQO umpc but it's still pretty nice for something built at home.
Having read through a bunch of these I wish they'd start to use sleeving when they splice cables together. Little bits of heatshrink or hellerene tubing makes all the difference to reliability and neatness.
It seems the RPi is fulfilling its role as an educational tinkerer's gadget.
And probably a few others around the Internet as well. Perhaps some enterprising person could come up with a laptop into which you plug in a raspberry pi?
The Atrix, too bad. Like polshaw said, I agree that the Pi is the weakness in the set up. It's like taking a honda engine and putting it in a BMW. I thought the Atrix and the accessories were awesome, just wasn't a fan of the low specs and Android.
I do have hope though for Ubuntu's mobile offering...wait that runs on an Atrix too, lol.
What type of battery life would you get assuming no gui and not using HDMI? Now that there is an Arch immage for the pi with Emacspeak I've considered building something like this to take notes at meetings to avoid having to haul my work laptop around.
what is the maximum portable battery life that can be gained from this system, how long does the monitor run in low power mode? I'd like to know if you could beat the Samsung 3 Chromebook with this (6.5 hours) and get some work done in perhaps 10 hours?
I have the 'lapdock' used here; with a phone (the original use case) IIRC it was quoted for 9 hours.. and that must have included powering the phone too, because it would keep the phone battery full. So, possible, i think.
Wow, that's impressive. How is the typing on it, is there a keyboard, is it smaller or the similar to current netbook keyboards? So if you could connect a Nexus 4 phone to it with hdmi, hack Linux on that phone you'd have a netbook comparable in performance to the current atom netbooks and a bit slower then the Samsung 303 chromebook.
It auto-powers on when the HDMI is connected. There's not a good way to get it to power off without just unplugging it.
You get roughly 3-4 hours of battery life.
The Raspberry Pi is woefully underpowered compared to modern PC's in terms of CPU performance. I'd put it in the same class as say middling Pentium III. The GPU is decent for a phone, if all you're doing is 2D/video stuff.
Some of the keyboard docks have a UK layout, which actually matches the default layout loaded by the Pi.
There's nothing that ties this to the Pi specifically - you could easily do the same with something like this quad-A9 board and get radically better performance (at the cost of battery life): http://www.hardkernel.com/renewal_2011/products/prdt_info.ph...