What is it about Linux that makes it so attractive for non-x86 platforms?
It’s obvious — Linux™ has become an attractive option for non-x86 platforms. Why? In this article, the author examines the reasons for this, including the fact that Linux on non-x86 enables affordable, easy-to-do virtualization; provides for better reliability, power consumption, and extended memory support; covers the lower and upper ranges of machines, giving users options outside of the middle range; revitalizes older hardware; and drives innovation.
In the early days, Linux ran on just a narrow range of systems, mostly processors compatible with the Intel® 80386 processor. But the drive to get the first shell prompt on a new piece of hardware motivates people to do crazy things, targeting a variety of processors that "everyone knows" are not viable Linux platforms, such as handheld computers, watches, game consoles, and a variety of workstations and servers.
Some people tend to dismiss non-x86 Linux as an idle amusement (it isn’t; it’s actually more than just a lot of fun). Linux development for other-than-x86 hardware has led to improvements in the quality of the Linux kernel, even for x86 users. Today, the main Linux kernel has code for 22 architectures, although not all of them are equally well supported or mature.
There are two questions to consider when looking at non-x86 Linux:
- "Why would I run Linux on this hardware?"
- "Why wouldn’t I use an x86 for this?"
Most Linux users are already familiar with the reasons to run Linux instead of another operating system. In this article, I’ll take a look at the reasons to run Linux on something other than x86.
Linus himself originally thought portability was a non-issue. In fact, he dismissed it as academic and potentially harmful to performance, so the early Linux kernel was designed entirely without consideration for other architectures or possible porting. Some originally thought this would doom Linux to being a single-architecture system, its life and death inextricably tied to the Intel architecture.
Others saw it as a challenge.
The first porting work targeted Motorola 680×0 chips, specifically the Commodore Amiga. The Amiga has always had a number of UNIX® enthusiasts and was also one of the first targets for NetBSD, not to mention having an official port of SVR4 UNIX. This porting effort was quickly extended to cover the Atari ST series computers, although only systems with an MMU were supported.
Early on, non-x86 Linux ports were maintained as separate source trees, integrating patches from the main kernel tree or porting changes back to it. The majority of the Linux/m68k ports were integrated into the main Linux kernel in version 1.3.94. Today, new work tends to get into the main tree faster. Portability is now seen as a serious concern, and developers don’t want to spend a lot of time tracking each others’ patches back and forth.
The first couple of ports were a learning experience for everyone involved. Operating system portability across architectures was not something that most programmers had much experience with in 1991.
The early ports of Linux to non-x86 hardware were essentially recreational. They were ports to systems that were generally a little older and slower than the commodity x86 hardware but which users liked for other reasons. (For instance, I still miss my Amiga keyboards.) The reason new hardware was targeted so much was because it was interesting; this carried as much or even more weight than any actual need to run Linux on it.
Whatever the reason, though, the possibility of running Linux on other systems, coupled with widespread buzz and interest in Linux, led to an interesting development in 1998.
In 1998, a major milestone for cross-platform Linux was the announcement of an attempt to port Linux to the IBM System/390®. Even though IBM no longer calls these machines "System/390" (they’re now called zSeries), the architecture directory is still named s390. IBM refers to this port as showing up in 1999, presumably because the creation of a mailing list for discussing a port isn’t quite the same as a shipping product. But, in under a year from the mailing list discussion, Linux was viable on the System/390. That’s sort of cool, but most users wouldn’t gain any benefit from running Linux on a bigger machine.
The big surprise came when people realized they could get Linux up and running on virtual machines on a mainframe. The System/390 architecture allowed complete virtualization of the machine, including even the "privileged" instructions that simply ran inside the sandbox created for them. This allowed Linux on a System/390 to be run inside a virtual machine (or multiple virtual machines).
A single physical box could run quite literally hundreds of distinct Linux servers, each entirely separated from the others. The security and administrative advantages are significant; for instance, there’s simply no way for an attacker who’s penetrated one virtual machine to affect another. This gives the advantages of multiple separate machines without the huge overhead of running hundreds of separate power supplies, disks, memory controllers, and so forth.
This port was of particular interest to enterprise developers. It’s a little pricey for home users, but it’s an excellent feature for people who want to run a lot of services without worrying about security or other interactions between them.
The development of Linux for mainframes showcased the beginning of the use of non-x86 hardware for more than just fun and games. This was no longer just a way of doing the same things you’d do on x86 hardware — this was something new, interesting, and above all, innovative.
Linux runs on a lot of virtualized hardware. One interesting port, user-mode Linux, runs Linux on Linux. It provides a virtualized machine that can have whatever hardware features you want, allowing the Linux kernel to be run in a safe little sandbox. It’s conceptually similar to the mainframe versions, but it’s aimed more at desktop users. User-mode Linux is a way to test new kernels, debug kernels, or even debug user applications.
For a long time, people have used programs such as Serenity Virtual Station or VMware to provide benefits similar to those offered by mainframe Linux, or to build test systems for software tests without having to actually assemble additional machines. User-mode Linux is sometimes useful for similar tasks, but it takes a slightly different approach. Whether it’s an x86 or not depends on which version you run; it’s also working with PowerPC®. This makes for a low-end way to run virtualized machines.
Non-x86 hardware can offer capabilities that are rare or unheard of in x86 hardware. One of the more subtle capabilities is reliability. While individual x86 machines are often fairly stable when running for a year or more at a time, other systems may be somewhat better engineered to stand the test of constant operation.
Much x86 hardware has poor, limited, or non-existent support for ECC memory. Support for redundant power supplies and other features can be hard to find. Interest in better hardware reliability has been a driving factor in running Linux on POWER™ or SPARC workstations and servers or on some older MIPS systems.
A capability that’s essentially absent in most x86 hardware is reasonable power consumption. Even the comparatively low-power chips used for embedded systems often use a great deal more power than the competition from ARM and PowerPC microprocessors. This is why a lot of handheld devices have been based on ARM processors such as the Compaq (now Hewlett-Packard) iPAQ line of handheld computers. Ports to systems like this made quite a buzz when Sharp introduced its Zaurus handheld based on ARM processors and Linux.
Competing handheld development platforms have not offered developers or users the flexibility and control that Linux does. Sharp’s work, although not a huge market success, got people interested in running Linux on handhelds and gave them access to the code they’d need to do the work themselves. The current Linux-on-PDA ports reflect this early work, and the Opie project (Open Palmtop Integrated Environment, originally designed for the Zaurus) is now available for other devices as well.
From the perspective of hardware, x86 Linux falls in the middle of the range. For a smaller box, one with lower power consumption, or a larger, more reliable system, you have to go to a non-x86 Linux system.
New life for old hardware
Another reason people keep porting Linux to old hardware is that Linux often runs on hardware that the vendor has mostly abandoned. Mac OS X won’t run on a lot of older PowerPC systems, but Linux is just fine on them. A friend of mine is still running a 90-MHz Pentium® as a Web server under a light load — I wouldn’t want to try to load Windows® XP on that.
The same issues apply to other platforms. Mac OS X is virtually unusable with less than 256 MB of memory, but an old Power Macintosh with 32 MB of memory can be a wonderfully functional Linux workstation or server.
Non-x86 Linux serves the same function that x86 Linux does when it comes to rescuing old servers from the junk heap. On the extreme end, ports like uClinux and ELKS target processors that are "too small" for regular Linux; in particular, systems without a memory-management unit that can support virtual memory. Of course, not every tiny system is old. Modern embedded systems are often small and Linux can run on them too.
Some devices, such as simple routers, are being built based on Linux distributions, especially around BusyBox (BusyBox, the "Swiss Army Knife of Embedded Linux," combines tiny versions of many common UNIX utilities into a single small executable). This results in a lot of users working out ways to reflash the chips in routers to update software support, add features, and otherwise update them.
In some cases, a company will encourage this experimentation and adaptation instead of trying to prohibit it — one result, the Kuro Box, is probably the cheapest PowerPC system out there (the Kuro Box is a customizable embedded Linux development kit that allows users to create a customized embedded Linux solution via a root access shell session and lets users install an internal IDE hard drive of any size).
This brings us back to the specialized capabilities question. My old Sharp Zaurus isn’t actively supported by the vendor now, but I can still update it with other Linux versions and software and get some extra mileage out of it. Similarly, those tiny little router/NAT boxes are pretty cool specialized hardware; they’re generally fanless and silent with multiple Ethernet ports and sometimes a wireless port. It’s pretty hard to build a box like that from parts you can buy retail.
Just playing around
Of course, there’s still a certain amount of just pure fun to be had, and don’t discount enjoyment for its own sake; it can be a powerful driving force for adaptation.
Linux has been successfully ported to both the Sony PlayStation 2 and the Nintendo GameCube. The PS2 is based on a custom CPU called the "Emotion Engine," which is based on a MIPS core. And what a stroke of luck that Linux was already ported to MIPS hardware. The GameCube is based on the PowerPC processor, another early port. The SH port, targeting the SuperH chips (made by Hitachi once long ago) works on the Sega Dreamcast and continues to be a popular target for hobbyist programmers.
Game consoles often use non-x86 hardware (the current Xbox being a notable exception), and Linux ports to this hardware give developers access to machines that are literally designed for game developers. For the most part, people aren’t trying to use these machines as workstations — they’re for playing around.
Thankfully, the Linux community is still full of people who do things "just because." As it turns out, that desire has led to code branches that have been of real commercial value and that have made Linux ever more ubiquitous and flexible. Pure research can pay off.
Even though non-x86 Linux systems are likely to be in the minority for some time, the development efforts that made them possible have made the Linux community better off as a whole and have even helped the x86 community reach higher. If Linux hadn’t previously been ported to a dozen other architectures, the x86/64 port for the 64-bit Athlon would have been orders of magnitude more difficult than it was.
There’s value in having fun.