On 6/10/2011 7:33 AM, Chris Warburton wrote:
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?
errm...
I don't know...
as for differences from an OS:
it doesn't boot up with the hardware;
it doesn't have an obvious kernel (say, a core which runs the processor
in Ring-0 or similar);
it doesn't provide process management or system calls (except maybe
builtin functions in JavaScript?...);
...
there is not a whole lot that seems in common between a browser and an OS.
yes, there is Chrome OS, but I sort of suspect this will (probably) fall
on its face (vs... say... installing real Linux on the netbooks...).
there is a lot more in common with it being an application:
it resides in "Program Files" or "/usr/bin" or similar;
it starts up after the main OS, and usually by direct action of the user;
it "lives" within a window, or multiple windows (it itself provides the UI);
...
it could be compared to a "platform" though, say similar to .NET or the
JDK, which both have OS-like and application-like aspects:
they run on top of the underlying OS;
they sit around in the background (not generally directly visible to users);
they launch other programs on top of themselves;
...
otherwise, one would get into issues like, say, "how is a modern game
engine, such as Steam / Source, not an OS?..." (yes, Steam and Source
are technically separate product-wise, but share much of the same
underlying architecture, and targeting apps to Steam often involves
summoning up Source as a sort of a slave backend, such as for VFS and
graphics/user-input services). when Source is being used as a game, it
may summon up maps, which may have a lot going on internally, and may
use mods, many of which used scripts (often Lua), ...
however, IMO, they are not really an OS, more 'platforms'...
and, many people would likely find the idea of booting a computer
directly into the Source Engine to be a little silly... (start
computer... start playing Portal 2...).
Steam could make a little more sense, since Steam is basically a
glorified program downloader and launcher (and, interestingly, does some
of its content presentation via HTML, IIRC).
"Valve Steam OS, coming soon..." but, then this would likely behave more
like a hybrid of the XBox360 or PS3?...
my own personal game-engine project also includes:
VFS / filesystem facilities (mounting/unmounting things, several FS
"drivers", ...);
ability to launch/execute "program-like" scripts;
compiler facilities (including a C compiler, also the scripting VM);
a text editing component (Notepad-like);
an internal shell/console interface (Bash-like normally, also can
directly evaluate script fragments);
GUI widget facilities (actually, IIRC, the GUI still supports a
zooming/panning UI as well, but for typical uses fixed-place UI elements
have been more useful);
...
but it is not really an OS either IMO...
maybe an application, maybe eventually a platform...
it would be silly/strange though if every application with a
VFS/shell/compiler/program-launcher/... were branded an OS.
"3DS Max... the OS..."
or something...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
