3 ms·

This is ridiculous. Even if you handwave away security concerns of running arbitrary native code fetched from the web as the operating system's problem, you hav

This is ridiculous. Even if you handwave away security concerns of running arbitrary native code fetched from the web as the operating system's problem, you have locked yourself into a single hardware architecture with (presumably) a single API for those binaries to run against. Even if you expect these things to run on metal you need a standard hardware configuration that exposes known I/O devices, etc. In a world where x86 coexists with ARM, PPC-derivatives and the occasional MIPS machine (not to mention dozens of other variations) native executables are not a sensible option unless you pass that buck to the server and have it spin off a custom binary for any client that may come along. Ok, ok- so we use a VM that everyone agrees on and- wait, we're back where we started, aren't we? Except, of course, we have a ton of mandatory overhead because browsers are no longer specialized to deal with the kinds of media users expect in a browsing experience. Unless you honestly expect that everyone, everywhere will use identical computers for everything, standardized formats will always be necessary.

defen 16y ago
Here is a project that is addressing the security and platform-independence issues while running native code: http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/
leoc 16y ago
> Even if you handwave away security concerns of running arbitrary native code fetched from the web as the operating system's problem Between ye olde Java sandboxing, hardware and software OS virtualisation (Qemu, VirtualBox, VMWare etc.), JavaScript, NaCl, and other examples, it seems clear that this is a problem we now know how to manage. > you have locked yourself into a single hardware architecture with (presumably) a single API for those binaries to run against NaCl appears to have a grip on this problem. Write portable code in one of several languages supported by LLVM; compile with LLVM to the native NaCl format that exists for various CPU architectures, and to Portable NaCl ("PNaCl") bytecode. LLVM can be replaced by another compiler that targets NaCl. > In a world where x86 coexists with ARM, PPC-derivatives and the occasional MIPS machine (not to mention dozens of other variations) native executables are not a sensible option unless you pass that buck to the server and have it spin off a custom binary for any client that may come along. All the server really needs to do is to pre-compile (or be given) a set of NaCl binaries for the presently popular archs as well as a PNaCl bytecode executable for everyone else, but yes indeed, it might also dynamically compile native binaries for minority archs it knows how to support in response to client demand. If the compile is too slow to serve the first such request with a native binary, then the server can serve the PNaCl code until the new native code is ready. (As a matter of fact, it wouldn't really be necessary to replace every single HTML file with executables. But that's another story.) > Even if you expect these things to run on metal you need a standard hardware configuration that exposes known I/O devices, etc. It seems that NaCl provides a syscall-like interface with its "service runtime". Something similar could surely be created for a runtime based on hardware VMs (in other words, something like Ethernet emulation in implementation terms but with an API more suitable for a Web-browser plugin). This part of the design is a weak spot of course, as it can break and fork and version and vary across implementations, but compared to the sinking sands of the browser interface it should prove much smaller and more stable. (HTML files which are genuinely documents rather than webapps are relatively robust against some API breakage but, again, it wouldn't actually be necessary to turn every HTML document with an executable blob.) > Ok, ok- so we use a VM that everyone agrees on and- wait, we're back where we started, aren't we? Except, of course, we have a ton of mandatory overhead because browsers are no longer specialized to deal with the kinds of media users expect in a browsing experience. Portable C or C++ compiled to NaCl should be decently fast for almost all purposes. Failing that, there's always the possibility of hand-writing raw NaCl code as an optimisation for popular architectures. (Or writing 100% native assembler if hardware virtualisation is being used instead of NaCl.) Failing that, even if a few high-performance AV formats have to be hardwired into the browser alongside WebGL (or whatever), we're still nowhere near being back where we are - in a madhouse world where a cartel of browser vendors empowers a tin-pot Napoleon to dictate, among many other things, how we will all mark up our documents, down to the minutest details.
sedachv 16y ago
Smalltalk and System/38 did this in the mid-70s. System/38 code can be run on IBM Power Systems (AS/400) made today. Open Cobalt (Croquet) does peer-to-peer virtual reality by passing Smalltalk bytecode around. Read up on some computing history before flaming.
ZeroGravitas 16y ago
I believe this was the original plan for Xiph's Vorbis, for similar reasons. I believe they abandoned it because of practicality but I can't Google up a link to where I originally read about this. I seem to recall it also involved Monty doing a demo for some company (Apple?) where they thought he was mental to suggest such a thing. edit: http://www.systemtoolbox.com/bfarticle.php?content_id=6 http://www.systemtoolbox.com/bfarticle.php?content_id=6 Monty: The previous Ogg generation, Stormbringer, was a "meta-codec", a language and virtual machine for writing other codecs. It turns out very few people at the time were interested; they didn't want meta-codecs, they wanted the codecs themselves. A particularly abysmal demo of Stormbringer at Apple finally drove that point home (in addition to the fact that Apple was uninterested in Stormbringer, which needed more work to be practically useful, our demo laptop decided to overheat and break down in the middle of our pitch to the Quicktime group). That took our sense of direction away for a while; for most of 1998, no one worked on anything related to Ogg. Then in the fall, Fraunhofer decided to start cracking down on free encoder implementations of mp3. That worried me. It also seemed like things were only likely to get worse; the trend was clearly for companies to start "cashing in" on the Net any way possible, often involving the basic technology itself, and it looked like digital audio would be no different. In 1998 this sense of foreboding was mostly a vague suspicion, but the trend strengthened and clarified over time. That gave me a clear direction to begin Vorbis; I knew what the world was going to need in a codec and soon.

defen 16y ago

Here is a project that is addressing the security and platform-independence issues while running native code: http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/

leoc 16y ago

> Even if you handwave away security concerns of running arbitrary native code fetched from the web as the operating system's problem Between ye olde Java sandboxing, hardware and software OS virtualisation (Qemu, VirtualBox, VMWare etc.), JavaScript, NaCl, and other examples, it seems clear that this is a problem we now know how to manage. > you have locked yourself into a single hardware architecture with (presumably) a single API for those binaries to run against NaCl appears to have a grip on this problem. Write portable code in one of several languages supported by LLVM; compile with LLVM to the native NaCl format that exists for various CPU architectures, and to Portable NaCl ("PNaCl") bytecode. LLVM can be replaced by another compiler that targets NaCl. > In a world where x86 coexists with ARM, PPC-derivatives and the occasional MIPS machine (not to mention dozens of other variations) native executables are not a sensible option unless you pass that buck to the server and have it spin off a custom binary for any client that may come along. All the server really needs to do is to pre-compile (or be given) a set of NaCl binaries for the presently popular archs as well as a PNaCl bytecode executable for everyone else, but yes indeed, it might also dynamically compile native binaries for minority archs it knows how to support in response to client demand. If the compile is too slow to serve the first such request with a native binary, then the server can serve the PNaCl code until the new native code is ready. (As a matter of fact, it wouldn't really be necessary to replace every single HTML file with executables. But that's another story.) > Even if you expect these things to run on metal you need a standard hardware configuration that exposes known I/O devices, etc. It seems that NaCl provides a syscall-like interface with its "service runtime". Something similar could surely be created for a runtime based on hardware VMs (in other words, something like Ethernet emulation in implementation terms but with an API more suitable for a Web-browser plugin). This part of the design is a weak spot of course, as it can break and fork and version and vary across implementations, but compared to the sinking sands of the browser interface it should prove much smaller and more stable. (HTML files which are genuinely documents rather than webapps are relatively robust against some API breakage but, again, it wouldn't actually be necessary to turn every HTML document with an executable blob.) > Ok, ok- so we use a VM that everyone agrees on and- wait, we're back where we started, aren't we? Except, of course, we have a ton of mandatory overhead because browsers are no longer specialized to deal with the kinds of media users expect in a browsing experience. Portable C or C++ compiled to NaCl should be decently fast for almost all purposes. Failing that, there's always the possibility of hand-writing raw NaCl code as an optimisation for popular architectures. (Or writing 100% native assembler if hardware virtualisation is being used instead of NaCl.) Failing that, even if a few high-performance AV formats have to be hardwired into the browser alongside WebGL (or whatever), we're still nowhere near being back where we are - in a madhouse world where a cartel of browser vendors empowers a tin-pot Napoleon to dictate, among many other things, how we will all mark up our documents, down to the minutest details.

sedachv 16y ago

Smalltalk and System/38 did this in the mid-70s. System/38 code can be run on IBM Power Systems (AS/400) made today. Open Cobalt (Croquet) does peer-to-peer virtual reality by passing Smalltalk bytecode around. Read up on some computing history before flaming.

ZeroGravitas 16y ago

I believe this was the original plan for Xiph's Vorbis, for similar reasons. I believe they abandoned it because of practicality but I can't Google up a link to where I originally read about this. I seem to recall it also involved Monty doing a demo for some company (Apple?) where they thought he was mental to suggest such a thing. edit: http://www.systemtoolbox.com/bfarticle.php?content_id=6 http://www.systemtoolbox.com/bfarticle.php?content_id=6 Monty: The previous Ogg generation, Stormbringer, was a "meta-codec", a language and virtual machine for writing other codecs. It turns out very few people at the time were interested; they didn't want meta-codecs, they wanted the codecs themselves. A particularly abysmal demo of Stormbringer at Apple finally drove that point home (in addition to the fact that Apple was uninterested in Stormbringer, which needed more work to be practically useful, our demo laptop decided to overheat and break down in the middle of our pitch to the Quicktime group). That took our sense of direction away for a while; for most of 1998, no one worked on anything related to Ogg. Then in the fall, Fraunhofer decided to start cracking down on free encoder implementations of mp3. That worried me. It also seemed like things were only likely to get worse; the trend was clearly for companies to start "cashing in" on the Net any way possible, often involving the basic technology itself, and it looked like digital audio would be no different. In 1998 this sense of foreboding was mostly a vague suspicion, but the trend strengthened and clarified over time. That gave me a clear direction to begin Vorbis; I knew what the world was going to need in a codec and soon.