Software/Goals

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.

Along with any goal, we must have rules of the game

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.

The platform is not the same as the applications that use it

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

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.

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.