a few days ago fabrice from qemu announced linux running inside a browser. By progressively replacing linux components with JS, emulation becomes lighter?
all these Googly services exist in Android. Except on chromeos you have no apps. Feature? Automatic updates - any distro with a package manager solved that 15 years ago.
bing 'IcedRobot'. It's a golden opportunity for that other Linux phone vendor, HP. Offer Mario and friends full time employment to integrate openjdk on webos - hey presto you've got a Larry friendly android runner. Not that it matters, webos never made it to Oceania.
to reach critical mass, any alternative language such as lua would require sponsorship by each open source browser effort. Given each has its own javascript engine as a selling point (mine is 10% faster than yours), such consensus might be difficult. Perhaps a higher level API than DOM is needed to shield the language runtime from the underlying impl. Perhaps a more realistic solution is to translate lua (or other) into javascript that can then be forwarded to the js engine. Coffescript uses this approach. It would then be a matter of maintaining a source-js translator for each language. If the engine uses an intermediate bytecode then a browser might support compiling certain languages to that bytecode.
Ummm... Isn't specifying what actions a script can perform the definition of a sandbox?
accessing the filesystem, launching popup windows, transmitting content outside of the original domain, redirection, cookies, etc.
These are all permissions that should be codified by the scripting engine's security manager and configurable by the end-user on a site-by-site option.
That's what I don't get. HTML, CSS and (ECMA)script were all put through some standardisation process and, when implemented 'correctly', should ensure consistency across all browsers. DOM on the other hand seems to have caused endless pain.
Can't we draft a common spec for both Gecko and Webkit so at least DOM access for Safari, Firefox and Chrome works identically? (IE and Opera to please themselves). Screw backward compat - define a standard for DOM2012 and migrate from there.
but MS does, indirectly, make money off mono on linux - through VS licenses. While mono/sharpdevelop do exist, i'd guess that a fair proportion of those mono deployers have corporate day jobs sitting in front of VS Pro. Developer mindshare here - MS make money off the tools where otherwise projects would be written in Java.
if ReactOS would adopt a BSD filesystem-to-rule-them-all then ntfs goes the way of the dodo. Some clever soul then slipstreams that code into your Win8 installer as a root fs driver and world domination ensues.:-)
Cheers. I'm assuming the original instructions were concocted for Sun's proprietary Java ME/SE embedded platforms - AFAIK, none of which supported has made it into phoneME, openjdk.
Maybe if MIPS had 'won' on phones we'd greater synergy e.g. The reverse of NestedVM.
I realise openjdk's is stack-based vm and dalvik is register-based. But aren't they essentially mapping virtual machine instructions to hardware instructions? In a rudimentary manner this was tried a decade ago with Java. It was found that general purpose processors would spank a Java-CPU in performance due to the way that a VM would interact with a JIT instead of processing raw instructions.
[Aside - ARM does include instructions for JVM-like code - Jazelle/ThumbEE. Can/does Dalvik even take advantage ?]
The extent to which this idea can escape from a research lab depends on relative performance. Quite interesting from the power consumption aspect though.
Perhaps NASA will demand KFC go skin-free by 2015?:-) If the skin is the part of the chicken that retains the most oil when fried, the benefit to the consumer is a healthier product.
Asus are having an each-way bet. Along with the Transformer, there's also the Slider, which includes a slide-out keyboard.
The Transformer, minus keyboard is lighter and more iPad-like. If they can keep the weight and depth down, the slider mechanism is robust and the keyboard doesn't stink, I'd be choose the retractable keyboard that doesn't need attaching. A problem with traditional tablet pcs is that the keyboards get in the way when you don't need them - there's some awkward rotation mechanism to hide the keyboard.
Call me cynical but the whole point of non-upgradeable storage is dictating the supply of internal storage.
Apple has 2 models available on their store for iPad. Wifi only or 3G. Yet they have the 16/32/64GB options - exactly the same computer but at $US100 price increments.
Slashdot Mirror
a few days ago fabrice from qemu announced linux running inside a browser.
By progressively replacing linux components with JS, emulation becomes lighter?
Hopefully this Saturday rapture phenomenon will be an exclusively North American thing.
It's now Sunday in my timezone. 6pm passed without incident.
Without supplies, won't those poor folks on the international space station starve to death?
"A Scanner Darkly" ?
Another cult Sci-fi adaption and a movie in which Keanu and Winona didn't suck.
i majored at university in mathematics and *never* used a calculator during exams. Something suggests examiners are doing it wrong.
Interestingly, they're both products of Larry Ellison.
The Ext* series of filesystems still has a place against the megacorps?
qemu supports emulating various guest CPUs. Would a simpler instruction set make for faster in-browser emulation?
Australia has prior art on wartime ip-over-donkey. Simpson in WW1.
However, donkeys don't deliver high throughput in the desert; we have a surplus of camels in the Territory.
all these Googly services exist in Android. Except on chromeos you have no apps. Feature?
Automatic updates - any distro with a package manager solved that 15 years ago.
Ex 86? :)
bing 'IcedRobot'.
It's a golden opportunity for that other Linux phone vendor, HP. Offer Mario and friends full time employment to integrate openjdk on webos - hey presto you've got a Larry friendly android runner.
Not that it matters, webos never made it to Oceania.
to reach critical mass, any alternative language such as lua would require sponsorship by each open source browser effort. Given each has its own javascript engine as a selling point (mine is 10% faster than yours), such consensus might be difficult. Perhaps a higher level API than DOM is needed to shield the language runtime from the underlying impl.
Perhaps a more realistic solution is to translate lua (or other) into javascript that can then be forwarded to the js engine. Coffescript uses this approach. It would then be a matter of maintaining a source-js translator for each language. If the engine uses an intermediate bytecode then a browser might support compiling certain languages to that bytecode.
Ummm... Isn't specifying what actions a script can perform the definition of a sandbox?
accessing the filesystem, launching popup windows, transmitting content outside of the original domain, redirection, cookies, etc.
These are all permissions that should be codified by the scripting engine's security manager and configurable by the end-user on a site-by-site option.
That's what I don't get. HTML, CSS and (ECMA)script were all put through some standardisation process and, when implemented 'correctly', should ensure consistency across all browsers. DOM on the other hand seems to have caused endless pain.
Can't we draft a common spec for both Gecko and Webkit so at least DOM access for Safari, Firefox and Chrome works identically? (IE and Opera to please themselves). Screw backward compat - define a standard for DOM2012 and migrate from there.
agreed but savvy consumers will vote with their wallet and with the benefit of hindsight choose wisely next time. :-)
regardless, this demonstrates the benefits of free software. A similar phone loaded with aosp would have lifetime updates thanks to cyanogenmod.
but MS does, indirectly, make money off mono on linux - through VS licenses. While mono/sharpdevelop do exist, i'd guess that a fair proportion of those mono deployers have corporate day jobs sitting in front of VS Pro. Developer mindshare here - MS make money off the tools where otherwise projects would be written in Java.
or the us economy will continue to sink into the abyss of insolvency through costly wars and unpaid loans.
Can the US *afford* another war?
if ReactOS would adopt a BSD filesystem-to-rule-them-all then ntfs goes the way of the dodo. :-)
Some clever soul then slipstreams that code into your Win8 installer as a root fs driver and world domination ensues.
Cheers. I'm assuming the original instructions were concocted for Sun's proprietary Java ME/SE embedded platforms - AFAIK, none of which supported has made it into phoneME, openjdk.
Maybe if MIPS had 'won' on phones we'd greater synergy e.g. The reverse of NestedVM.
I realise openjdk's is stack-based vm and dalvik is register-based. But aren't they essentially mapping virtual machine instructions to hardware instructions? In a rudimentary manner this was tried a decade ago with Java. It was found that general purpose processors would spank a Java-CPU in performance due to the way that a VM would interact with a JIT instead of processing raw instructions.
[Aside - ARM does include instructions for JVM-like code - Jazelle/ThumbEE. Can/does Dalvik even take advantage ?]
The extent to which this idea can escape from a research lab depends on relative performance. Quite interesting from the power consumption aspect though.
Meh. I'll wait for the Flower Power model.
Perhaps NASA will demand KFC go skin-free by 2015? :-) If the skin is the part of the chicken that retains the most oil when fried, the benefit to the consumer is a healthier product.
Asus are having an each-way bet. Along with the Transformer, there's also the Slider, which includes a slide-out keyboard.
The Transformer, minus keyboard is lighter and more iPad-like. If they can keep the weight and depth down, the slider mechanism is robust and the keyboard doesn't stink, I'd be choose the retractable keyboard that doesn't need attaching. A problem with traditional tablet pcs is that the keyboards get in the way when you don't need them - there's some awkward rotation mechanism to hide the keyboard.
Call me cynical but the whole point of non-upgradeable storage is dictating the supply of internal storage.
Apple has 2 models available on their store for iPad. Wifi only or 3G. Yet they have the 16/32/64GB options - exactly the same computer but at $US100 price increments.