Developers program/lang-ko

  이 페이지는 OLPC 팀을 모니터링합니다.

This is an on-going translation

The currency of this article or section may be limited by out-of-date information. There may be relevant discussion on its talk page

• 공식 번역문이 아니므로 (No Official translation), 번역이 매끄럽지 않은 부분은 원문 Original을 참조하시거나, 추가적으로 번역이 요구되는 부분은 주저 없이 discussion page에 메시지를 남겨주세요.

OLPC 개발자 프로그램

소개 및 기대치 세팅

OLPC 시스템과 전통적 대략 5년 전의 노트북 간에는 주요한 차이가 있습니다; 즉, 우리의 기본 소프트웨어 시스템이 당시보다 훨씬 유능합니다. 지금 스크립트의 국제화를 지원하는 리눅스 환경은 과거에는 불가능했으며, 훨씬 높은 품질 렌더링과, 무엇보다, 훨씬 광범위한 응용프로그램들이 있습니다.

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.

그러나, 이는 일련의 댓가를 지불했습니다: 무어의 법칙은 메모리와 CPU 활용 측면에서 우리를 나태하게 만들었습니다; 이는 우리로 하여금, 수용 가능한 소프트웨어의 "족적"을 유지하도록 다소 힘든 선택을 강요했습니다. OLPC 노트북은 단지 512MB (* 역주: BT3은 1GB) 만의 저장공간 (플러시)를 가지며, 가장 심각한 제한으로 128MB (*역주: BT3은 256MB)의 메모리와 싱글코어 프로세서를 가집니다. 지난 해 동안, 우리 공동체는 이러한 이슈들에 더 민감해 졌으며, "거품" 속에서도 제대로 작동하는 기계를 만들었습니다. 작은 것이 아름다우며, 보통 더 빠릅니다.

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!).

우리는 기본적인 기술로 세계전역에 걸쳐 가장 우수한 전반적 "사용자 경험"을 지원할 소프트웨어를 선택합니다. 따라서, 우리는 GTK+ 와 Pango (with Cairo as the graphical underpinnings)를 선택했는데, 복잡한 스크립트를 처리하는 Pango의 능력은 현대의 가장 진보된 자유 소프트웨어 기술입니다. 다른 툴킷도 이용될 수 있지만, 메모리와 저장 공간이 협소할 수 있으며, 오늘날, 태국어와 아랍어를 포함하여, 스크립트의 많은 부분을 지역화하므로, 그에 기반한 소프트웨어의 성능 저하가 야기될 수 있습니다. 따라서, 다른 툴킷들을 우리의 기초 시스템의 표준 구성에 포함하는 것은 문제가 있으며, 임베디드 시스템에 관한 지난 경험은 복수의 툴킷을 포함하는 것이 전반적인 문제를 야기함을 보여줍니다.

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 , 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"를 위한 세 번의 완저한 OLPC 빌드 중 둘을 거쳤습니다.

전형적으로 외부 베타 테스트 이전에 한 두 차례의 내부 시스템 빌드가 있으므로, 우리의 BTest-1은 사실 전자부품에 대한 베타 테스트이며, 새로운 스크린, 터치패드, 산업 디자인 그리고 키보드에 대한 알파 테스트입니다. 이것은 시스템이 일반적으로 가용한 때보다 이른 초기 개발 단기이며, 따라서 개괄적입니다.

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 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의 기대

릴리즈 노트를 읽으세요!!

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 software will run on BTest-1, BTest-2 and the ATest boards; please read the OLPC Software Release Notes.

버그 보고

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. This early beta test hardware means a much higher probability of hardware problems than later beta test or production hardware. The design is just now 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.

하드웨어

하드웨어에 대한 사용자 가이드

e-북 구성
EBook Configuration

하단 뷰
Bottom View

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.

ATest 보드 타입

We've had approximately "ATest" 500 developer boards built, to jump start serious development in the free- and open-source software community and the initial deployment countries. Quantities of this generation of boards is limited as we do not have production test fixtures. Note that these are bare printed-circuit boards. At this time, we still have a limited number of boards available, and some more may become available as BTest systems replace many uses of ATest boards.

The hardware specification of these boards is set.

There are a number of ATest board types in the wild:

• 30 Pre A-Test PCB, which have been built and distributed.
• 20 A-Test PCB's, which have been built and distributed.
• 485 A-Test PCB's, which have been built and are being distributed through Brightstar. These can be distinguished from the first 50 boards in that they have serial-number barcodes on them.

These boards lack DCON chips and instead come with the standard VGA connector you'd find on the back of a desktop or laptop computer. We expect that production boards may ship with pads for VGA connectors, but not the connector itself. Additionally, the Pre-A-Test boards have populated mini-pci connectors; on the A-Test boards, these mini-pci connectors have been left off; the pads are included and will probably be included on production boards.

The A-Test boards include a socketed ROM chip for BIOS development; this socket will not be on production boards. The sockets are empty; the BIOS is stored in the serial flash chip that is interfaced via the embedded controller. The process for updating the serial flash under Linux is not yet available and at the moment involves booting DOS and updating the flash chip using a utility from Quanta. Unless you are directly involved in BIOS development, you should stear clear of BIOS updates unless and until instructed by responsible people working on behalf of OLPC.

At this time, the hardware is all believed to work (having been tested), but not all drivers are working properly under Linux. The wireless driver is being completely revamped at the moment.

See: Notes on using the OLPC developer boards.

기대해서는 안되는 것

1. Monitor or flat panel
2. disk, DVD, CD or USB drives
3. keyboard or mice
4. powered USB hubs that may be needed for use with some peripherals
5. USB ethernet adaptors
6. other input devices

We expect you have or can acquire these locally.

BTest 머신에 대한 기대 설정

BTest-1 Release Notes 또는 BTest-2 Release Notes 그리고 BTest-1 Demo Notes를 자세히 읽어보세요.

If you get a BTest machine(s), expect to get (a) box(s) with:

1. one or more BTest systems, with localized keyboards if available
2. 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
3. one battery pack for each machine
4. 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.

ATest 보드에 대한 기대치 설정

Expect to receive (a) box(s) with:

1. one bare OLPC A-Test board, in a static protective bag, with static warning, with serial number both on the box and on the board.
2. one power supply brick (U.S. plugs), 15-Watt capacity. Note that Sony power bricks should also work fine, and that if you can find the connector (the Sony appears compatible) you can use many different DC voltages.
3. RS-232 cable adapter to DE-9 male connector for serial console use and debugging
4. a small plastic bag with standoffs for the board, along with a diagram showing where they should be inserted
5. one pair of 802.11 antennae, which will need to be connected to the board before use.

프로젝트 오스팅

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.

하드웨어 스케줄

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, will sometime in the spring. This final BTest build is the first point where working with children starts to make sense, as the software matures.

목표

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

OLPC runs a development environment for hosting software and content development projects. As much as possible, we encourage you to do your development upstream in the original projects. However, some projects are OLPC specific, or need temporary development resources while being staged for our systems. An example is the Linux kernel tree where we maintain OLPC code before it is ready to submit to the main Linux kernel. This lets us easily share work on various aspects of the Linux kernel, while tracking Linus' tree reasonably closely, to aid in upstream submission of code. We are happy to provide hosting resources on this system to those with OLPC related needs.

소스코드 관리 시스템

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.

위키

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:

• Gnome
• Matchbox
• GTK+ toolkit, Pango Text Layout Library
• Cairo Graphics Library
• X Window System
• Linux Kernel
• Gecko Rendering Engine of the Mozilla Foundation
• AbiWord word processor
• eToys

연락처

메일

For e-mail contacts, see Contact OLPC.

Snail mail please sent to:

One Laptop per Child

P.O. Box

Cambridge, MA 02142

USA

IRC 채팅

We primarily use IRC instant messaging, and can be found on irc.freenode.net, #OLPC and #sugar channels.

Instalación de Software

제품 수령

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.

BTest 시스템에서 OS 이미지를 업데이트하는 법

낸드 플래시와 바이오스 재설치

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:

1. Download a zip file;
2. Unzip the contents, creating a directory named "boot" on a flash key or disk drive;
3. 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.)

플래시 또는 디스크에 리눅스를 설치하는 방법

(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.

Como inscribirse

Please send mail to the developer at laptop dot org email alias with the following information:

1. Name
2. Email address
3. Employer (if any), University/College
4. Shipping address and instructions
   1. name,
   2. address, (cannot be a post office box)
   3. city,
   4. postal code,
   5. country,
   6. telephone number, (yes, we really need this for the shipping companies)
   7. any special instructions
5. 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".
6. Quantity of machines desired
7. 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.

한가한 기계들이 있다면

If you no longer have time to contribute to the OLPC effort, please be so kind as to return your system or board for redistribution.