Running Linux on Samsung's ARM Chromebook
Hi, Samsung have had an ARM-based laptop for a while, sold as a Chromebook. (ie. with an Android-like Linux kernel and the Chrome browser as the whole OS) The little ARM cpu means the laptop doesn't need much power and can run for quite a while, despite being lightweight and cheap with a small battery. I was wondering how it'd go running a full version of Linux; just running a bunch of terminal emulators more of the time, and maybe Chromium from time to time. I've heard of people managing to get Ubuntu or other linux variants installed, but I wondered if anyone here has done it? Was it worth the trouble? Cheers, Toby -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world
Toby Corkindale <toby@dryft.net> wrote:
I was wondering how it'd go running a full version of Linux; just running a bunch of terminal emulators more of the time, and maybe Chromium from time to time.
Obviously you would need to be very selective in what to install so as to conserve resources. Start with a minimal installation, then add an X server, a window manager of your choice, Chromium and a terminal emulator. One of the smaller desktop environments (XFCE or LXDE) might work well, but some people still prefer to run just a window manager rather than a full desktop where hardware constraints are of concern.
On 19 February 2014 12:36, Jason White <jason@jasonjgw.net> wrote:
Toby Corkindale <toby@dryft.net> wrote:
I was wondering how it'd go running a full version of Linux; just running a bunch of terminal emulators more of the time, and maybe Chromium from time to time.
Obviously you would need to be very selective in what to install so as to conserve resources. Start with a minimal installation, then add an X server, a window manager of your choice, Chromium and a terminal emulator. One of the smaller desktop environments (XFCE or LXDE) might work well, but some people still prefer to run just a window manager rather than a full desktop where hardware constraints are of concern.
Well, it has 16GB of storage, 2GB of RAM and a dual-core 1.7 GHz ARMv7 CPU, so it's not all that constrained. But I don't know how well the Linux distros actually support the hardware? Does it run reliably, or glitchy? It looks like a temptingly-cheap $300 lightweight laptop, but I guess if I'm asking questions about reliability, I should probably not get a laptop that's going to be yet another hack project.
On Wed, 2014-02-19 at 12:51 +1100, Toby Corkindale wrote:
On 19 February 2014 12:36, Jason White <jason@jasonjgw.net> wrote:
Toby Corkindale <toby@dryft.net> wrote:
I was wondering how it'd go running a full version of Linux; just running a bunch of terminal emulators more of the time, and maybe Chromium from time to time.
Obviously you would need to be very selective in what to install so as to conserve resources. Start with a minimal installation, then add an X server, a window manager of your choice, Chromium and a terminal emulator. One of the smaller desktop environments (XFCE or LXDE) might work well, but some people still prefer to run just a window manager rather than a full desktop where hardware constraints are of concern.
Well, it has 16GB of storage, 2GB of RAM and a dual-core 1.7 GHz ARMv7 CPU, so it's not all that constrained.
But I don't know how well the Linux distros actually support the hardware? Does it run reliably, or glitchy?
It looks like a temptingly-cheap $300 lightweight laptop, but I guess if I'm asking questions about reliability, I should probably not get a laptop that's going to be yet another hack project. _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Hello Toby, Based on my research (and this is only, and only me, others may differ), this is a hack project. If you want to have some fun and if you have plenty of spare time, go ahead. If you can spare a few hundred more and get something with more memory and HD resources. If you want a toy, this is nice. If you want something more decent, find something better... Don't get me wrong, it will run linux (a lot of things do, even a crockpot!), but after some massaging (and quite a few hours of your time). ChromeOS (based on my research) is a glorified browser. GNU/Linux is a full OS. Just my 5c. Cheers, Davor
On 19/02/14 12:51, Toby Corkindale wrote:
On 19 February 2014 12:36, Jason White <jason@jasonjgw.net> wrote:
Obviously you would need to be very selective in what to install so as to conserve resources.
Well, it has 16GB of storage, 2GB of RAM and a dual-core 1.7 GHz ARMv7 CPU, so it's not all that constrained.
Whether it's powerful enough or not is not the point. The point is that the amount of eye-candy you would typically run on a desktop machine is not conducive to battery life. I feel it is probably also worth pointing out at this point that GNOME Shell is written in JavaScript. Take from that what you will.
On 19 February 2014 15:53, Jeremy Visser <jeremy@visser.name> wrote:
I feel it is probably also worth pointing out at this point that GNOME Shell is written in JavaScript. Take from that what you will.
JavaScript.. The language that is now interpreted so fast that it outperforms C++ at times? The language that people have been able to use to write Quake and Doom clones that perform quite well in your browser? I don't have a problem with someone basing a window manager on that!
On 19/02/2014 12:51 PM, Toby Corkindale wrote:
Well, it has 16GB of storage, 2GB of RAM and a dual-core 1.7 GHz ARMv7 CPU, so it's not all that constrained.
Also, keep in mind that an ARM running at 1.7 GHz is nothing like an x86 chip running at that speed. There is the whole RISC (ARM) vs CISC (x86) situation to consider. On some tasks RISC is far superior, but because of the reduced instruction set (RIS par of RISC), it may take more cycles to do some things and therefore those tasks take longer and potentially drain the battery quicker. If you are selective where you run those tasks, then you can choose the right tool for the job, ARM not being right for such particular tasks. OTOH, an x86 chip with the latest power saving technologies gives fuller complex instruction set (CIS part of CISC) ... this can mean the that CPU handles a task extremely efficiently and therefore more quickly, allowing the CPU to fall back to a lower power setting (ala idle state) or give you more grunt when you need it -- of course, like a V8, the more grunt you use, well it doesn't come free, in the CPU world that will mean more power usage and consequently less battery life, particularly if you "gun" it all the time. At then end of the day, comparing ARM with x86 is like comparing apples with oranges. Or perhaps more so in the computing world, Motorola vs Intel. For many years Apple made use of Motorola to great benefit, but they've moved to Intel for various reasons, not least of which, Intel or x86 must have enough advantages over the Motorola offerings. Still, Motorola is not AMD either; that's where the analogy breaks down somewhat. Cheers A.
On Wed, 19 Feb 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
On 19/02/2014 12:51 PM, Toby Corkindale wrote:
Well, it has 16GB of storage, 2GB of RAM and a dual-core 1.7 GHz ARMv7 CPU, so it's not all that constrained.
Also, keep in mind that an ARM running at 1.7 GHz is nothing like an x86 chip running at that speed. There is the whole RISC (ARM) vs CISC (x86) situation to consider.
On some tasks RISC is far superior, but because of the reduced instruction set (RIS par of RISC), it may take more cycles to do some things and therefore those tasks take longer and potentially drain the battery quicker. If you are selective where you run those tasks, then you can choose the right tool for the job, ARM not being right for such particular tasks.
http://en.wikipedia.org/wiki/ARM_architecture#Instruction_set The ARM instruction set doesn't seem that reduced. There's the Thumb instructions, SIMD, Jazelle, and lots of other complications. Also the original RISC concept was based around the idea of a super-scalar processor being necessary to take advantage of linear reads of RAM. But for a long time all forms of main memory access have been slow when compared to a CPU. Modern Intel CPUs have as much as 20M of L3 cache to deal with this and CISC features such as a variable instruction width are better in this regard (which is why they have Thumb). http://vr-zone.com/articles/forget-benchmarks-arm-uses-real-life-gaming- performance-prove-beats-intel-video/59935.html A quick Google search didn't turn up any good micro-benchmark results comparing ARM and Intel CPUs. But the above article is interesting, it compares tablets based on ARM and Atom CPUs and shows the ARM tablet winning. Even though it's difficult to compare CPUs I think that showing a 3D game performing well is an indication that the device has adequate CPU performance for most workstation tasks.
At then end of the day, comparing ARM with x86 is like comparing apples with oranges. Or perhaps more so in the computing world, Motorola vs Intel. For many years Apple made use of Motorola to great benefit, but they've moved to Intel for various reasons, not least of which, Intel or x86 must have enough advantages over the Motorola offerings. Still, Motorola is not AMD either; that's where the analogy breaks down somewhat.
http://en.wikipedia.org/wiki/68000 http://en.wikipedia.org/wiki/80386 http://etbe.coker.com.au/2008/09/11/execmod-and-se-linux-i386-must-die/ The 680x0 ISA had some benefits, 8 general purpose registers vs 4 is a major difference. The lack of registers on i386 caused many performance problems and also drove the use of some hacks that weakened system security. The execmod problem probably wouldn't have occurred if we had all been using 680x0 CPUs. The advantage Intel had over Motorolla is a greater market share which gave them more money to spend on fabs. Making smaller transistors allowed bigger caches and higher clock speeds which gave better performance in spite of architectural issues such as a lack of registers. Also a significant amount of developer time has been wasted due to a lack of registers on i386. That would result in some combination of less development costs, less bugs, or more features. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 19/02/2014 7:43 PM, Russell Coker wrote:
http://vr-zone.com/articles/forget-benchmarks-arm-uses-real-life-gaming- performance-prove-beats-intel-video/59935.html
It's still all horses for courses..... ARM chips usually have excellent dedicated GPU components which deal with video; such components lend themselves well to CISC type architecture and are themselves [the GPU parts] dedicated for video processing type tasks -- that is, they free up the /main/ processor by dealing with the video content requirements. This is much like higher end NICs have specialized chips that do the heavy work so other parts can be less encumbered; low end NICs rely on the CPU of the PC to deal with the heavy lifting. Other general purpose computing uses of ARM chips gives lesser performance. A.
Russell Coker <russell@coker.com.au> writes:
The ARM instruction set doesn't seem that reduced. There's the Thumb instructions, SIMD, Jazelle, and lots of other complications.
FYI, Jazelle's deprecated by ThumbeEE as at v7.
Even though it's difficult to compare CPUs I think that showing a 3D game performing well is an indication that the device has adequate CPU performance for most workstation tasks.
In a general sense, yes. But AFAIK graphics is heavily FPU-bound (floats) where systems tasks are heavily ALU-bound (integers). So modulo GUI desktopy bits, you probably want specint rather than specfp.
On 20 February 2014 11:25, Trent W. Buck <trentbuck@gmail.com> wrote:
Russell Coker <russell@coker.com.au> writes:
The ARM instruction set doesn't seem that reduced. There's the Thumb instructions, SIMD, Jazelle, and lots of other complications.
FYI, Jazelle's deprecated by ThumbeEE as at v7.
And ThumbEE was in turn deprecated by ARM v8. I don't know if anyone ever used Jazelle or ThumbEE much?
Even though it's difficult to compare CPUs I think that showing a 3D game performing well is an indication that the device has adequate CPU performance for most workstation tasks.
In a general sense, yes.
But AFAIK graphics is heavily FPU-bound (floats) where systems tasks are heavily ALU-bound (integers). So modulo GUI desktopy bits, you probably want specint rather than specfp.
Look at the Raspberry Pi -- it can do high-res video decoding just fine, but that is no indication that it is at all fast at general stuff. (It's so not, despite what anyone tells you). I've used multi-core ARMv7 systems and they're pretty useable at the sort of speeds that Chromebook runs at, so I reckon it would probably be OK for the target purpose of xterm windows and some light browsing in Chrome. But as others have pointed out.. it's going to be a fight to run Linux on it, and I suspect as much as it'd be good to have an ARM laptop I just won't want to be spending the time to make it work reliably. T -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world
Toby Corkindale wrote:
But as others have pointed out.. it's going to be a fight to run Linux on it, and I suspect as much as it'd be good to have an ARM laptop I just won't want to be spending the time to make it work reliably.
FWIW I've been using a TF101 as my only computer (apart from an OpenWRT) for... 18mo? Something like that. Most of the hardware isn't working, but it's enough I can run Emacs and SSH in a terminal, and at that point I stopped giving a shit because my old Eee had died unexpectedly and I needed *something*. Due to the evilness of tegra2 reflashing, I haven't bothered to fiddle with it since. But I *do* get excellent battery life, which was the whole point of the exercise.
Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> writes:
There is the whole RISC (ARM) vs CISC (x86) situation to consider.
Erm, AMD64 CPUs are RISC under the hood.
OTOH, an x86 chip with the latest power saving technologies gives fuller complex instruction set (CIS part of CISC) ...
AFAIK this is gibberish (unless you're in the habit of hand-writing assembly).
this can mean the that CPU handles a task extremely efficiently and therefore more quickly, allowing the CPU to fall back to a lower power setting (ala idle state) or give you more grunt when you need it
I don't see how the ISA has any relevance to ACPI C states & their ARM equivalents.
At then end of the day, comparing ARM with x86 is like comparing apples with oranges.
If you only look at the clock, sure. That's true even between microarchitectures implementing the same ISA. You can meaningfully compare unalike systems using a benchmark like SPECint, though. (Synthetic benchmarks like dmips or bogomips are unlikely to give useful numbers.) https://en.wikipedia.org/wiki/SPECint https://en.wikipedia.org/wiki/Dhrystone https://en.wikipedia.org/wiki/BogoMips
Or perhaps more so in the computing world, Motorola vs Intel. For many years Apple made use of Motorola to great benefit, but they've moved to Intel for various reasons
Um, you're missing a big chunk of history there, namely the POWER derivatives. https://en.wikipedia.org/wiki/Power_Architecture AFAIK the biggest drivers for Apple moving to Intel weren't "zomg it's fastaaaar" but fungibility, economies of scale, and politics.
Toby Corkindale <toby@dryft.net> writes:
Samsung [ARM] Chromebook. I was wondering how it'd go running a full version of Linux [...]
Caveat: chromebooks are notoriously well locked down. For example, IIRC there's a hardware switch you need to flip, to boot off something other than itself (like, to install a normal linux). And that also erases your user data area, to ensure Bad Men can't get at it. Plus the usual quirks that ARM systems always have, but you can probably work around some (most?) of those by running either a bleeding-edge kernel, or the android-flavoured variant the vendor shipped. Pay attention to other people who have already fought the same model.
participants (8)
-
Andrew McGlashan -
Davor Balder -
Jason White -
Jeremy Visser -
Russell Coker -
Toby Corkindale -
Trent W. Buck -
trentbuck＠gmail.com