Software/Goals: Difference between revisions
m (Reverted edits by 202.108.28.23 (Talk) to last version by 212.150.16.241) |
|||
| (14 intermediate revisions by 12 users not shown) | |||
| Line 1: | Line 1: | ||
<noinclude>{{Translations}}</noinclude> |
|||
| ⚫ | |||
__NOTOC__ |
|||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
== Along with any goal, we must have rules of the game == |
|||
== Guidelines == |
|||
=== Children must be allowed to play === |
=== Children must be allowed to play === |
||
| Line 17: | Line 20: | ||
These two central facts mean we can make certain assumptions about deployment and can create an incredibly easy way to install and update the base operating system. |
These two central facts mean we can make certain assumptions about deployment and can create an incredibly easy way to install and update the base operating system. |
||
=== |
=== OLPC is the platform, not linux === |
||
In the classic Linux world we have the strange tendency to merge our ideas of what the platform is and what the applications are that sit on top of it. If you ask "what is the Linux platform" from 50 people in the community you will get 50 different answers. Because of the small size of this platform, ''we have to make choices about what the platform will be'' and how we enable applications to be written. |
|||
If you think about it you will realize that package managers are the result of one simple problem in Linux: we have ''so much software'' that we never know what our platform is. A program that's installed must be able to ask for everything it needs instead of assuming what is available. Because we've had to make choices about what the operating system is, and we know what's there, applications can make certain assumptions and we don't need to use a package managers. Instead we will focus on how to ''enable people building applications for this platform.'' |
|||
Remember that this is not a classic linux distribution so when we don't have a package manager, you should ''ignore your screaming sysadmin hindbrain.'' |
|||
---- |
|||
(comment) Forgive my package manager (PM) mentality, but is not some kind of way of managing blocks of software needed? At the top of this page, it says the student may break the laptop and it must be easy to fix. It also says the student may modify the software, presumably often without breaking it. A PM would know whether the parts of a package are in their original state or not, and therefore when the student approaches the schoolhouse with the repository of software, whether it can offer to 'fix' or revert what may be corruption or failed attempts at customization. |
|||
Because of the small size of this platform, ''we have to make choices about what the platform will be'', and how we enable applications to be written. This is not a classic GNU Linux distribution, with package manager, and an enourmous universe of loosely related software. If you ask 50 people "what is the Linux platform", you will get 500 different answers. Our applications can make assumptions about their hardware and software environment. We can focus on how to ''enable people building applications for this platform.'' |
|||
The PM is also useful when upgrading a package, in that it knows which pieces belong with the package and therefore should be replaced. To only overwrite when upgrading, say by a simple file copy, to leave possibly obsolete pieces on the laptop (version 1.0 uses parts A, B C; version 1.1 replaces A and B with new code, and no longer uses C at all) risks confusing the programming student during his exploration of the package and consuming precious storage space. |
|||
A PM also maintains a valuable catalog of what is installed on the laptops -- while the underlying hardware and OS core is well-defined, what about where a school may have additional packages, perhaps written by students or teachers and a new student comes to town? Having a catalog of what is on his laptop, even for use by an automated process, so that he can receive the local standard configuration, is valuable. And when students begin to share their software creations, visibility by themselves and their teachers into what they have onboard is useful. You do not want to repeat the Windows mantra of blindly reloading a laptop anytime you're not sure what is onboard, even if the unit has little storage and it is easy to do so. It risks disrupting the student's environment, his personal software changes and, even if you separate code from data, losing data regardless. This loss may arise when some data was created with a newer or older version of a package, and the code is taken forward or backward in version. |
|||
[[Category:Software development]] |
|||
And the latter sentence raises the question of version upgrades and his evil brother, dependency management. If a constellation of cool packages are to be created for such a resource-constrained laptop, reuse of packages will be paramount (drawing modules, music composition modules) leading to a complex web of dependencies. If they are not managed within the laptops, then they must at least be managed within the schoolhouse computers, but then they are just laptops themselves, for a uniform distribution environment, perhaps with additional peripherals. |
|||
[[Category:Developers]] |
|||
[[Category:OLPC FAQ]] |
|||
Latest revision as of 01:40, 21 December 2008
Our project goal
To create a solid operating system base for the OLPC hardware which anyone can deploy, requires no administration and provides a clear platform on which to build applications for educational computing.
Guidelines
Children must be allowed to play
Remember that this is a laptop that is designed for children, not for system administrators or programmers. We hope that children will be allowed to play with the base operating system as well as the programs that run on top of it. But at the same time, if they break it it must be very easy to fix and anyone should be able to fix it.
What this means is that the base operating system is something that can be replaced at any time, in a matter of minutes, and without damaging the child's data or the applications that happen to be installed. Simply put, replacing the operating system should not be scary.
Deployment is more important than development
Remember that how you build the operating system is very different than how it will be put into children's hands in the field. The tools that we use to build the operating system - package managers, compilers, installers - are not useful during the deployment of the operating system. This is because we know what the operating system will be and even more importantly we know what the hardware will be.
These two central facts mean we can make certain assumptions about deployment and can create an incredibly easy way to install and update the base operating system.
OLPC is the platform, not linux
Because of the small size of this platform, we have to make choices about what the platform will be, and how we enable applications to be written. This is not a classic GNU Linux distribution, with package manager, and an enourmous universe of loosely related software. If you ask 50 people "what is the Linux platform", you will get 500 different answers. Our applications can make assumptions about their hardware and software environment. We can focus on how to enable people building applications for this platform.