Yes I agree, however Hugo designed the Flash Savearea so that it saves in a different part of the flash each time, thus ensuring that the flash is 'evenly roasted' and over many years the whole flash area is used up evenly - probably long before then the hard disks and display dies but thats only part of the problem.

If we keep updating the same part of flash with shopping lists then we are not probably doing the same to exetend the flash rams life as the flash save area does now for saving the player status.

The same goes for kernel updates - in all likelihood we are not likely to 'use up' the flash with kernel updates even if Mark released 3 updates a day for 2 years and we installed everyone of these updates as they were released.

However the shopping list idea in flash is not without some [minor] drawbacks and we should bear this in mind as this does limit some of the things we can use it for.

There must be a 'flash' block size which is the minimum that gets erased/written every time you changed even one byte, so changing one byte in X bytes is the same as changing every byte in X bytes.

I would figure the flash in the player is designed for up to a minimum 1,000-10,000 erase/write/cycles but this is calculated assuming a even spread of updates over the lifetime of the device and no more than X% of it is updated more than say 1,000 times ever.

To keep whacking a the same block of flash with updates ala shopping lists does put a different stress on the lifecycle design of the flash ram.

I guess Hugo can comment as he obviously had these things in mind when the save to flash routines were developed for saving the player status.

Don't get me wrong I'm not knocking it, I think its a great idea, but lets be a little cautious about using something like flash as if it were a RAM device - its not.

And once the Flash Ram starts going bad it will begin to affect everything stored in it - i.e. the kernel also as its stored in there & the save area etc.

My memory is going Dave, I can feel it....