1
edit
Changes
Jump to navigation
Jump to search
no edit summary
Here are a few of the most obvious development issues:
* memory footprint of applications
* memory leaks
* 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 on its footprint.
* ability to operate applications when running in grayscale mode
* 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.
* graphical activity that does not turn itself off quickly
* 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
* 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.
This page is a stub. Please expand on it.
* memory footprint of applications
* memory leaks
* 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 on its footprint.
* ability to operate applications when running in grayscale mode
* 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.
* graphical activity that does not turn itself off quickly
* 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
* 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.
This page is a stub. Please expand on it.