Developers/Setup: Difference between revisions
Jump to navigation
Jump to search
(there is already a link to Fedora when the term is first introduced) |
|||
| (60 intermediate revisions by 19 users not shown) | |||
| Line 1: | Line 1: | ||
{{Translationlist | ko | origlang=en }} |
|||
{{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. |
|||
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 powerful hardware available and want to get started as fast as possible, choosing an emulated approach is probably for you. |
|||
=== SSH Access === |
|||
If you are running a reasonably powerful Linux, Windows or Mac OS X machine, you can likely use one of these tools to run an emulated image. 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 Packages/Products == |
|||
==== Password Based ==== |
|||
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: |
|||
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). |
|||
* [[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 everywhere, GUI available for Windows |
|||
** 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 available for Mac OS X |
|||
Open a [[Terminal]] activity and run: |
|||
Which emulation system you choose is mostly a matter of preference and suitability for your system. |
|||
passwd |
|||
== Emulation for Development == |
|||
which will prompt you to enter a password (and confirm it). |
|||
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. |
|||
Note: you can also set a password on the root account by doing: |
|||
''Official Images'' |
|||
su root |
|||
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. |
|||
passwd |
|||
in the terminal window. This is strongly recommended if you are going to allow remote access to your machine. |
|||
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. |
|||
==== SSH Key Based ==== |
|||
''Developer's Desktops'' |
|||
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. |
|||
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. |
|||
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. |
|||
See [[#Native Sugar]] |
|||
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): |
|||
=== Emulation for Compilation === |
|||
ssh-keygen |
|||
* Using an image (preferably with an overlay) to do binary compilation in a "throw-away" environment |
|||
Usage notes: |
|||
== Emulation for Testing == |
|||
* Accept the defaults for key-type and size. |
|||
Suitable for developers who want to develop on their host machine and then see the results in the emulator. Emulation tools often have the ability to share folders with the emulated machines, but simple scp, rsync or source-code-controls work as well. |
|||
* 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). |
|||
= Emulated OLPC-XO = |
|||
mkdir ~olpc/.ssh |
|||
The recommended platform for "checking out" the Sugar environment, testing activities and for initial development of new activities. By installing an emulation package on your (reasonably powerful) host desktop, you can run an emulated version of the Sugar environment which is essentially the same code as runs on the real laptops. |
|||
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. |
|||
An emulated XO does not provide tools such as SVG editors or Integrated Development Environments. You will normally run such software on your host machine and push the results onto the emulated machine. |
|||
== See Also == |
|||
The emulated XO has certain limitations with regard to the specialized hardware in the XO. See [[Developers/FAQ|the Developer's FAQ]] below for some pointers on how to simulate the special hardware. |
|||
* [[Compiling C/C++ program for the OLPC]] |
|||
= Native Sugar = |
|||
* [[Building custom images]] |
|||
[[Developers|Previous]] [[Developers/Stack|Next]] |
|||
== sugar-jhbuild == |
|||
[[Category:Developers]] |
|||
This is what the core development team uses and is one of the most pleasant ways to work. 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 better environment. If you are intending to work on the core system/activities you will likely need to use sugar-jhbuild to set up your environment. See [[Sugar with sugar-jhbuild]] to get going. The 'native' environment for sugar-jhbuild is Fedora 7 and Ubuntu (feisty or gutsy). |
|||
[[Emulated Sugar-jhbuild|This approach]] also works nicely under emulation ([[Qemu]], [[Parallels]], [[VirtualBox]] or [[VMWare]]) on Linux, Windows or Mac OS host operating systems. This allows you to work without rebooting even when using sugar-jhbuild, and without risk of corrupting your host operating system. |
|||
=== On 32-bit Linux === |
|||
To get a working [[Sugar with sugar-jhbuild|Sugar using jhbuild]] you will need to be running an OS that provides compatible versions of the various libraries that Sugar requires (basically a very up-to-date Linux platform). |
|||
As of 2007-12-13 the distributions known to be able to support sugar-jhbuild are: |
|||
* [[Sugar_on_Fedora_7|Fedora 7]] |
|||
* [[Sugar_on_Ubuntu_Linux|Ubuntu Feisty Fawn (or Greater)]]. |
|||
* [[Sugar_on_Gentoo_Linux|Gentoo]] (with a trivial work-around) |
|||
At the moment, a Fedora 7 install with sugar-jhbuild is probably the most "sure" approach to getting a working full-speed (non-emulated) working environment for developing on Sugar with the latest libraries and solid upgrade path. As most of the core developers are working on Fedora boxes with sugar-jhbuild it is the most likely environment to be supported and continue to receive support. |
|||
=== On 64-bit Linux === |
|||
As of 2007-12-13 it is possible to build Sugar on 64-bit Linux with trivial workarounds/fixes. This has been confirmed on Gentoo amd64 and Debian Lenny (with the caveats below). |
|||
Sugar seems to be working on Debian Lenny (2007-11-05), though Python 2.5, even when installed, is not detected. Comment out the line '''jhbuild.commands.run('sanitycheck', config, [])''', line 95, to get it to install. |
|||
== 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 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). |
|||
== Live CDs == |
|||
The Live CDs allow you to convert a "regular" machine into a Sugar-running machine without touching the hard disk of the machine. This allows you to play with and test how the software runs with your hardware. It also lets you demonstrate and test your software at full speed. |
|||
= Cross Coding = |
|||
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 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 = |
|||
* [[Emulating the XO]] |
|||
[[Developers|Previous]] [[Developers/Stack|Next]] |
|||
Latest revision as of 03:17, 12 May 2014
For Developers
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.