Developers/Setup: Difference between revisions

From OLPC
Jump to navigation Jump to search
(Add an image of the final goal)
(there is already a link to Fedora when the term is first introduced)
 
(48 intermediate revisions by 19 users not shown)
Line 1: Line 1:
{{Translationlist | ko | origlang=en }}
{{Developers}}
{{Developers}}
[[Developers|Previous]] [[Developers/Stack|Next]]
[[Developers|Previous]] [[Developers/Stack|Next]]


The OLPC software environment is a combination of OLPC-tailored low-level system components (sharing as much with [[Fedora]] as possible), plus dual user-level platforms [http://wiki.sugarlabs.org Sugar] and GNOME.
[[Image:Sugar.png|right|thumb|Sugar GUI Shell (Our Goal)]]
The OLPC's software environment is a heavily modified [[Fedora]] 7 Linux system running a custom [[Sugar|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.


Development of components of Sugar and GNOME (really anything that directly faces the user) happens within the regular upstream [http://wiki.sugarlabs.org/go/Sugar_Labs/Getting_Involved#Developer Sugar developer] and [http://developer.gnome.org/ GNOME developer] communities. The content on this wiki relates to development of the lower level OLPC platform.
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:


== Recommended environment ==
* 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


[[Releases|OLPC OS releases]] are based on specific versions of Fedora. It is recommended that you install the matching version of Fedora on your development computer, matching the architecture (i686 or x86_64).
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]].


Although you will likely develop on your regular desktop computer, you will need an XO at your side for testing.
= About Emulation =


== Communicating with your XO ==
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.


=== SSH Access ===
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.


You will often want to be able to use file-transfer and remote-login operations to access your Sugar environment. We generally recommend using ssh-based access for working with your Sugar environment remotely.
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.


==== Password Based ====
== Emulation Packages/Products ==


Password-based SSH authentication is convenient and simple to set up, but it is far easier to crack than key-based access. Consider using key-based authentication unless you are absolutely sure that no-one can reach your Sugar environment from untrusted networks (and maybe even then).
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:


Open a [[Terminal]] activity and run:
* [[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
* [[Emulating_the_XO/Parallels|Parallels Desktop]]
** Commercial emulation package
** Extremely difficult setup
** Mac friendly


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


which will prompt you to enter a password (and confirm it).
See Also:


Note: you can also set a password on the root account by doing:
* [[Emulating_the_XO]] -- has a handy chart outlining which system has been reported to work with which type of emulation task


su root
== Emulation for Exploration ==
passwd


in the terminal window. This is strongly recommended if you are going to allow remote access to your machine.
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 ==
==== SSH Key Based ====


SSH Key based authentication provides strong public-key encrypted access control for your Sugar environment, but takes a bit more work than SSH Password base authentication.
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 [[Develop|IDE]] activity for altering and creating new code. That IDE is not yet finished, however.


In summary, you create a private key which will be stored on your remote system and encrypted with a strong password. You transfer the public key (think of it as a lock) that corresponds to that key to the Sugar environment and install it as an "authenticated key" which can be used to log into the Sugar environment.
''Official Images''


On your remote system, install SSH (Linux and MacOS will already have it installed, on Windows use the PuTTY program) and generate a new ssh key pair (following is for Linux/MacOS, refer to PuTTY's documentation for details on Windows):
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.


ssh-keygen
Developers wishing to use the [[Developers/Stack#EToys|EToys]] application stack can create new software from EToys built-in development environment while running on an emulator.


Usage notes:
''Developer's Desktops''


* Accept the defaults for key-type and size.
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.
* If ssh-keygen asks if you want to overwrite a key say '''No''', you are about to destroy your current ssh key!
* Use a strong pass-phrase that you can remember easily (the pass phrase will need to be entered frequently unless you make use of an ssh-agent such as offered by PuTTY or Gentoo's keychain)


This will normally create a file in your ~/.ssh/ directory named id_rsa.pub (if you accepted the defaults). You now need to copy this file to your Sugar environment and add it to the contents of your ~/.ssh/authorized_keys file (you may need to create the file).
See [[#Native Sugar]]


mkdir ~olpc/.ssh
=== Emulation for Compilation/Experiments ===
cat id_rsa.pub >> ~olpc/.ssh/authorized_keys


add your key to your keychain/ssh-agent application and you can now use SSH with just a single sign-on for many concurrent actions.
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.


== See Also ==
For example:


* [[Compiling C/C++ program for the OLPC]]
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).
* [[Building custom images]]

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.

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 [[Developers/FAQ|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) ==

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

* [[Qemu]] + KQemu (recommended where possible)
** [http://download.laptop.org/xo-1/os/official Official Releases] -- stable, official releases for wide consumption
** [http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2 Ship.2] -- patch releases for Official Releases
** [http://xs-dev.laptop.org/~cscott/olpc/streams/joyride Joyride] -- Bleeding Edge/Development Releases
* [[VMWare]], [[VirtualBox]] (good secondary choices, particularly if you already have one installed)
** [http://dev.laptop.org/virtualbox/ 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.

See Also:

[[Emulating the XO]] -- for setup and configuration issues, tips and hints

= 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 CD|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 [[Sugar_on_Fedora_7|Fedora 7]], and this is by far the best supported development platform for sugar-jhbuild. [[Sugar_on_Ubuntu_Linux|Ubuntu]] (Feisty or Gutsy) and [[Sugar_on_Gentoo_Linux|Gentoo]] can also build the environment.

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

You can [[Emulated Sugar-jhbuild|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:

* [[Sugar_on_Ubuntu_Linux#Option_3_-_Deb_Packages_for_Gutsy|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 [[Developers_Program#How_to_apply|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).

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:

* [[Developers/Stack#Browser|Browser]] -- Mozilla/Firefox-derived web browser
* [[Developers/Stack#EToys|EToys]] -- Squeak/Smalltalk multimedia environment
* [[Developers/Stack#OLPCGames|Pygame]] -- raster-graphics game development framework
* [[Developers/Stack#Flash|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)


[[Developers|Previous]] [[Developers/Stack|Next]]
[[Developers|Previous]] [[Developers/Stack|Next]]


[[Category:Emulation]] [[Category:Developers]]
[[Category:Developers]]

Latest revision as of 03:17, 12 May 2014

english | 한국어

  For Developers

Previous Next

The OLPC software environment is a combination of OLPC-tailored low-level system components (sharing as much with Fedora as possible), plus dual user-level platforms Sugar and GNOME.

Development of components of Sugar and GNOME (really anything that directly faces the user) happens within the regular upstream Sugar developer and GNOME developer communities. The content on this wiki relates to development of the lower level OLPC platform.

Recommended environment

OLPC OS releases are based on specific versions of Fedora. It is recommended that you install the matching version of Fedora on your development computer, matching the architecture (i686 or x86_64).

Although you will likely develop on your regular desktop computer, you will need an XO at your side for testing.

Communicating with your XO

SSH Access

You will often want to be able to use file-transfer and remote-login operations to access your Sugar environment. We generally recommend using ssh-based access for working with your Sugar environment remotely.

Password Based

Password-based SSH authentication is convenient and simple to set up, but it is far easier to crack than key-based access. Consider using key-based authentication unless you are absolutely sure that no-one can reach your Sugar environment from untrusted networks (and maybe even then).

Open a Terminal activity and run: 

 passwd

which will prompt you to enter a password (and confirm it).

Note: you can also set a password on the root account by doing: 

su root
passwd

in the terminal window. This is strongly recommended if you are going to allow remote access to your machine.

SSH Key Based

SSH Key based authentication provides strong public-key encrypted access control for your Sugar environment, but takes a bit more work than SSH Password base authentication.

In summary, you create a private key which will be stored on your remote system and encrypted with a strong password. You transfer the public key (think of it as a lock) that corresponds to that key to the Sugar environment and install it as an "authenticated key" which can be used to log into the Sugar environment.

On your remote system, install SSH (Linux and MacOS will already have it installed, on Windows use the PuTTY program) and generate a new ssh key pair (following is for Linux/MacOS, refer to PuTTY's documentation for details on Windows): 

 ssh-keygen

Usage notes:

  • Accept the defaults for key-type and size.
  • If ssh-keygen asks if you want to overwrite a key say No, you are about to destroy your current ssh key!
  • Use a strong pass-phrase that you can remember easily (the pass phrase will need to be entered frequently unless you make use of an ssh-agent such as offered by PuTTY or Gentoo's keychain)

This will normally create a file in your ~/.ssh/ directory named id_rsa.pub (if you accepted the defaults). You now need to copy this file to your Sugar environment and add it to the contents of your ~/.ssh/authorized_keys file (you may need to create the file). 

mkdir ~olpc/.ssh
cat id_rsa.pub >> ~olpc/.ssh/authorized_keys

add your key to your keychain/ssh-agent application and you can now use SSH with just a single sign-on for many concurrent actions.

See Also

Previous Next

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=Developers/Setup&oldid=295993"