Changes

* memory leaks

* memory leaks

* required flash footprint of the application is huge

* required flash footprint of the application is huge

* your application cannot be packaged to strip out unneeded functionality. For example, GAIM supports just about every IM protocol in existance, and we can only anticipate 3 being common. So the fact it uses plugins that we can choose to not package saves greatly on its footprint; everything being built in would make this very difficult

* your application should be engineerd and packaged to make it easy to strip unneeded functionality. For example, GAIM supports just about every IM protocol in existance, but we can only anticipate 3 being common. So the fact it uses plugins that we can choose to not package saves greatly on its footprint, whereas if everything were built in, both the memory and flash footprint would be much larger.

* ability to operate applications when running in grayscale mode

* ability to operate applications when running in grayscale mode

* lower effective resolution in color mode: some applications will find this hard

* the 640x480 effective resolution in color mode: some applications will find this hard, even though the frame buffer will always be in high resolution.  If your application does not honor the font resolution change-on-the-fly mechanisms, or hardwires fonts by pixel size, your application won't be able to switch modes gracefully and may require manual intervention to be usable.

* the hardware does support alpha blending (Porter-Duff compositing), so we expect to eventually support this well

* the hardware does support alpha blending (Porter-Duff compositing), so we expect to eventually support this well

* no 3D hardware: we don't have shaded triangles or a geometry pipe; so any OpenGL used will be based on Mesa, and without hardware, will be very slow

* no 3D hardware: we don't have shaded triangles or a geometry pipe; so any OpenGL used will be based on Mesa, and without hardware, will be very slow

* choice of libraries and required applications: you may not have the dependencies you might need, or they might come at too high a memory cost. We will attempt to inventory what you can "count on" in the basic system as it becomes clear.

* choice of libraries and required applications: you may not have the dependencies you might need, or those dependencies might come at too high a memory cost. We willinventory what you can "count on" in the basic system as it becomes clear.

* graphical activity that does not turn itself off quickly; we want to save power

* graphical activity that does not turn itself off quickly; we want to save power

* CPU performance: the system is slow relative to current desktops, though fast relative to desktops at the turn of the millenium.

* CPU performance: the system is slow relative to current desktops, though fast relative to desktops at the turn of the millenium.

* power consumption: if your application is CPU bound for long periods, or routinely requires itself to be run (can't be suspended well), this isn't good

* power consumption: if your application is CPU bound for long periods, or routinely requires itself to be run (can't be suspended well), this isn't good

* while we are a great fan of interpreted languages, key CPU bound kernels had better be in compiled code, or your performance and power consumption will be poor

* while we are a great fan of interpreted languages, key CPU bound kernels had better be in compiled code, or your performance and power consumption will be poor

* the file system is a flash file system, so its write performance is slow, while random access is actually very good.  The performance is glacial if the file system is low on space and has to continually erase freed blocks before writing (jffs2 attempts to do this in the background, but if it can't....). Programs that continually write to the file system without need are anti-social; wear leveling helps flash longevity, but it certainly doesn't help, and burns power.

* the file system is a flash file system, so its write performance is slow, while random access is actually very good.  The performance is glacial if the file system is low on space and has to continually erase freed blocks before writing (jffs2 attempts to do this in the background, but if it can't....). Programs that continually write to the file system without need are anti-social; wear leveling helps flash longevity, but it certainly doesn't help, and burns power.

This page is a stub.  Please expand on it.

This page is a stub.  Please expand on it.