On 7/26/2011 5:34 AM, Igor Stasenko wrote:
On 26 July 2011 05:21, Alan Kay<alan.n...@yahoo.com> wrote:
Again good points.
Java itself could have been fixed if it were not for the Sun marketing
people who rushed "the electronic toaster language" out where it was not fit
to go. Sun was filled with computerists who knew what they were doing, but
it was quickly too late.
And you are right about Mark Miller.
My complaint is not about JS per se, but about whether it is possible to get
all the cycles the computer has for certain purposes. One of the main
unnecessary violations of the spirit of computing in the web is that it
wasn't set up to allow safe access to the whole machine -- despite this
being the goal of good OS design since the mid-60s.
Indeed. And the only lucky players in the field who can access raw
machine power is plugins like Flash.
And only because they gained enough trust as being "well safe".
As for the rest of developers (if they are not using existing
mechanisms in browser) the computer's resources still closed behind
solid fence.
Another interesting fact that while we having a hardware which can do
virtualization (not saying about software),
the only application of it which adopted widely is to run one
operating system inside another, host one.
But hey, things could be much more lightweight!
For instance , look at SqueakNOS project. Its boot time is like 10-15
seconds (and most of it not belongs to SqueakNOS itself but to bios
and boot loader).
So, it remains a mystery to me, why we cannot use web+virtualization.
It seems like a good balance between accessing raw machine power and
being safe at the same time.
I hope that NaCl partly using it , but then i wonder why they spending
an effort to validate native code, because if something vent wrong,
you can just kill it or freeze it (or do anything which virtualization
allow you to do),
without any chance of putting host system in danger.
because NaCl was not built on virtualization... from what I heard it was
built on using segmented memory.
the problem then is that unverified code could potentially far-pointer
its way right out of the sandbox.
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
