- What Is a Netbook?
- Yes, But Does It Run Linux?
- Is a TV a Computer?
- The Form Factor
- Storage
- So, What Do I Want?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Yes, But Does It Run Linux?
Windows compatibility is one of the biggest issues limiting the capabilities of devices in this market segment. The Asus Eee PC originally shipped with Linux, but one of the marketing promises was that you could replace it with Windows XP if you didn't like Linux, and some of the machines sold with Windows XP preinstalled.
In order to run Windows, you have to use an x86-compatible CPU. You could use something else and run Windows CE, but this strategy eliminates pretty much the only reason for choosing Windows these days—wanting to run a program that works only on Windows. The lowest-power Intel chips in this segment draw around 2 watts. Competing ARM chips typically draw around 250 milliwatts (mW). These figures aren't entirely fair to compare, since the ARM chip usually comes with an on-chip GPU, memory controller, peripheral controllers, and often a DSP. If you're doing something like playing music that just uses the DSP, often you can get this usage down to under 50 mW. The Intel chip requires a large secondary chip with a draw of up to 12 watts for all of these functions.
The bottom line is that people who don't want to run Windows are paying a huge premium in terms of power usage (and therefore battery life) for functionality that they don't need.
In many ways, it's a shame that Asus decided to go with Linux rather than a member of the BSD family. My experience with Linux on non-x86 platforms has been less than stellar. A trivial example was trying to get the name of the CPU to display in an "about" box. On Linux, this detail is found in /proc/cpuinfo, a plaintext file containing a load of information about the CPU. This means that on Linux I needed to write a parser for understanding this file format. Not a huge problem, until I tried to run the same code on PowerPC Linux and discovered that the format was different there. Similarly, power management functions differ between platforms. The best way of playing sound depends on which driver the user has picked (OSS or ALSA). In contrast, I've written code for each of these drivers on FreeBSD and Solaris and had it work on x86 and SPARC, and I've written code on OpenBSD and had it work on PowerPC and x86—and, apparently, ARM (although I haven't tested this myself).
Why does this matter? Because porting from Linux on x86 to Linux on ARM is about as difficult as porting between Linux and some other UNIX-like system. In contrast, code that works on any of the BSDs on one platform will work on any of the others, unless it relies on inline assembly code. Until Linux does the job an operating system is meant to do (hiding from the programmer the need to know about the underlying architecture), using Linux on ARM isn't going to save developers much work.
When UNIX was ported to the PDP-11, a decision was made to rewrite it in C, rather than assembly language, for the new architecture. Thus, the same operating system could be ported easily to the VAX and a number of other architectures later. Variants of UNIX have been ported to a large number of CPU families. The Free Software movement inherited this CPU-independence philosophy from UNIX—GCC currently supports more than 40 different CPU families. A lot of Free Software can be run on a different architecture simply by recompiling. Many OS X developers discovered that the same is true for proprietary software when Apple switched from PowerPC to x86, although this option is available only to developers, not to end users.
These days, very little software relies on inline assembly. A few bits may make some assumptions that are valid on only certain architectures (memory write ordering, structure alignments, byte order, or pointer size are the main issues), but these are rarer with high-level language or good frameworks. If you have modification and distribution rights to the source for the software you want to distribute, you aren't limited to a single CPU architecture. Going with x86 may be cheaper in that you're less likely to need to do any porting, but you'll lose features that help differentiate you from your competition.