Talk:Software/Goals

How come this page talks more about the package manager (or lack thereof) than about the goals for the software?

Simson 22:13, 17 September 2006 (EDT)

This comment was on main page; guess it'd be better transfered to the talk page.

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

Incomprehensible text removed

Finding this text incomprehensible, I removed it, replacing it a few lines which perhaps capture some of the intent.

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.