K. K. Subramaniam wrote: > On Sunday 01 Jun 2008 3:45:03 am Felix Rabe wrote: >> 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. > You may also want to take a look at > http://www.ted.com/index.php/talks/view/id/129. The processing power and > memory required for responsive operation are available on desktop/notebook > class machines today but not on handhelds. Video I/O also needs to transition > from VESA to OpenGL.
[ WRT the link: Awesome! WRT the presented software: Is it open source? Is it patent-encumbered? Does it all just run on Windows? (Quoting http://labs.live.com/Seadragon.aspx: "from wall-sized displays to mobile devices" - almost what I said :) ) I worry that this great technology, thanks to the Microsoft lock-in, will need to be separately and time-consumingly re-implemented if it is to be used as part of a free software system, which is (hopefully) what VPRI is intending to produce. ] I'm fine with a not-so-perfect zooming experience as long as the hardware is used to its extents and the zooming mechanism is usable. I just want zooming / scalable graphics to be used ubiquitously throughout the whole GUI of the system (which I think should be inherently scalable in not just this, but every aspect). I imagine that zooming could be made more efficient by tricks like letting the user specify a "reference area" for zooming, such that only part of the whole screen gets zoomed in or out as a representation of the whole screen, which will follow suit as soon as the user is done zooming. Or he could rectangle-select a piece of interesting information to zoom in steps, as it is already done in current PDF readers, image editors / viewers and similar programs. > >> - 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? > Because of the i/o speed technology gap between volatile memory (~2GB/s) and > persistent memory (~3MB/s-30MB/s). I had considered that too, but maybe I did not express myself clearly enough in that point. The computer should decide, most of the time autonomically, *based on these different properties of different kinds of memory* (relative speed, relative size, persistency beyond reboots etc.), when and how to transfer data between one kind of memory and the other. The safety of the user's data should always have the highest priority, but the user should not have to worry about manually saving his work in regular intervals, and should also not have to rely on a (per-application) auto-save mechanism implemented in proprietary, inconvenient ways. Auto-saving should just work system-wide and transparently to the user and the running code. I think this will also bring garbage collection into play in interesting ways, which does not contribute to a quick and easy implementation of this idea. But I'm primarily arguing from a user's (busy Theology student's) point of view. In my opinion, there should basically only be one huge virtual memory spanning the whole persistent memory space available, of which currently-used parts would be in RAM. The hard-disk version could, at any time, be used to boot up properly (in case of an unexpected power cut), thanks to proper and efficient journalling / snapshotting. (I wonder what Btrfs will contribute to this discussion. It sounds interesting.) Differences to current, conventional operating systems: - There would be no swap space (file or partition) used for making RAM larger, but RAM (and also CPU cache) would be used consistently to cache access to persistent, slow hard disk drives (or the Internet even). The computer should actually be able to figure out the most optimal caching configuration. Some configure-time optimization math should IMO get it to do the right thing relatively easily, given the right parameters. - Currently, programs and user files have (sometimes) a very different structure between their saved state on hard disk and their loaded state in RAM. This just seems unnecessary, and using cache and RAM transparently on top of the other storage facilities would (have to) do away with that current state of affairs. (Of course, I'm not discussing things like caching the full-screen bitmap version of a JPG image and thinks like that. Obviously, this kind of temporary data does not belong on hard disk.) > As we get a computer to do more, our > working set gets larger and persistent i/o takes longer. Then let the computer say something like: "Look, I'm too busy at the moment to respond smoothly to your interactions with me. These are the things I'm doing right now: [-> list of individual working sets / processes / threads / active objects / ... , presented in a way that makes most sense to the user and maybe ordered by the amount of performance drop they caused / system resources used]. Which of those would you like to stop (if any)?" I know this is probably very hard to implement, as I know e.g. that Linux is struggling to give good information to the userspace about the exact memory consumption caused by individual processes, or things like who is causing how much I/O (though LatencyTOP might give all the necessary information - I haven't checked and thus don't know). In a future (fully-late-bound, message-passing-objects-based) system, the division into processes might not make any sense, and performance measurement facilities could get even more complex as they are today. Though the design of that future system should probably allow for those performance (bottleneck) measurement facilities. >> 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. > You could accomplish this today, but it would be a big privacy hole. > A working set may contain private data and should not be accessed without > authentication. Imagine a bank transaction window in a startup splash screen! I thought about this, too. I didn't bring it up because some of its aspects seems obvious. Also, security as a topic seems to be a very intensely discussed one and other people have way more experience with computer security than I have. (I basically use Linux-based systems, complicated passwords, signed emails, and normally ignore everything else that I'm not interested in. Maybe I should be more interested, I don't know.) But I think my ideas don't inherently preclude tough security. (At least they don't rise a warning bell like "everybody will just be able to download your hard disks' content without you even noticing if this-or-that will get implemented".) I think a computer system user does not need privileged access to a computing system some (maybe most) of the time. (Not even in the form of a normal user account.) E.g. he might just want to use it as a fancy calculator for a short moment, without having to type in his credentials. (That and the long boot time is why I currently don't use a not-already-running personal computer as a calculator nowadays -- maybe with the exception of the developer-keyed OLPC XO-1, which will give me an OpenFirmware prompt within seconds.) A screenshot of that calculator showing up after the next reboot would be a neat way to inform the user what software will be running when the system is ready, and he can start to think about the next steps to take (e.g. switch over to another application, or use it as a calculator again and just start to enter digits). One way out of the boot-up privacy issue would be to let the user decide between starting from the last screen visible before shutdown, or starting from a different (default) screen. (This works for the cases when another, untrusted person could peek over the legitimate user's shoulder, but the legitimate person is currently accessing the machine.) Another way out is to get the authentication capabilities of the system up as soon as possible. This could just again mean having a screenshot show up of the last view an unprivileged user had on the system, which might include a password prompt (with no password visible, of course). I think the system should be aware of some obvious, basic kinds of information that should be kept private, e.g. anything to do with financial data. Of course, if you use the machine to browse the Web in an unprivileged mode, then this is hard to determine - unless you go by the criteria that e.g. every HTTPS connection, or even every secured connection in general, will transport private data and the user would have an interest of closing those connections before shutting down the machine to leave a screenshot of his session behind. (This is getting into too much detail, like e.g. the user should get informed (and be able to decide) about those screenshots showing up next time etc. etc.) - Felix
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
