On Sun, Jun 1, 2008 at 12:15 AM, Felix Rabe <[EMAIL PROTECTED]> wrote: > - JIT. I think it was Ian Piumarta who said in his recent presentation > in Germany that nowadays processing power is cheap. So why keep > software around in binary blobs anyway? As I see it, the computer > should be able to decide what software should be kept around in a > (just-in-time and then cached) compiled state and what should not.
Marcus Denker's PhD is just about that, keeping code in AST form and using the compiler as an optimizer/instrumenter and bytecodes as a cache. > - Memory management. I hate the save button. Why do I have to tell a > computer that a string of bytes in one kind of memory should now move to > another kind of memory that can *also* handle a string of bytes, but > just possesses a different set of attributes? (Like: disks are larger Well the save button is also kind of a commit, or checkpoint, that you can use for large-grained undo. In a fully-persistent world you would probably want to extend it to some kind of versioning system where the save button means "this is in a meaningful state". > long-term preservation. In the system I envision, a power failure could > maybe result in something like the last 10-30 seconds of my work lost, > but never more, as memory portions would be constantly swapped into and > out of disk in a safe (journalled?) fashion, in a way that would not > interfere with the user-visible performance of the system. Of course, You could also just journal every user action and replay them from the latest full snapshot in case of a problem. > sensible and usable than a boot logo showing up.) If OLPC can put an > XO-1 to sleep and wake it up again within a fraction of a second, then > the shutdown-bootup cycle should be trimmable to a similar order of > magnitude with a future operating/computing system, I guess. Well this is waking up from sleep, not booting from a clean image. The apple laptops are reasonably fast at waking up too. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
