Developers/Setup

  For Developers

Previous Next

Sugar GUI Shell (Our Goal)

The OLPC's software environment is a heavily modified Fedora 7 Linux system running a custom GUI shell (Sugar). To develop for the platform you will eventually need access to a platform which runs in a manner substantially similar to the OLPC environment. To put it simply, you will likely need to have Sugar running on a computer.

There are two major approaches to running Sugar, running it natively on your machine, and running it in an emulated environment. Which approach you choose will depend on a number of factors, including:

• whether you are just wanting to check the platform out, or are setting up for long-term development work (i.e how much time you want to invest in getting the best possible setup)
• what type of hardware you have available to you
• how comfortable you are with working with traditional Linux tools such as ssh, and vim/nano editors
• what type of development work you are interested in doing

If you can neither run an emulated machine or run Sugar natively, it is still possible that you may be able to develop for the platform by #Cross Coding.

About Emulation

There are a number of tools which allow you to run an image of one operating system in a window on another system. If you have the hardware and want to get started as fast as possible, choosing an emulated approach is probably for you.

Emulation is a computationally intensive operation, it requires a powerful (modern) host machine with lots of RAM and lots of storage space. Each official image you wish to use will require about 2GB of disk storage with ancillary files and unpacking requirements.

Emulation is also a 90% thing, that is, it normally gets about 90% of the emulation correct, but things such as peripherals, sound, cameras, keyboards and the like can be "slightly off" in an emulated environment. You should always keep this in mind when working with a emulator.

Emulation Packages/Products

Emulation is a hot topic these days, there are lots of emulation systems available, some no-cost, some Open Source, some commercial. We cannot hope to support all of these systems, so we have focused our efforts on small subset of systems:

• Qemu (with the KQemu Accelerator)
  • Our best-supported emulation system
  • With the KQemu package provides reasonably fast emulation
  • Open Source and runs well on Linux and Windows machines
  • Basic setup is reasonably easy
  • Allows for working in "overlays"
  • Command-line interface on Windows, Linux and Mac, GUI available for Windows and Mac
  • Works directly with offical builds
• VMWare / VirtualBox
  • Commercial emulation packages with no-cost "players" for images
  • Somewhat easier setup than Qemu, particularly for advanced networking on Linux hosts
  • Require converted images, which are not always kept up-to-the-minute and do not include experimental/testing builds
  • Beta version of VMWare (Fusion) available for Mac OS X
• Parallels Desktop
  • Commercial emulation package
  • Extremely difficult setup
  • Mac friendly

Which emulation system you choose is mostly a matter of preference and suitability for your system.

See Also:

• Emulating_the_XO -- has a handy chart outlining which system has been reported to work with which type of emulation task

Emulation for Exploration

Want to just see what Sugar is like? Want to play with the activities and kick the tires? Downloading a Qemu or VMWare/VirtualBox image and running it is normally a matter of a half hour or so.

Emulation for Development

It is possible to code software on an OLPC-XO running Sugar. One of our long-term goals is to make this an easy and straightforward process. The "Gear" key on the keyboard of the OLPC-XO will eventually hook up to an IDE activity for altering and creating new code. That IDE is not yet finished, however.

Official Images

The only "normal" code editing environments present on the OLPC-XO are all command-line environments available through the Terminal activity. Official Sugar images include both the vim and nano editors, so users who know these editors can use them to write and modify software within the images.

Developers wishing to use the EToys application stack can create new software from EToys built-in development environment while running on an emulator.

Developer's Desktops

If you have a very powerful host machine, it is possible to run an entire "regular" Linux desktop with a sugar-jhbuild or package-based install of Sugar. This will tend to take a lot more memory, processing power and disk space than using an official image (which is, of course, intended to run on a relatively lightweight computer), but it gives you most of the benefits of the native Sugar approach.

See #Native Sugar

Emulation for Compilation/Experiments

One very useful feature of emulation systems is their ability to "snapshot" or "overlay" images. This feature allows you to leave a base image untouched while performing some messy or dangerous operation. When you are finished the operation, you can return to the unmodified base image.

For example:

If you want to support a piece of hardware that requires a kernel module, you can mount a Qemu copy-on-write or VMWare snapshot into which you install the whole kernel-compilation toolset (likely getting quite close to filling up the whole storage).

You can then compile the kernel and then the missing driver. When you are finished, you copy the driver to the host machine and can install the compiled driver into the base image.

Emulation for Testing

If you are #Cross Coding or using a #Native Sugar environment, you will often want to use an emulated official image for testing. This is often far more convenient than loading the image onto a real XO and doesn't require hardware you might not have.

For support operations, it is often handy to be able to load exactly the operating system image that a user is using in order to be able to duplicate a bug. You can use an emulated version of the system instead of a real XO to save "wear and tear" on the XO's flash storage.

Emulation tools often have the ability to share folders with the emulated machines, this lets you work on your host machine, quickly see if the code works on the emulator, and only then package up and test on a real machine (or potentially have someone else test).

It should be noted that emulators often have difficulties with sound support and graphics resolutions. They also can wind up being much faster or slower than the target hardware. See the Developer's FAQ below for some pointers on how to simulate the special hardware. Testing in emulation is valuable, but eventually the software needs to be tested on real hardware.

Getting Started (Emulation)

For a detailed exploration of emulation issues with a focus on using the official images, see Emulating the XO, which includes setup and configuration issues, tips and hints, and a grid of known-working approaches to emulating an OLPC-XO laptop.

You will need to install one of the emulation systems and download an image:

• Qemu + KQemu (recommended where possible)
  • Ship.2 -- patch releases for Official Releases
  • Joyride -- Bleeding Edge/Development Releases
• VMWare, VirtualBox (good secondary choices, particularly if you already have one installed)
  • All Builds -- collection of all the pre-converted images (the same images work on either system)

Follow the specific instructions on the emulation-system-specific pages linked to above to get started.

Native Sugar

If you are running a modern Linux Operating System (whether as your primary OS, as a Live CD, via dual-booting, or potentially even via emulation), it is quite possible that you can run Sugar directly on your Linux machine with its current OS.

Core developers will likely need to set up a sugar-jhbuild environment, sugar-jhbuild uses the bleeding edge version of each component, often checked directly out of the source-code-control for each project. It allows you to work with developers across many different projects, but it tends to be fragile as a result.

Activity developers can get away without a Native Sugar setup, but if you are coding a non-trivial Activity on a "normal" Linux machine, it is probably worth setting up either a sugar-jhbuild or a package-based sugar install to speed up your edit-run cycle.

Sugar as Your Shell

Sugar, though a bit exotic seeming compared to most GUI shells, such as KDE or Gnome, is really just a GUI shell. As such, you can run it either as the actual shell for a GUI login session, or in a virtual X session (that is, a window that mimics a whole X session/server).

The official OLPC images, of course, run Sugar as the GUI shell for the primary X server. So if you are running an official image (for example because you are working directly on an OLPC-XO) you will be running Sugar as your GUI shell. Similarly, the Live Backup Live CD, which is based on an official image, boots directly into the Sugar shell. On Fedora 7, you can also (with recent versions of Sugar) choose a Sugar session from your GDM/KDM/XDM-based login manager.

Virtual X Server

In most other cases, you want to run Sugar in a virtual X session. This allows you to have multiple Sugar desktops running and visible simultaneously to test networking and the like. The virtual X sessions can be quickly shut down and restarted without needing to log out and back in again. Most core developers are using this type of setup using sugar-jhbuild.

sugar-jhbuild

This is what the core development team uses and is one of the most pleasant ways to work (once set up). Compared with using an Emulated XO, installing sugar takes more time and space to set up, and can be difficult to maintain, but results in a more flexible environment.

The 'native' environment for sugar-jhbuild is Fedora 7, and this is by far the best supported development platform for sugar-jhbuild. Ubuntu (Feisty or Gutsy) and Gentoo can also build the environment.

Currently sugar-jhbuild requires about 2.5 hours to complete building on a modern workstation (AMD4800+).

You can run sugar-jhbuild under emulation. This has the advantage of working on a wider range of Linux hosts (as well as Windows or Mac OS-X), and does not "pollute" your host machine with Sugar libraries. It requires a lot of disk space and processing power, however.

See Sugar with sugar-jhbuild to get started.

Native Sugar Packages on Linux

As Sugar stabilizes and is ported to more distributions, it should be possible to use your Linux distribution's package management system to install Sugar. Distributions with ports so far:

• Ubuntu Gutsy -- Note that we need more testing of this package-set, please let us know your experiences

If you don't see your distribution here, ask your distribution maintainers, or if you have the skills, create the packages yourself and submit them.

A Real OLPC-XO Laptop

Hardware Developer's Program - while there are only a small number of test units being produced, developers can submit proposals to receive one of those units for testing and development.

You can also, if you live in the US or Canada, and have sufficient funds, until Dec 31, 2007 use the Give 1 Get 1 program to acquire a production-run machine (and donate one to a child).

If you would like to run a non-official (i.e. experimental, unstable) build on a Mass-Production/G1G1 machine you will need to acquire a developer key to allow your (locked) laptop to load the unsigned image. You probably do not need to run an experimental image for most activity development purposes.

See Also:

#Emulation for Development for discussions on the current limitations on using the official images as development environments

Live CDs

There are currently a number of projects underway to produce various types of LiveCD. LiveCDs are not a "normal" part of the development process, normally being used for lightweight deployments, experimentation, testing, and potentially installation onto a dedicated machine to create a workstation.

See #Emulation for Development for considerations regarding installing LiveCD's based on official images for development.

Cross Coding

If you can neither run an emulated machine nor run Sugar natively, it is still possible that you may be able to develop for the platform by developing your code on one machine and then porting it to the platform when you are finished.

Cross coding generally works best when you are working in a relatively constrained and abstracted environment. Of the stacks available on the Sugar platform, the following are well suited to Cross Coding activities:

• Browser -- Mozilla/Firefox-derived web browser
• EToys -- Squeak/Smalltalk multimedia environment
• Pygame -- raster-graphics game development framework
• Flash -- Gnash or Adobe-Flash engine

You may be able to install just the software involved in that stack in order to test and develop your game. You can then have a development partner do porting and testing to a Sugar environment.

See Also

• Sugar Instructions -- how to get around inside Sugar (i.e. how to use it)
• Support -- how to get help with running Sugar (on an OLPC-XO)

Previous Next