FAQ
- What is this all about? Really?
-
The idea of the Handhelds Mojo project is to take existing desktop Linux distributions and compile them for mobile and embedded devices. We're not changing the software in the distribution. In practice, what we're doing is taking the 10,000+ software packages that are usually compiled for x86 processors and rebuilding them for ARM processors. See the overview page for background.
- How can I test one of the Mojo distributions?
- QEMU is a popular method. Another device we've tried things out with is a Nokia N800 tablet. Install the distribution on an SD card, plug it into the tablet, and execute programs off of the SD card within a chroot.
- The architecture field in the Debian control files is ARM - but the distribution is something else. Why?
-
Debian uses the architecture field in the control files to indicate which architectures an particular file can be compiled for. Because we run these distributions on small, embedded devices it is desirable that we compile each distribution once for each possible client architecture. For example, in the ARM family one may wish to optimize for XScale, ARMv5EL, XScale 2, ARMv6, ARMv6el-vfp, ARMv7, and so forth. It gets a little silly to keep adding "arm" variations to each of the thousands of packages just because we're recompiling for a marginally different instruction set and pipeline optimization. Hence we decided to stick to "arm" for everything and use the directory structure to allow users to sort out what the code has been optimized for.
- Why aren't you cross-compiling?
-
Our experience has been that very few packages are set up to cross-compile cleanly. We found that native compilation has worked very well on the vast majority of packages where we successfully compiled them without any modifications. The few cases we did need to modify packages were generally problems simply one or two line fixes.
- Isn't native compilation too slow on these embedded boards?
-
Well, yes, native compilation is a great deal slower than cross-compiling on a big, fast x86 box. On the other hand, it requires little or no human intervention and just quietly runs off in the background. Most developers are concerned about re-compiling just their local code for testing and debugging. Since we're running almost exactly the same distribution on our desktop computers as on the small devices, it's easy to test and debug the software on the desktop before going through the trouble of compiling for the small device.
- How can I help out?
-
There are several good ways to get involved. First, not all of the packages compile in each distribution. We've tried to ensure that the majority work, but there are always little packages in the corners that didn't compile. In many cases a small one or two-line patch to a key package allows dozens of dependent packages to compile successfully. A second way to help the project would be to working on our installation images. We're looking at creating standard Debian/Ubuntu installation images. A third way to help would be to get involved in setting up the security and bug fix feeds. We'd like to get the build system updating the security and bug fix feeds automatically.
|
