Hi there, I just start to understand what VPRI and idst and FONC and all this is about, and have read a few of the VPRI(-related) papers that looked the most important to me, starting with last year's VPRI Progress Report. I haven't had the time yet to read through them all, so bear with me if my understanding is still limited and I ignore some of your work or intents by posting my ideas here. I have to say you guys are doing what I'd love to do if I wasn't studying Theology, as I see a lot of common ground with ideas I have. So I see this as the best place to start discussing them.
I'd like to discuss here a bunch of those ideas that I'd like to see implemented in a computer operating system (or something at that level): - Zooming interfaces. I own an OLPC XO-1, I will get an OpenMoko cell phone (if within my financial possibilities). Those devices have a different screen size and/or resolution than current "standard" desktop environments - and they seem to be getting more popular (-> Asus EEE, iPhone, home cinemas / big flat screens). It just seems to make sense to do away with the current layout on the screen and think about how a completely (100%) scalable interface could look like and work. I got very inspired by talks of Aza Raskin on this one, and plan to look into his and Jeff Raskin's research work. I think that not only visually-impaired people would benefit from it, but it would (in my opinion) very likely also contribute to reducing RSI if people could just sit in a more comfortable distance to their computer screen. Aside from enabling innovative, not-yet-thought-about work flows. I'm currently learning how to use Cairo with the XCB backend (which will presumably get supported this summer, and hopefully better documented) and plan to do some prototype work this summer, as time permits. Probably using idst. - GUI and console should merge. I think of a highly efficient and productive (i.e., simple and powerful) GUI that will appeal to people like me who currently prefer text-based computer interfaces (like the GNU Bash) over graphical ones (like Nautilus or Windows Explorer, or even desktop icons that I cannot reach as easily as that terminal window that I just minimised five minutes ago). Whenever I get the chance, I try to do 3D artwork in the Blender 3D software, though I'm still a beginner. The Blender workflows that I grasp so far are inspiringly efficient, having the left hand execute commands on the keyboard while using the right hand to move the mouse. Some people are trying to find ways to make UI's in other domains more Blender-like or adapt Blender to those, leading to efforts like DTPBlender. Though I'm certain that the Blender UI as-is would be quite frankly horrible as an operating system shell, beginning with the fact that it *is* quite hard to learn. To knit it together with the console topic: I think the GUI could learn a lot from (nowadays) unconventional workflows like Blender or a text console. - 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. If I write a piece of code, I should just have to tell the computer one thing: "I think it's ok". After that (barring errors), it should just run whenever triggered, without the user worrying about compilation. This would also eliminate the need for porting to new processor architectures. "Pieces of code", in my opinion, should also just be available everywhere. From a DTP document, I should be able to get to the code that performs the layouting of a paragraph. From the "desktop" (or whatever will finally, hopefully, replace it one day) I should be able to find out how to look for data, and what places the software will look for it and using what algorithm. I should be able to change the system from within without having to reboot. I see that this is a very central idea to FONC too, it just didn't happen to read the small word "JIT" some where. - 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 than RAM, or: RAM loses its content for all practical purposes when powered off whereas a disk doesn't, or: RAM is faster (and a CPU cache is even much faster) than a hard disk drive (or even online storage).) As in the JIT paragraph where the computer decided which programs to compile (and keep compiled), I think the computer's system software would be the most qualified instance to decide which data is worthy of short-term attention and modification (like the stuff I have zoomed into on my hypothetical screen right now), and which data is worthy of 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, there should be a way for a user to say: "save all data to disk right now" (with less technical terms, but I'm too tired to think of some more beginner-friendly sentence right now). This would be the action taken by the system before powering off anyway, which I think should not take the order of magnitude of 10 seconds (like my "traditional" laptop and the OLPC XO-1), but rather 1 second or even less. Also, startup has a lot of room for improvement. For example, what about saving a screenshot of the last things that were on my screen and show this as soon as possible on startup? The user could just keep a TODO list zoomed in at the end of a session, and within seconds (or less) could see it again on starting up. (Maybe he would not be able to edit it for a little more time yet, but at least this would be something vastly more 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. Looking forward to comments, Felix Rabe
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
