Developers program/lang-ja
- This is an on-going translation
OLPC開発者向けプログラム
開発者プログラムに参加するための手順についてはここをご覧下さい.
あなたがしようとしていることの多くはエミュレータを使って行うことができる場合が多いです。
- あなたのシステム用にエミュレータをダウンロードし走らせるにはエミュレーションのためのOSイメージをご覧下さい。エミュレーションには、QEMU, Paralles, そしてVMWareなどの様々な選択肢があります。
- 個人の活動成果やライブラリコレクションもダウンロードすることができます。
- ソースコードの保管場所とバグトラッキングシステムはここにあります。
上記の補足情報として、該当のリリース関連情報としてハードウェア・ソフトウェア・ライブラリリリースノートをご覧下さい。
概要と心の準備
OLPCシステムは、おおよそ5年程前の一般的なラップトップと比べ際立った相違点があります。すなわち、私たちがベースとしているシステムソフトウェアは以前よりもより多くのことができるようになりました。Linux環境は今では言語記述において以前は手の届かなかった国際化に対応しており、遥かに高品質なレンダリングと、そして何よりもアプリケーションの選択肢が大きく広がりました。
しかしながら代償もあります。「ムーアの法則」はメモリの利用やCPUの利用において私たちを無頓着にしてしまいました。この状況は利用可能なソフトウェアの"フットプリント(サイズと必要リソース)"に対し難しい選択を迫ることになりました。OLPCラップトップは内蔵ストレージとして512MB(のフラッシュメモリ)しかありません。そしておそらくもっと深刻な制約として128MBしかないRAMとシングルコアプロセッサであることが挙げられます。過去5年間にわたり、これらの問題に対してOLPCコミュニティはより神経質になってきました。そして作業はこの"膨れ上がる"サイズと全般的な処理効率改善の作業にむけ順調に推移しています。
私たちが基盤とする技術の選択は、ソフトウェアの能力において、見渡す限り世界的な規模での"ユーザの使用感"において最も優れたものを達成すると予測されてきました。この思いは私たちにGTK+とPango(そしてグラフィカルユーザインタフェースの基盤としてCairoも含め)を選択させるに至りました。なぜならば、複雑なスクリプト群におけるPangoの処理能力は現在ではフリーソフトウェア技術の中で最も進んだものです。もちろんその他のツールキット群も利用可能ですが、メモリとflashのサイズに対する代償が大きいのです。特に今日では、私たちが直ちに直面する多くの言語表現に対しローカライズ作業を要す(それらはタイ語とアラビア語を含みます)それらを基盤としたソフトウェアの能力において代償が大きいのです。従って、私たちのベースシステムの標準的部分としてその他のツールキットを含めることは問題を抱えることになり、そして内蔵システムにおける利用感は、複数のツールキットを含めることが恐らく間違いなく全体的な利用感を損ねることになりかねないということを示しています。
Bテストシステム
私たちは"Bテスト"のために、(3つのビルドの)2つの完全なOLPCラップトップ完成筐体のビルドを作ってきました。
一般的に外部ベータテストの前に内部的に1つないしは2つのビルドを用意します。そして私たちのBテスト-1は電気回路の真のベータテストであり、一方アルファテストは新しいスクリーン、タッチパッド、工業デザイン、そしてキーボードのテスト用でした。このプロセスは開発サイクルにおいて通常利用可能になるペースに比べより早いものです。そしてそれに応じて、少々荒いものでもあります。
Bテスト-2ハードウェアは電気回路、新しいスクリーン(今回はディフューザーがスクリーンをより改善しています)、そしてタッチパッドのためのベータテストを継続中です。工業デザインに関してはBテスト-1に比べほんの少しだけ改善されています。すなわちBテスト-1より得られた機構的改善における要改善点はBテスト-2では今回は盛り込まれていません。そしてBテスト-3ではBテスト-1やBテスト-2よりも著しく耐環境性に関して向上する見込みです。
Bテスト-1マシーンの開発者プログラムにおける注目点はシステムにおけるスクリーン、タッチパッド、そして/あるいはカメラの使い勝手を知るためのGUIに関係したプロジェクトにおけるソフト開発です。このようなテストはベアPCボードではすぐに確認するにはなかなかやっかいな項目でした。
Bテスト-2の注目点は、メッシュネットワークのテストプロセスを開始することであり、(準備作業は完了はしましたが、これを書いている現時点ではサスペンド・リジューム機能はまだ動作していないのですが)このサスペンド/リジューム機能についても作業を実施しています。
マシンはまたプロジェクト最初のターゲット国へ割り当てられる予定ですが、個人のフリーでオープンソースのデベロッパーやOLPCの目標を拡大することへの貢献に興味を持っている研究組織は目標としていないため、このプログラム下の活動には割り当てられません。
Bテストユーザに対しOLPCが期待すること
リリースノートをお読みください!
Bテスト-1ビルドは配布が完了しています。Bテスト-1リリースノートにこのマシーンの位置づけが述べられています。 Bテスト-2ビルドは(2007年)2月12日に配布が開始されます。Bテスト-2リリースノートにこのマシーンの位置づけが述べられています。Bテスト-4ビルドは6月下旬に完成しました。そしてこれらの改善されたシステムの配布が始まっています。まず最初に開発者、そしてTraial-2ソフトウェアの準備ができ次第、その後の評価のために配布される予定です。
ソフトウェアはBテスト-1, Bテスト-2,そしてAテストボードで走る予定です。詳しくはOLPCソフトウェアリリースノートをご覧下さい。
バグのレポート方法
私たちのプロセスは完全にオープンなものであることにご注意下さい。商品の"一般の"ベータテストプログラムでは、秘密保持契約への署名を求められ、そしてあなたが直面したいかなる問題、あるいはあなた以外のベータテスターが経験したであろう問題に気が付いたとしても、それらについて秘密厳守を求められてきたことと思います。普通、このようなハードウェアベータテストは、ここで行われてきたものよりもより厳密なテストが完了した後に行われるものです。
初期ベータテストハードウェアとはその後のベータテストや製品ハードウェアに比べハードウェア障害発生の確率が格段に高いことを意味します。また設計に関してはその他様々なテスト項目と共に温度上昇、寒冷地、振動、衝撃、そして湿度といった負荷試験が進行中のものです。
机上では構成が良くとも、コンポーネント自身の設計上の欠陥やその利用方法の両方に置いて実際にはうまく動かないかもしれません。ベータテストはまた異なる製造者のコンポーネントに対して用いられるものです。より多くの製品個数が利用可能な場合は常に、コンポーネントは"複数の製造メーカから調達され",そして異なる製造メーカからの同種の部分についてコンパチビリティテストが実施されます。これは製造開始後特定の製造メーカに問題が発覚しても代替メーカが利用可能であるかどうかという安定供給を確認するためです。私たちのハードウェアに関して2,3の例を挙げるならば、例えば、カメラ供給メーカ、RAM供給メーカ、PCB供給メーカといったものです。例えば、Aテストボードにおいては、私たちは製造に置いて利用したくないいくつかのコンポーネントを見つけました。そして私たちはBテストを通して同様な問題に遭遇する可能性があります。コンポーネントの設計は新しいかもしれません。そしてそれ自身に依存した設計があるかもしれませんし、製造メーカが解決すべき問題があるかもしれません。(例えばライティングパッドにおける下記に記す問題のように。)組み立て時に問題が作りこまれる可能性もあります。問題は設計にあるいはコンポーネントの選択にもありえます。コンポーネントの特定ロットに欠陥があるかもしれません。ベータテストの目的は、特に大量生産される製品について、大量生産を開始するかなり前の段階でこのような種々の問題を見つけ出し、欠陥を完全に解析し、そして、個々の欠陥について直接的原因を理解することで製品ユニットにおいてこれらの問題を排除・防御することにあります。もしあながたハードウェアの問題に直面したら、OLPCは障害解析のために直ちにマシンの返却を要求するでしょう。私たちは代替マシンを大至急あなたに届けるべく最大限の努力をします。
私たちはあなたがバグ追跡システムに新しいハードウェア・ソフトウェアの問題について直ちに書き込むことを期待しています。それによって問題は追跡され解決されます。その際にはあなたが使っているファームウェアバージョン(ファームウェアバージョンは電源投入時の表示2行目に表示されます。例えば "OpenFirmware CL1 QA62 Q2A"という表示ならば、QA64がファームウェアバージョンです。)、オペレーティングシステムビルドナンバー(ブートプロセスの最後に表示されます)、そしてあなたのマシンのシリアル番号(バッテリーの下に表示してあります。)を含めてください。この情報が、私たちが問題を解析し解決することに役立てられます。
同じバグの入力は避けられないとは思いますが、同様な問題がすでに報告されていないかどうかまず検索をしていただけると非常に助かります。あなたが問題に遭遇したり、あるいはどれくらいの頻度で発生するかを私たちが知らなければ問題の解決しようがありません。すなわち、明らかに、ある別の問題と同じ問題に遭遇したならば、どのくらい頻繁にそれが発生するのか、あるいはあなたが気が付いたその他追加情報を知ることが非常に役立ちます。なるべく少なく、ではなくなるべく多く問題についてレポートするようにしてください。バグについてのレポートやコメントの中からあるパターンが浮かび上がってくるかもしれません。あるいは問題がどれだけ深刻であるかについてより良い新しいアイデアが生まれるかもしれませんし、その解決のためによりよい優先順位付けをすることが可能かも知れません。バグとは良いものなのです。個々のバグは後になって修正するよりも、直ちに直すほうがより簡単です。
ハードウェア
ハードウェアについてのユーザガイド
あなたは"普通の"商用製品を使用する機会を得るであろう随分と前に、テストの間システムを使っていることと思います。これはハードウェアとソフトウェア両方のテストをスタートするためです。何故ならば私たちのシステムは一般的なラップトップ(例えばスクリーンだとか、電源管理だとか、耐環境性といったものに関し)に比べ著しく異なり、また大変異なる環境で利用されるであろうからです。あなたはコンピュータシステム製造メーカがあなたから隠してきた"カーテンの後ろの真実"を(あるいは部分的にでも)知ることになるでしょう。良いこと、悪いこと、そしてハードウェアとソフトウェアデバッグの醜いプロセスを、です。
右の写真はこのマシンの特徴の殆どを記しています。マシンを開くために、まず最初にアンテナをアンラッチし、そして持ち上げて開きます。
ebookモードに変更するためにスクリーンを回すためには、スクリーンをまず少なくとも90度開いた状態にしなければなりません。スクリーンはキーボードの上に再び閉じる方向へ、1方向、もしくは両方向にまわすことができます。
バッテリーパックはキーボードの下のスクリーンの下に位置しています。取り外すときは下のサムネイルに示すように2つのスライドラッチをリリースします。同じ写真にSDスロットをはっきりと確認することができるでしょう。ノート:後期のビルドではマシンの表面がピカピカしないようプラスチックに表面加工がなされる予定です。
Bテストマシーンで心しておくこと
Bテスト-1リリースノートあるいはBテスト-2リリースノートとBTest-1 Demo Notes|Bテスト-1デモノートをよく読んでおいて下さい。
もしあなたがBテストマシーンを入手したならば、以下のものが同梱されているはずです。
- 1台もしくは2台のBテストシステム(利用可能な場合はローカライズされたキーボード)
- (私たちの物流部門と占いが許す範囲で)個々のマシン用に、利用可能な場合はあなたの国の正しいプラグタイプを有するAC電源アダプタが一つ。
- 個々のマシン用にバッテリーをひとつずつ。
- 工場かOLPCにて事前組み込みなされた有るバージョンのソフトウェア:到着後直ちにソフトウェアの更新をするつもりでいてください。更新作業はAutoreinstallation imageによって非常に簡単にできるようになりました。
プロジェクトにおける情報交換の場所
最初にあなたが興味を持つのはあるシステムレベルでのあるいはアプリケーションレベルでのコーディングであるならば、私たちのHosting Wikiの中の一つのプロジェクトに参加してください。 SourceForgeといった代替手段よりも私たちは遥かに柔軟性に富んでいて、回線容量もCPUも利用できます。そしてOLPCに関係ないその他の数千ものプロジェクトに埋もれてしまうこともありません。もしあなたのプロジェクトがOLPCと関係の有る観点を有するならば、限られたOLPC関連の設備を喜んで提供しましょう。それは例えばが部トラッキングとか私たちのwikiとかといったものです。
ハードウェアスケジュール
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.
目標
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.
品質管理
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
ソースコード管理システム
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 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
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 depends on a number of key technologies and projects, including:
お問い合わせ
e-mailについてのお問い合わせはContact OLPCをご覧下さい。
郵便による送付については下記まで:
- One Laptop per Child
- P.O. Box 425087
- Cambridge, MA 02142
- USA
IRC Chat
私たちは主にIRCインスタントメッセージングを利用しており、irc.freenode.netのチャネル#OLPCと#sugarにいます。
ソフトウェアのインストール
ハードウェアを受け取った方は
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.
システムの更新
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.
BテストシステムのOSイメージをアップグレードする方法
NANDフラッシュとBIOSの再インストール
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をインストールする方法
(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で遊べたら素敵だし、あなた方のためにいろいろとデモをします"といった内容よりも、このシステムにもたらす具体的な成果と共にはっきりとした提案をいただいたほうがより有望です。
- 必要とするマシンの数
- ハードウェアやソフトウェアに関するあなたの経験
使っていないマシンについて
もしあながたOLPCの取り組みに寄与する時間がもはや確保できない場合は、どうぞ貸与中のマシンを返却くださいますようお願いします。全てのAテスト用のボードについてはあなたの貢献の記念としてお手元に残してくださって結構です。