このページは、OLPCチームによってチェックされています。
- This is an on-going translation
OLPC開発者向けプログラム
開発者プログラムに参加するための手順についてはここをご覧下さい.
あなたがしようとしていることの多くはエミュレータを使って行うことができる場合が多いです。
- あなたのシステム用にエミュレータをダウンロードし走らせるにはエミュレーションのためのOSイメージをご覧下さい。エミュレーションには、QEMU, Paralles, そしてVMWareなどの様々な選択肢があります。
- 個別のアクティビティやライブラリコレクションもダウンロードすることができます。
- ソースコードの保管場所とバグトラッキングシステムはここにあります。
上記の補足情報として、該当のリリース関連情報としてハードウェア・ソフトウェア・ライブラリリリースノートをご覧下さい。
Instructions for applying to the developers program can be found here.
It may well be the case that you can do much of your work by using an emulator:
- To download and run an emulation of our system, see OS images for emulation. There are several emulation options: QEMU; Parallels; and VMWare.
- Individual activities or library collections can also be downloaded.
- A source code repository and a bug-tracking system are found here.
For help with the above, please see the hardware, software, and library release notes for the appropriate release.
概要と心の準備
OLPCシステムは、おおよそ5年程前の一般的なラップトップと比べ際立った相違点があります。すなわち、私たちがベースとしているシステムソフトウェアは以前よりもより多くのことができるようになりました。Linux環境は今では以前は手の届かなかったスクリプトの国際化に対応しており、遥かに高品質なレンダリングと、そして何よりもアプリケーションの選択肢が大きく広がりました。
しかしながら代償もあります。「ムーアの法則」はメモリやCPUの利用において私たちを無頓着にしてしまいました。この状況は利用可能なソフトウェアの「フットプリント(サイズと必要リソース)」に対し難しい選択を迫ることになりました。OLPCラップトップは内蔵ストレージとして512MB(のフラッシュメモリ)しかありません。そしておそらくもっと深刻な制約として128MBしかないRAMとシングルコアプロセッサであることが挙げられます。過去1年以上にわたり、これらの問題に対してOLPCコミュニティはより神経質になってきました。そして作業はこの「膨れ上がる」サイズと全般的な処理効率改善にむけ順調に推移しています。小さいことは良いことです(もちろん速いことも!)。
私たちが基盤とする技術の選択は、ソフトウェアの能力において、見渡す限り世界的な規模での「ユーザの使用感」において最も優れたものを達成すると予測されてきました。この思いは私たちにGTK+とPango(そしてグラフィカルユーザインタフェースの基盤としてCairoも含め)を選択させるに至りました。なぜならば、複雑なスクリプト群におけるPangoの処理能力は現在ではフリーソフトウェア技術の中で最も進んだものだからです。もちろんその他のツールキット群も利用可能ですが、特に今日私たちが直面しているローカライズが必要なスクリプト(それらにはタイ語とアラビア語が含まれます)に対し、それらを基盤としたソフトウェア能力ではメモリとフラッシュのサイズに対する代償が大きいのです。従って、私たちのベースシステムの標準的部分にその他のツールキットを含めることは問題を抱えることになり、そして内蔵システムにおける利用感は、複数のツールキットを含めることが、恐らく間違いなく全体的な利用感を損ねることになりかねないということを示しています。
There is a major difference between the OLPC system and a conventional laptop of
approximately five years ago; that is, our base system software is much more capable than it was then. The Linux environment now supports internationalization capability for scripts that were out of our reach then, and much higher quality rendering and, best of all, a much wider range of applications.
This has come somewhat at a cost, however: Moore's "Law" has allowed us to become sloppy, both in memory usage and CPU usage; this tends to force us to make some tough choices to keep the "footprint" of the software acceptable. The OLPC laptop have only 512 MB of storage (Flash), and probably the most serious limitation, 128 MB of RAM, and a single-core processor. Over the last year or so, the community has become much more sensitive to these issues, and work is well underway toward reigning in this "bloat" and performance work in general. Small is beautiful (and usually faster!).
Our base technology choices have been predicated on the ability of the software to achieve the best overall worldwide "user experience". This drove our choice of GTK+ and Pango (with Cairo as the graphical underpinnings), since Pango's abilities in complex scripts are currently most advanced of free software technologies. Other toolkits can be used: but they come at a cost in memory and flash footprint, and today, in the ability of software based on them to be localized to many of the scripts we face immediately, which include both Thai and Arabic. Including other toolkits as a standard part of our base system is therefore problematic, and experience on embedded systems show that including multiple toolkits would almost certainly cause the overall experience to suffer.
BTestシステム
私たちは"BTest"のために、(3つのビルドの)2つの完全なOLPCラップトップ完成筐体のビルドを作ってきました。
一般的に外部ベータテストの前に内部的に1つないしは2つのビルドを用意します。そして私たちのBTest-1は電気回路の真のベータテストであり、一方アルファテストは新しいスクリーン、タッチパッド、工業デザイン、そしてキーボードのテスト用でした。このプロセスは開発サイクルにおいて通常利用可能になるペースに比べより早いものです。そしてそれに応じて、少々荒いものでもあります。
BTest-2ハードウェアは電気回路、新しいスクリーン(今回はディフューザーがスクリーンをより改善しています)、そしてタッチパッドのためのベータテストを継続中です。工業デザインに関してはBTest-1に比べほんの少しだけ改善されています。すなわちBTest-1より得られた機構的改善における要改善点はBTest-2では今回は盛り込まれていません。そしてBTest-3ではBTest-1やBTest-2よりも著しく耐環境性に関して向上する見込みです。
BTest-1マシーンの開発者プログラムにおける注目点はシステムにおけるスクリーン、タッチパッド、そして/あるいはカメラの使い勝手を知るためのGUIに関係したプロジェクトにおけるソフト開発です。このようなテストはベアPCボードではすぐに確認するにはなかなかやっかいな項目でした。
BTest-2の注目点は、メッシュネットワークのテストプロセスを開始することであり、(準備作業は完了はしましたが、これを書いている現時点ではサスペンド・リジューム機能はまだ動作していないのですが)このサスペンド/リジューム機能についても作業を実施しています。
マシンはまたプロジェクト最初の対象国へ割り当てられる予定ですが、個人のフリーでオープンソースのデベロッパーや、OLPCの目標を拡大することへの貢献に興味を持っている研究組織を狙っていないため、このプログラム下の活動には割り当てられません。
We have had the two builds (of three builds) of full OLPC laptops built, for "BTest".
There is typically one or two builds of systems internally before an external beta test, so our BTest-1 is really beta test for the electronics, while alpha test for the new screen, touch pad, industrial design, and keyboard; this is earlier in the development cycle than systems are usually made available, and is correspondingly rougher.
The BTest-2 hardware is continuing beta test for the electronics, beta test of the new screen (this time with a diffuser improving it futher) and touch pad. The industrial design is only somewhat improved from BTest-1; most of the learning from BTest-1 on mechanical improvements could not be incorporated in time for BTest-2 and so BTest-3 will be significantly more rugged than BTest-1 or BTest-2.
The focus for the developer program BTest-1 machines will be software development on GUI related projects that need to understand the screen, the touch pad, and/or the camera in the system, along with wireless testing, which has been difficult to do sooner due to the cumbersome nature of bare PC boards.
BTest-2's focus will start the process of testing the mesh network, and we are also working on suspend/resume, though as of this writing, suspend/resume is not yet running, though the preparatory work is now complete.
Machine are also being allocated to launch countries and do not come under this program, which is aimed at individual free and open-source developers or research organizations interested in contributing to furthering OLPC's goals.
BTestユーザに対しOLPCが期待すること
リリースノートをお読みください!
BTest-1ビルドは配布が完了しています。BTest-1リリースノートにこのマシーンの位置づけが述べられています。
BTest-2ビルドは(2007年)2月12日に配布が開始されます。BTest-2リリースノートにこのマシーンの位置づけが述べられています。BTest-4ビルドは6月下旬に完成しました。そしてこれらの改善されたシステムの配布が始まっています。まず最初に開発者、そしてTraial-2ソフトウェアの準備ができ次第、その後の評価のために配布される予定です。
ソフトウェアはBTest-1, BTest-2,そしてATestボードで走る予定です。詳しくはOLPCソフトウェアリリースノートをご覧下さい。
The BTest-1 build has been distributed: the BTest-1 Release Notes describes the state of the first build of machines.
The BTest-2 build is starting distribution as of February 12. The BTest-2 Release Notes describes the state of the second build of machines. The BTest-4 build completed in late June, and distribution
of these improved systems has begun, first to developers, and when the Trial-2 software is ready, they will be distributed for later trials.
The software will run on BTest-1, BTest-2 and the ATest boards; please read the OLPC Software Release Notes.
バグのレポート方法
私たちのプロセスは完全にオープンなものであることにご注意下さい。商品の「一般の」ベータテストプログラムでは、秘密保持契約への署名を求められ、そしてあなたが直面したいかなる問題、あるいはあなた以外のベータテスターが経験したであろう問題に気が付いたとしても、それらについて秘密厳守を求められてきたことと思います。普通、このようなハードウェアベータテストは、ここで行われてきたものよりもより厳密なテストが完了した後に行われるものです。
初期ベータテストハードウェアとはその後のベータテストや製品ハードウェアに比べハードウェア障害発生の確率が格段に高いことを意味します。また設計に関してはその他様々なテスト項目と共に温度上昇、寒冷地、振動、衝撃、そして湿度といった負荷試験が進行中のものです。
机上では構成が良くとも、コンポーネント自身の設計上の欠陥やその利用方法の両方に置いて実際にはうまく動かないかもしれません。ベータテストはまた異なる製造者のコンポーネントに対して用いられるものです。より多くの製品個数が利用可能な場合は常に、コンポーネントは"複数の製造メーカから調達され",そして異なる製造メーカからの同種の部分についてコンパチビリティテストが実施されます。これは製造開始後特定の製造メーカに問題が発覚しても代替メーカが利用可能であるかどうかという安定供給を確認するためです。私たちのハードウェアに関して2, 3の例を挙げるならば、例えば、カメラ供給メーカ、RAM供給メーカ、PCB供給メーカといったものです。例えば、ATestボードにおいては、私たちは製造に置いて利用したくないいくつかのコンポーネントを見つけました。そして私たちはBTestを通して同様な問題に遭遇する可能性があります。コンポーネントの設計は新しいかもしれません。そしてそれ自身に依存した設計があるかもしれませんし、製造メーカが解決すべき問題があるかもしれません。(例えばライティングパッドにおける下記に記す問題のように。)組み立て時に問題が作りこまれる可能性もあります。問題は設計にあるいはコンポーネントの選択にもありえます。コンポーネントの特定ロットに欠陥があるかもしれません。ベータテストの目的は、特に大量生産される製品について、大量生産を開始するかなり前の段階でこのような種々の問題を見つけ出し、欠陥を完全に解析し、そして、個々の欠陥について直接的原因を理解することで製品ユニットにおいてこれらの問題を排除・防御することにあります。もしあながたハードウェアの問題に直面したら、OLPCは障害解析のために直ちにマシンの返却を求めるでしょう。私たちは代替マシンを大至急あなたに届けるべく最大限の努力をします。
私たちはあなたがバグ追跡システムに新しいハードウェア・ソフトウェアの問題について直ちに書き込むことを期待しています。それによって問題は追跡され解決されます。その際にはあなたが使っているファームウェアバージョン(ファームウェアバージョンは電源投入時の表示２行目に表示されます。例えば "OpenFirmware CL1 QA62 Q2A"という表示ならば、QA64がファームウェアバージョンです)、オペレーティングシステムビルドナンバー(ブートプロセスの最後に表示されます)、そしてあなたのマシンのシリアル番号(バッテリーの下に表示してあります)を含めてください。この情報が、私たちが問題を解析し解決することに役立ちます。
同じバグの入力は避けられないとは思いますが、同様な問題がすでに報告されていないかどうかまず検索をしていただけると非常に助かります。あなたが問題に遭遇したり、あるいはどれくらいの頻度で発生するかを私たちが知らなければ問題の解決しようがありません。すなわち、明らかに、ある別の問題と同じ問題に遭遇したならば、どのくらい頻繁にそれが発生するのか、あるいはあなたが気が付いたその他追加情報を知ることが非常に役立ちます。なるべく少なく、ではなくなるべく多く問題についてレポートするようにしてください。バグについてのレポートやコメントの中からあるパターンが浮かび上がってくるかもしれません。あるいは問題がどれだけ深刻であるかについてより良い新しいアイデアが生まれるかもしれませんし、その解決のためによりよい優先順位付けをすることが可能かも知れません。バグとは良いものなのです。個々のバグは後になって修正するよりも、直ちに直すほうがより簡単です。
Note that our process is a fully open one: in a "conventional" beta test program for a product, you would have been asked to sign a non-disclosure agreement, and not disclose any of the problems you might have, or even be aware of problems other beta testers might be having. Usually, such a hardware beta test is done later in the program after more extensive testing has been done than has been done here.
The early beta test hardware means a much higher probability of hardware problems than later beta test or production hardware. The design is undergoing stress testing at elevated temperature, cold, vibration, shock, and humidity as well as many other tests.
Components that are fine on paper, may not work well in practice, either by defects in the design of the components or in their use. Beta testing is also used to test different manufacturer's components. Whenever possible in high volume products, components are "multiple-sourced", and the same nominal kind of part from different manufacturers tested for compatibility. This is to ensure steady supply, even if a particular manufacturer later starts having manufacturing problems, alternatives will be available. Examples in our hardware include camera supplier, RAM supplier, PCB supplier, to name just a few. On the ATest boards, for example, we discovered several components that we do not want to use in production, and we can expect similar issues during BTest. A component's design may be new, and have its own design or manufacturing problems to be resolved (e.g. the writing pad problem we note below). Errors can be made in assembly. Errors can be made in design or component selection. A particular lot of components may be defective. The purpose of beta test, particularly for a high volume product, is to discover these problems, long before volume production, analyze the failures completely, and, by understanding the root cause of each failure, be able to eliminate or prevent these problems in the production units. If you have a hardware problem, OLPC may ask you to return the machine quickly for failure analysis; we will do our best to get you a replacement promptly.
We expect that you will quickly enter new hardware and software problems you encounter into our bug tracking system, so that the problems can be tracked and resolved. Please include the firmware version you are using -- displayed at power on time on the second line: e.g. "OpenFirmware CL1 QA62 Q2A"; the QA62 is the firmware version--the operating system build number--which is displayed at the end of the boot process--and the serial number of your machine--found under the battery; this will help us analyze your problem and resolve it.
While duplicate bug entries are inevitable, searching to see if the problem has already been reported will be very helpful to us. Problems cannot be fixed if we don't know what you encounter, or how often they are encountered; if you find clearly the same problem as some one else, it is still helpful to know how often it is occurring, or any additional details you know. Add such information to the bug reports. Err by too much reporting, rather than too little. A pattern may emerge among the reports or comments on a bug, or we may have a much better idea how severe a problem is and be able to better prioritize its resolution. Bugs are good. Each bug is much easier to fix now than later.
ハードウェア
ハードウェアについてのユーザガイド
あなたは「普通の」商用製品を使用する機会を得るであろう随分と前に、テストの間システムを使っていることと思います。これはハードウェアとソフトウェア両方のテストをスタートするためです。何故ならば私たちのシステムは一般的なラップトップ(例えばスクリーンだとか、電源管理だとか、耐環境性といったもの)に比べ著しく異なり、また大変異なる環境で利用されるであろうからです。あなたはコンピュータシステム製造メーカがあなたから隠してきた「カーテンの後ろの真実」を(あるいは部分的にでも)知ることになるでしょう。良いこと、悪いこと、そしてハードウェアとソフトウェアデバッグの醜いプロセスを、です。
右の写真はこのマシンの特徴の殆どを記しています。マシンを開くために、まず最初にアンテナのラッチを外し、持ち上げて開きます。
電子ブックモードに変更するためにスクリーンを回すためには、スクリーンを少なくとも90度開いた状態にしなければなりません。スクリーンはキーボードの上に閉じる方向へ、単方向、もしくは両方向にまわすことができます。
バッテリーパックはキーボードの下のスクリーンの下に位置しています。取り外すときは下のサムネイルに示すように２つのスライドラッチをリリースします。同じ写真にSDスロットをはっきりと確認することができるでしょう。ノート：後期のビルドではマシンの表面がピカピカしないようプラスチックに表面加工がなされる予定です。
You are using a system during test, well before when you would have the opportunity to use a "normal" commercial product. This is to allow both hardware and software testing to start, since our system is significantly different than conventional laptops (e.g. the screen, power management, ruggedness), and will be used in very different environments. You will see "behind the curtain" (and be part of) the process that computer system manufacturers hide from you: the good, the bad, and the ugly process of hardware and software debug.
The picture on the right locates most of the features of the machine. To open the machine you must first unlatch the antennae and then lift it open.
To rotate the screen to transform to ebook mode, the screen must be in the 90% upright position. It can only rotate one of two directions to the point where the screen can again be closed down over the keyboard.
The battery pack is located under the screen underneath the keyboard, and is released by two slide latches as seen in the lower thumbnail. You can also see the SD slot clearly. Note: the plastic will be textured in later builds so the surface of the machine will not be shiny.
BTestマシンで心しておくこと
BTest-1リリースノートあるいはBTest-2リリースノートとBTest-1 Demo Notes|BTest-1デモノートをよく読んでおいて下さい。
もしあなたがBTestマシーンを入手したならば、以下のものが同梱されているはずです。
- 1台もしくは2台のBTestシステム(利用可能な場合はローカライズされたキーボード)
- (私たちの物流部門と占いが許す範囲で)個々のマシン用に、利用可能な場合はあなたの国の正しいプラグタイプを有するAC電源アダプタが一つ。
- 個々のマシン用にバッテリーをひとつずつ。
- 工場かOLPCにて事前組み込みなされたあるバージョンのソフトウェア:到着後直ちにソフトウェアの更新をするつもりでいてください。更新作業はAutoreinstallation imageによって非常に簡単にできるようになりました。
Please carefully read the BTest-1 Release Notes or BTest-2 Release Notes and the BTest-1 Demo Notes.
If you get a BTest machine(s), expect to get (a) box(s) with:
- one or more BTest systems, with localized keyboards if available
- one AC power adapter for each machine (to the extent possible by our logistics and crystal ball gazing) which will have the right plug type for your country if available
- one battery pack for each machine
- factory or OLPC pre-load of some version of the software: you should plan to immediately update the software to a current version upon arrival. This has been made extremely easy with the Autoreinstallation image.
プロジェクトにおける情報交換の場所
最初にあなたが興味を持つのが、システムレベルやアプリケーションレベルでのコーディングなら、私たちのHosting Wiki中の一つのプロジェクトに参加してください。
SourceForgeといった代替手段よりも私たちは遥かに柔軟性に富んでいて、回線容量もCPUも利用できます。そしてOLPCに関係ないその他の数千ものプロジェクトに埋もれてしまうこともありません。もしあなたのプロジェクトがOLPCと関係のある観点を有するならば、限られたOLPC関連の設備を喜んで提供しましょう。それは例えばバグトラッキングとか私たちのwikiとかといったものです。
If your interest is primarily on doing some systems level or on applications level coding, then join one of the projects on our Hosting Wiki.
We have much more flexibility, bandwidth and CPU available than alternatives like
SourceForge, and your project won't be as lost among thousands of other projects unrelated to OLPC. If your project has aspects related to OLPC, but is primarily
part of some other project (e.g. GTK+, X11), we're also happy to provide more limited OLPC
related facilities, such as bug tracking and our wiki.
ハードウェアスケジュール
私たちがATestボードと呼ぶ、この最初の世代のボードでは、ハードウェアはBTestシステムに見られるようなDCONチップによって動作するフラットパネルを利用するのではなく、映像信号がVGA出力に出力されることを覗けば機能的に完全なものです。
パッケージされたBTest-1マシーンは昨年(2006年)11月下旬にビルドされました。BTest-1マシンはNANDフラッシュ、カメラ、そしてSDインタフェースのために後期ビルドでは存在するCaFE ASICのところにAltera FPGAが使われていることを除けば、完全に機能するものです。このFPGAはCaFE ASICの動作に比べ、処理能力が低く、より多くの電力を消費します。もう一つのビルド(BTest-2)は完成したCaFE ASICを使い、(2007年の)1月下旬に作られました。より多くの台数が作られた、３番目のBTest-3ビルドは(2007年)5月に作られました。BTest-2システムは最も初期のトライアルで利用されました。
BTest-4は(2007年)6月下旬にビルドされました。これは開発者向けの初めての現在配布中のモデルです。そして一旦トライアル-2のソフトウェアが準備できれば、その後のトライアルにも配布される予定です。
In this first generation of boards, which we call A-Test boards, the hardware is fully functional except that video is VGA out, rather than using a flat panel with the DCON chip which appears in the BTest systems.
Packaged BTest-1 machines were built in late November. The BTest-1 systems are fully functional, but use an Altera FPGA in place of the CaFE ASIC which is present in later builds, for NAND flash, camera, and SD interfaces. This FPGA has lower performance and consumes much more power than the CaFE ASIC does. Another build (BTest-2) occurred in late January using the completed CaFE ASIC. The third BTest-3 build, in larger quantities, occurred in May. BTest-2 systems were used in the earliest trials.
BTest-4 was built in late June, is undergoing distribution first to developers, and once the Trial-2
software is ready, will be distributed to later trials.
目標
私たちの目標はハードウェアの成熟と共に変わってきます。BTestシステムに対して私たちが最も望むのは下記の点です。
- デバイスドライバにおける電源管理：私たちにとって、あらゆる熱量関連問題、そして単純な「よしよし、殆どのチップはだいたい電源がオフになっているな」といった程度では全くもって十分ではありません。私たちはあらゆる可能な電源節約の方法が実現されているということ、そしてサスペンド/リジュームが完璧でとてつもなく早いかということが知りたいのです。
- すばやいサスペンド/リジューム:power management summitで議論されている最新の技術の更に遥か先を目指します。
- モーダルオペレーション:もしあるアプリケーションがフルスクリーンだったとき、システムはいつでもシステムがほんの一瞬でもアイドルになったとき自動的にサスペンドしそしてリジュームする必要があります。
- 可変速度ディスプレイ駆動:(俗にモードチェンジ・オンザフライと呼ばれるものです)、この機能も改めて電源を節約するためです。
- 無線ネットワーク:私たちはメッシュネットワークを配備する予定です。この領域における非常に重要な実験は、ドライバのブラッシュアップと異なる環境でのその振る舞いについての知見を得ることです。(例えば、低ノイズ特性の田舎の地域とか慌しい都会の地域とか)私たちは厳密なテストを行うためには1つ以上のボードが必要であると理解しています。どうぞ現実的なことを期待してください。2つのボードでは面白く無いでしょう。しかし200枚のボードは提供不可能です。
- コンパイラの最適化:もしあなたがコンパイラに精通しているなら、処理能力、特に浮動小数点演算の処理能力を制限するための特殊なバックエンドスケジューラがGeodeには無いことが分かっています。なので、この領域における作業を是非進めたいと考えています。そうすれば皆が助かります。
- チックレスオペレーション: じきLinuxに組み込まれる、Linuxを周期的なチックなしに機能させるような開発計画ツリーに含まれていないパッチがあります。引き続き実験を続けていますが、私たちのチックレートはおそらくLinuxシステムの中でも今までになかったほど最も低いものではありますが、さらに改善できるし、するべきだと考えています。システム中のどの部分もポーリングしてはいけません!
デスクトップで監視する電源管理:BTestマシーンの電力消費と電力要求を更に細かく監視し、これら情報をうまくやりとりするのに必要なアプリケーション
- OOM(out of memory)防止対策についてはまだあまり検討がなされてません、というか全くなされてません。
- Sugerの最適化:再ビルドしたPython2.5が配備されればSugerの実行環境はかなり早くなるはずですが、Pythonの起動時間について特に、更なる作業をこなしていく予定です。
- アプリケーションのSuger対応: 幼い子供たちのためにSuger環境でもっとうまく動作するようにするよう、最低限の作業しかなされていない多くのアプリケーションがあります。それらを取り上げて対応作業の援助を要請します。
- 外部ディスプレイ: 安いプロジェクタについての作業を始めています。アプリケーションが簡単に遠隔動作するようにする作業はとても意味のあることです。これを実現するためには多くの方法(と難しさ)があります。なのであなたの嗜好と能力次第で、先進的な「X Window System的最新技術」によるより洗練された方法とともに、付け焼刃的なやり方もとれます。
- あらゆる種類の教育向けアプリケーション
- 各スクールサーバとラップトップのサポートのためのサーバベースのツール類
私たちよりもあなたの方がきっと聡明で、上記リストで私たちが何を見逃しているかきっとすでにお気づきのことと思います。
あなたはハードウェアを必要としない多くの領域で貢献できます。例えば：
- メモリ利用効率: 多くのアプリケーションとツールキットがメモリを消費しメモリーリークを起こします。これらの問題を修正することは全ての人を助けることになるし、殆どが通常のシステムで作業できることです。
- 処理能力の最適化: メモリ利用効率の修正は一般により早いコードにつながります。
- ツールキットの適応: ディスプレイ有効解像度はグレイスケールとカラーの間で切り替わります。ツールキットとアプリケーションはそれに対応せねばなりませんし、デスクトップテーマも両方のモードでうまく動作するか確認されねばなりません。
- ユーザインタフェース:殆どのユーザインタフェースに関する作業は今のところ通常のデスクトップのLinuxにて実施可能です。しかしながら私たちのシステムは2つの4方向キーとエンターキーで操作できる電子ブックモードを有しています。キー入力処理アプリケーションはこの環境でうまく動作するよう更新されねばなりません。(例えばevinceやwebブラウザなど) グレイスケールモードでのアプリケーション類のテストと、それにもとづくどのような修正も非常に助かります。
- アプリケーション: これについては言うまでも無いでしょう。開発の進んでいる"Suger"環境は一般のデスクトップで動作させられます。また多くのアプリケーションはこのシステム向けに単純化され最適化される必要があります。私たちの最初のユーザは、これまで一般的にコンピュータを使う最初の子供たちであった中学生や高校生ではなく、幼い子供たちなのです。
- IPv6のサポートとサービス検出。これらは私たちのプロジェクトにとって非常に重要です。
- セキュリティ:SELinuxやその他の技術がゼロディ攻撃に対する一つの方法かもしれません。同様なマシン群からなる巨大なエコシステムにとって、この問題は真剣に検討するに値する問題であるといえます。
これらの解決を進展させるためにOLPCハードウェアへアクセスを必要とする諸提案のためにハードウェアの初期設定を公開する予定です。BTestの要求項目はシステムの移動運用を必要とするべきだし、新しいスクリーンへアクセスするGUIとアプリケーションに重点的に実施される必要があります。
Our goals will vary as the hardware matures. For the BTest systems we need the most help on:
- power management in the device drivers: for us, every joule matters, and a simplistic "oh, we mostly have most of a chip turned off, maybe" isn't good enough. We want to know that every possible power savings has been realized, and that suspend/resume is rock solid and blindingly fast.
- fast suspend/resume: We must go beyond the current state of the art as discussed at the power management summit.
- modal operation: if certain applications are full screen, the system should automatically suspend and resume whenver idle for more than a short period.
- variable speed display driving: (aka: mode change on the fly), again, to save power.
- wireless: we will be deploying mesh networking. Serious experimentation in this area is in order, to shake down the drivers and to gain experience in its behavior in differing conditions (e.g. rural areas with low noise characteristics; busy metropolitan areas). We understand that to do serious tests, more than a single board will be needed. Please be realistic in your expectations: two boards is not interesting; two hundred boards can't be provided.
- compiler optimization: if you are a compiler wizard, we understand that the Geode lacks a specific back end code scheduler, which limits performance, particularly FP performance. We'd love to see work go on in this area which would help everyone.
- tickless operation: there are patches out of tree about to be integrated into Linux that allows Linux to function without periodic tics; we've been experimenting, and while our tick rate is probably the lowest yet observed on a Linux system, it can and should go further. Nothing in the system should poll!
- power management desktop interaction: applications need to be better aware of their power usage and requirements, and communicate this better to the system.
- The OOM (out of memory) killer is naive, to say the least.
- Sugar optimization: While the Sugar environment will get substantially faster as soon as we deploy a rebuilt Python 2.5, further work, particularly on python startup, is in order.
- Sugarizing applications: There are many applications that with minimal work can be made to work well in the Sugar environment for young children. We encourage you to pick one and help out.
- Remote display: we have begun work on a low cost projector. Making it easy to remote applications is well worthwhile. There are a number of ways (and difficulties) of doing this, so there are immediate techniques available, along with much more sophisticated ways of advancing the "state of the X Window System art", depending on your inclinations and abilities.
- Educational applications of all sorts.
- Server based tools for schools and support of the laptops.
We're sure you are brighter than we are and have seen what we're missing in the above list.
You can contribute in many areas which do not require hardware. For example:
- memory usage: many applications and toolkits waste and/or leak memory. Fixing these will help everyone and most easily done on conventional systems.
- performance optimization: fixing memory usage will usually result in faster code.
- toolkit adaptation: the display's effective resolution will change from grayscale to color mode and back. Toolkits and applications need to be able to adapt, and themes that work well in both modes verified.
- UI: most of the user interface work can be done today on conventional Linux desktops. But our system will also have an e-book mode, with dual 4-direction keys and enter. Key applications will need updating to work well in this environment (e.g. evince, web browser). Testing application's behavior under grayscale conditions and making whatever changes are needed would be helpful.
- Applications: goes without saying. The "Sugar" environment under development can be run on conventional desktops, and many applications should be simplified and optimized for our systems. Our primary audience are younger children, rather than the middle and high school students that have been the primary child users of computers.
- IPv6 support, and service discovery, which are very important to us.
- Security: SELinux or other techniques may be a way to protect against Day 0 attacks; as a large ecosystem of similar machines, it is something worth seriously worrying about.
We will give preference for hardware to proposals that require access to the OLPC hardware to make progress; BTest requests should either require mobile use of the systems and focused on GUI and applications where access to our new screen is needed.
必要資格など
私たちは開発を助けることができ、興味を持っている人たちを探しています。必要とされる資格はあなたがどの分野で働きたいかに強く依存しています。例えば、BIOS/bootパスで働きたい人は「電子の友達」といえるほどのスキルが必要で、JTAGや同種のデバッグ作業は恐れるに足らずと言える人です。
殆どのドライバ作業は、電力節約を正しく処理するという点では殆どのドライバに比べかなりチャレンジングではありますが、それ以外は通常のドライバデバッギングスキルがあればよいでしょう。
ウィンドウシステム開発はXでの開発経験などなどが必要ですし、アプリケーションについては同種のアプリケーションの開発経験が必要です。などなど。
We're looking for people able and interested in helping in development. The qualifications needed depend strongly upon where you are interested in working: for example, people working on BIOS/boot paths should be seriously "friends of the electrons", and not scared of JTAG and similar kinds of debugging.
Most driver work takes normal driver debugging skills, though getting power management right can be more challenging than most driver development.
Window system development requires X experience, and so on; applications, experience in developing those or similar applications, and so on.
支援の方法
dev.laptop.org
OLPCはソフトウェアとコンテンツ開発プロジェクトのために開発環境を走らせています。私たちはあなたの開発を大元のプロジェクトの上流でできるかぎりたくさん実施することを勧めます。しかしながら、あるプロジェクトはOLPCに特化されていたり、あるいは私たちのシステムに位置づけられるまでの間一時的な開発リソースを必要とします。例えばLinux kernel treeでは、私たちはメインのLinuxカーネルの一部として組み込まれる準備ができるまでOLPCのコードを管理しています。これによって上流でのコードの発行の手段も残してライナスのツリーをリーズナブルな近さでトラッキングしつつ、Linuxカーネルの様々な観点における作業を共有することが簡単になっています。
私たちはOLPCに関係したニーズを伴うこのような作業のために喜んでこのシステム上でホスティングしているリソースを提供します。
{{{1}}}
ソースコード管理システム
カーネルとX Windowシステムは共にgitをそれらの開発ソースコード管理システムとして使います。私たちはgitとSCMの両方で作業をしていますが、SCMが私たちの選択です。このあたりの議論はgit trees hosted at dev.laptop.orgをご覧下さい。
Fedoraカーネルがそのプロジェクトでは管理維持されています。BTest-1のためにFedoraのカーネルではなく、olpc-2.6ツリーからのカーネルを利用しています。これは将来的にある時点で変更されるかもしれません。
殆どのOLPCに特化されたバージョンのコードのソースはまたRedHatより入手可能です。
Since both the kernel and the X Window System use git as their development source code management systems, and we work on both, git is our SCM of choice. You can see the git trees hosted at dev.laptop.org.
The Fedora kernel is maintained at that project. For BTest-1 we are using a kernel from the olpc-2.6 tree, rather than a Fedora kernel. This may change at some future date.
Source RPMs for most OLPC-specific versions of code are also available from RedHat.
バグ追跡システム
OLPCはtracと呼ばれるバグ追跡システムを利用しています。これはwikiでもあります。(私たちはこのシステムのwiki的使い方には失望してますが)これを使うためには、あなた自身のアカウントを作成する必要があります。公開(非公開)バグについてこのシステムで検索することができます。
OLPC maintains a bug tracking system called trac, which is also a wiki (though we discourage use of it as a wiki). To use it, you need to create an account for yourself. You can query it for open (or closed) bugs.
ウィキ(wiki)
メインの公式OLPCウィキがプロジェクトに関する様々なアイデアや取り組みを書き込むために、あるいはラップトップのためのコンテンツをカテゴリ分けし、開発を進めるために利用可能です。あるページはOLPCコアチームによって管理されています。(それらページは目立つようにマークしてあります)私たちはTracのウィキよりもこちらのウィキの方を好んで使っています。
The main public OLPC wiki is available for use to write about any ideas or efforts related to the project; or to categorize and develop content for the laptops. Some pages (prominently marked) are maintained by the core OLPC team. We prefer this wiki to the Trac wiki for most writing.
重要な技術に関連する組織へのリンク
OLPCは、下記のリストで示されるものを含む多くのキー技術とプロジェクトに依存しています。
OLPC depends on a number of key technologies and projects, including:
お問い合わせ
Mail
e-mailについてのお問い合わせは問い合わせ先一覧をご覧下さい。
郵便による送付については下記まで:
- One Laptop per Child
- P.O. Box 425087
- Cambridge, MA 02142
- USA
For e-mail contacts, see Contact OLPC.
Snail mail please sent to:
- One Laptop per Child
- P.O. Box 425087
- Cambridge, MA 02142
- USA
IRC Chat
私たちは主にIRCインスタントメッセージングを利用しており、irc.freenode.netのチャネル#OLPCと#sugarにいます。
We primarily use IRC instant messaging, and can be found on irc.freenode.net, #OLPC and #sugar channels.
ソフトウェアのインストール
ハードウェアを受け取った方は
ノート：最初にシステムを受け取ったら、以下のNANDフラッシュとBIOSの再インストール手順に説明してある手順に従い、システムを現在のソフトウェアにすみやかにアップデートしてください。
BIOS(LinuxBIOS + ブートローダのOpenFirmware), Linux自身, そしてOLPCソフトウェアスタックはBTestシステムに工場出荷時にインストールされています。しかしながらこれはシステムテストと実環境での利用というよりは後で確認することを意図したものです。私たちがQuantaに製造のためにマシンを引き渡してからあなたが受け取るまでの間、多くの重要なバグが修正され、そのほかの問題が解消されてきました。
Note: when you first receive the system, please immediately update the system to current software, as documented below in the NAND Flash and BIOS Re-installation section.
The BIOS (LinuxBIOS + OpenFirmware as bootloader), Linux itself, and the OLPC software stack were installed at the factory on the BTest systems; however, this is intended as testing of the systems and practice for later rather than for serious use. In the time since we gave the system to Quanta for manufacturing until you receive a system, a number of key bugs have been fixed, and other problems resolved.
システムの更新
あなたがシステムを受け取り、そしてその後のベータテストの間に何度か、ソフトウェアおよび/あるいはファームウェア(BIOS)、はアップグレードが必要かもしれません。私たちは開発期間中ローカライズされたソフトウェアとコンテンツ、あるいは工場でインストールされたソフトウェアの完全置換があたりまえのように発生するものと考えています。
When you receive the systems, and occasionally afterwards during beta test, the software and/or firmware (BIOS), may need to be upgraded. We expect that during deployment addition of local software and content or total replacement of the factory installed software will be normal.
BTestシステムのOSイメージをアップグレードする方法
NANDフラッシュとBIOSの再インストール
イメージの自動再インストール手順に従ってください。この手順は、USBキーを刺し込みリブートするのと同じくらい多くのマシンをアップデートするのを非常に簡単にします。
(procedureの要約を以下に示します。
NANDフラッシュ上のOSをアップグレードするために今は以下の３つのステップでいけます：
- zipファイルをダウンロードします
- 内容物を解凍します。そして"boot"という名前のディレクトリをUSBメモリスティック上かハードディスクの上に作ります。
- USBメモリスティックかUSBディスクをマシンに刺し込み、そしてリブートします。
Open Firmwareのための４番目の手順はやっかいな手間を必要とせずに、SPI BIOSブートフラッシュをアップデートし、製造データエラーを修正し、NANDフラッシュ上にイメージをインストールします。これらはできる限り簡単にできるようにしています。)
Follow the autoreinstallation image directions; this makes updating many machines very easy, as easy as inserting a USB key and rebooting the system.
(A summary of the procedure is outlined below.
Upgrading the OS on NAND flash is now a three step process:
- Download a zip file;
- Unzip the contents, creating a directory named "boot" on a flash key or disk drive;
- Plug in the USB flash key or USB disk and reboot.
The Forth scripts used by Open Firmware will update the SPI BIOS bootflash, fix the manufacturing data error, and installs an image onto NAND flash, without further intervention. It is has been made as simple as possible.)
FlashもしくはDiskにLinuxをインストールする方法
(詳細な手順は右にあります：イメージのビルド)
最初のステップはUSBディスクを入手し、このディスクにOSイメージをインストールし、そしてこのUSBディスクからラップトップをブートすることです。
OSイメージをUSBディスクへインストールするための手順についてはhttp://wiki.laptop.org/go/OS_images_for_USB_disks こちら]をご覧下さい。一旦ラップトップがUSBディスクからブートされたら、ラップトップ自身に搭載されているイメージがアップデートされます。(これは古いBIOS上で走っているAテストシステムをアップデートするときにのみ推奨されるやり方です)。内部OSイメージをアップデートする方法については、ここをご覧下さい。
新しいOSイメージを使った場合、BIOSとワイヤレスファームウェアのマニュアルアップデートが自動的に始まるはずです。
(Detailed instructions are here: Build_images.)
The first step is to obtain a USB disk, install an OS image to the disk, and boot the laptop off of the USB disk. Instructions for installing an OS image to the USB disk can be found here. Once the laptop has booted off the USB disk, the image that's on the laptop itself can be upgraded (this is only recommended when upgrading an old ATest system running an old BIOS). Instructions for upgrading the internal OS image can be found here.
Manual updates to the BIOS and wireless firmware should happen automatically when using a new OS image.
XOの申し込み方法
もしあなたがエミュレータでの作業を試み、開発を実施するための物理的なXOマシンを必要とする場合は、developerアットマークlaptopドットorgのメールアドレスへ下記の情報と共にメールをお送りください。
- 名前
- Emailアドレス
- 会社名(もしあれば), 大学名/学校名
- 送り先住所と指定事項
- 名前,
- 住所, (私書箱は不可です。)
- 市,
- 郵便番号,
- 国,
- 電話番号, (運送業者のために必ず必要です。)
- その他何か送付の際の指示があれば
- 電源アダプタの仕様(注意：ある国においては正しい電源アダプタを必要とする全てのデバイスについて税関が非常に神経質です。例えばアルゼンチンは特に小うるさいです)
- 希望キーボードレイアウト(できるだけ要望に沿えるようにいたします)
- マシンの活用に関するあなたの計画についての説明。"XOで遊べたら素敵だし、あなた方のためにいろいろとデモをします"といった内容よりも、このシステムにもたらす具体的な成果と共にはっきりとした提案をいただいたほうがより有望です
- 必要とするマシンの数
- ハードウェアやソフトウェアに関するあなたの経験
If you have tried working with an emulator and need a physical XO to develop on,
please send mail to the developer at laptop dot org email alias with the following information:
- Name
- Email address
- Employer (if any), University/College
- Shipping address and instructions
- name,
- address, (cannot be a post office box)
- city,
- postal code,
- country,
- telephone number, (yes, we really need this for the shipping companies)
- any special instructions
- Power adapter requirements (note that some countries are very picky in customs about all devices needing the correct power adapters; Argentina, for example, is particularly fussy.
- desired keyboard layout (we may or may not be able to oblige).
- Description of your plans for the machine(s). Concrete proposals with defined outcomes are much more likely to result in a system than "it would be cool to play with these and demo them all over for you".
- Quantity of machines desired
- Description of your experience, both with hardware and software
Presuming your request is approved, a mail message will be sent to you with shipping information, or a regret. Note that some requests may be more feasible and applicable later in the project, when we more machines available.
使っていないマシンについて
もしあながたOLPCの取り組みに寄与する時間がもはや確保できない場合は、どうぞ貸与中のマシンを返却くださいますようお願いします。全てのATest用のボードについてはあなたの貢献の記念としてお手元に残してくださって結構です。
If you no longer have time to contribute to the OLPC effort, please be so kind as to return your system. Please keep any ATest boards as a memento of your contributions.
