On Thu, 2011-06-09 at 11:42 -0700, BGB wrote: > interesting... > less painfully slow than I would have expected from the description... > > I wasn't thinking exactly like "run an emulator, run OS in emulator", > but more like, a browser plugin which looked and acted similar to a > small Unix (with processes and so on, and a POSIX-like API, and a > filesystem), but would likely be different in that it would "mount" > content from the website as part of its local filesystem (probably > read-only by default), and possibly each process could have its own > local VFS. > > screen/input/... would be provided by APIs. <snip>
> > However, such a hypervisor will also host more ambitious OSes, for >> example, platforms for persistent capability-secure peer-to-peer >> real-time collaborative end-use-scriptable augmented-reality >> environments. (again, trying to use word-associations to roughly >> sketch what I'm referring to, as I did earlier with >> "Croquet-Worlds-Frank-OMeta-whatnot"). > > > > Does this make my original question clearer? > > ok. > > what exactly this would be like is less obvious. > I personally have a much easier time imagining what "Unix in a browser" > would look like. > > > with just a plain OS in the browser though, one could run apps... > > then one could have 3D mostly by having this virtual OS expose OpenGL > (or GL ES). > > possibly, for sake of simplicity, the "app" could always use OpenGL, > just its "text mode" would just be using OpenGL to draw all the characters. > > then maybe some special API calls for handling input, and "enabling" GL > (disabling drawing the console UI). > > > I before wondered about the problem of what to do about client-program > memory use, but it seems like there is a nifty solution: if a limit is > exceeded, allocation calls fail (say, each process is limited to a > certain amount of memory). > > possibly, a given "app" is also limited to a certain maximum number of > child processes, at which point "fork()" calls will fail (or send out a > "SIGKILL" or similar to all processes belonging to the parent app). > > > or such... I've been following this discussion and it seems there are a lot of very interesting ideas floating around, but I'm afraid I'm finding a lot of it to be getting rather bogged down in details like plugins, processes, etc. Forgive me if I'm missing something fundamental here, but to me Alan's contrast of "browser as application" vs "browser as OS" can be roughly translated to "the browser is the 'real' application, the pages are just data it reads" vs "the pages are the 'real' applications, the browser just implements the lower levels of the stack". The latter viewpoint is gradually taking over now, where those "lower levels" are currently CPU (Javascript engine), storage (cookies, HTML5 local SQL, ...), networking (XMLHttpRequest, WebSockets, ...), display (DOM, canvas, WebGL, SVG, ...), IO interrupts (events) and so on. Can I ask how this is not an OS? Regards, Chris Warburton _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
