Talk:Hardware specification
A tacit assumption of the OLPC project is that these systems will enjoy limited - or even zero - field maintenance. The best one might hope for is that some onboard diagnostics could warn of impending problems to help the end-user plan for the demise (and possibly the remanufacture) of his unit. In the First World, most are used to tossing out electronic stuff long before it wears out, on account of "technical obsolescence" But OLPC units may see use long after they are "obsolete", for complex reasons that don't care about "Moore's Law". And who knows what setbacks will befall schools in the places these machines might go? Consider a country that suffers a decade-long "technology" embargo, for example.
I have not built devices with flash memory, but I understand that it can't be rewritten an indefinite number of times - maybe just a million? (Something done twice a minute is done a million times in only a year.) I assume that measures are taken to load-balance the wear on the various blocks of the memory. But IF one suspects that the flash memory may wear out before other laptop components, it would be useful if the end-user could determine how much life was left in it. When the day came the unit did not function, a hint that flash memory wear killed it might keep remanufacture cheap enough to make sense. (At least "run the numbers" before dismissing my concerns!) Of course the same goes for any other parts (e.g. crank) whose usage (and inferred wear) might be measured. (cf. S.M.A.R.T. technology for PCs with hard drives.)
- Linux supports the JFFS2 file system which addresses the issue of limited number of Flash write cycles. (Incidentially, JFFS2 was developed at Red Hat)
Recycling of components - even "Frankenstein" repairs in remote field locations with multiple broken units - might well be designed into the system from the ground up. Moreover, it could also prove useful to benchmark software applications for their life-shortening properties. For example, an application that did frequent automated backups of a document being edited might wear the flash memory more than worthwhile. Remember, in the CRT age, "screensavers" once EARNED their name, rather than serving other purposes on cheap displays easily tossed when worn!
The "prospectus" for the OLPC laptop looks to a five-year-plus life to justify it as a textbook replacement alone. I think that flash memory "forgets" after a decade, so perhaps the "permanent" part of the flash content might also be regenerated episodically, too. If it is a big portion of the total flash memory, perhaps "rotating the tires", by swapping in which physical part of memory it dwells would allow superior wear-balancing as well.
Upkeep will be the problem of the host country, but maybe one should think about it now before the design is complete. Will host countries want to revise the "permanent" memory content one or more times (e.g. via a USB port) before the machine cannot be used? Maybe First World "Gen-Netters" like revving freeware versions monthly, but poor people burdened with long hours of tiring physical work will not want to make a "hobby" of tweaking a laptop. While USAers might prize customization, another culture might want to keep these "personal" units as harmonized as possible, that cross-peer instruction prove easier. "Shudder": they may value common content over the potential to experiment! But perhaps a village "server" which archives multiple flash "images" could embrace experimentation and homogeneous potential at the same time. Maybe you'd want something like this anyway, as important software flaws emerge late - making a patching infrastructure desirable. (The "server" needn't be a real computer- just a collection of one or more USB flash drives.)
So in looking to keep the OLPC laptops working, one should perhaps try to think like a carpenter planning to sail with Magellan. There will be no way to "Fedex" in replacement parts overnight.
RF
CPU, esp, running firefox with non-latin fonts - isn't it too slow? I have a similiar spec desktop linux machine actually, and whenever I load multilingual pages (even just a wikipedia page with the names of languages listed on the side in Arabic and Hindi and Korean. Rendering a WP page of Korean page on FireFox takes time!), the font rendering seems real slow... I'm running a K6-3@400Mhz.
- The CPU is constrained by "5W max heat dissipation" requirement. AMD Geode System already consumes almost 2 W under load, leaving only 3 W for display, audio, storage and wireless. At Wikipedia it was suggested that lower power Alchemy be used which would allow for higher clock rates, but apparently x86 was chosen for compatibility reasons.
- 5W heat dissipation requirement was recently dropped and changed to 10W. So there might have been the possibility of using a faster CPU after all. 130.149.23.44 12:33, 9 March 2006 (EST)
- Regarding page rendering, using non-XUL-based Browser such as Epiphany, Konqueror or Opera should speed things up.
BIOS, isn't it smart to have OpenBIOS? (ie. Forth?)
I'm worried that 128M of DRAM is going to hobble the machine. Can you get twice as much DRAM if you're willing to take broken DRAMs with parts that don't work, and use the VM hardware to map around the bad spots in them? It's a simple hack and if it cuts the cost of the DRAM chips by 50% then you can put in twice as many. Or are all the DRAMs with failing bits now being used in telephone answering machines where a dropout doesn't matter? -- gnu
