It's entirely beside the point, but there is another workaround route to fast parallel code in the (Firefox) browser, called River Trail: https://github.com/RiverTrail/RiverTrail
Quoting the project wiki: In a world where the web browser is the user’s window into computing, browser applications must leverage all available computing resources to provide the best possible user experience. Today web applications do not take full advantage of parallel client hardware due to the lack of appropriate programming models. River Trail puts the parallel compute power of client’s hardware into the hands of the web developer while staying within the safe and secure boundaries of the familiar JavaScript programming paradigm. As to the real point, which is why these fundamental research results about the 'right way' to do secure distributed systems has been systematically ignored for 40 years or so, let me gently suggest that there are political and sociological issues at stake here, as well as the technical and psychological issues already being discussed. -- Max On Wed, Feb 29, 2012 at 3:09 PM, Alan Kay <alan.n...@yahoo.com> wrote: > Hi Duncan > > The short answers to these questions have already been given a few times > on this list. But let me try another direction to approach this. > > The first thing to notice about the overlapping windows interface > "personal computer experience" is that it is logically independent of the > code/processes running underneath. This means (a) you don't have to have > a single religion "down below" (b) the different kinds of things that might > be running can be protected from each other using the address space > mechanisms of the CPU(s), and (c) you can think about allowing "outsiders" > to do pretty much what they want to create a really scalable really > expandable WWW. > > If you are going to put a "browser app" on an "OS", then the "browser" has > to be a mini-OS, not an app. > > But "standard apps" are a bad idea (we thought we'd gotten rid of them in > the 70s) because what you really want to do is to integrate functionality > visually and operationally using the overlapping windows interface, which > can safely get images from the processes and composite them on the screen. > (Everything is now kind of "super-desktop-publishing".) An "app" is now > just a kind of integration. > > But the route that was actually taken with the WWW and the browser was in > the face of what was already being done. > > Hypercard existed, and showed what a WYSIWYG authoring system for > end-users could do. This was ignored. > > Postscript existed, and showed that a small interpreter could be moved > easily from machine to machine while retaining meaning. This was ignored. > > And so forth. > > 19 years later we see various attempts at inventing things that were > already around when the WWW was tacked together. > > But the thing that is amazing to me is that in spite of the almost > universal deployment of it, it still can't do what you can do on any of > the machines it runs on. And there have been very few complaints about > this from the mostly naive end-users (and what seem to be mostly naive > computer folks who deal with it). > > Some of the blame should go to Apple and MS for not making real OSs for > personal computers -- or better, going the distance to make something > better than the old OS model. In either case both companies blew doing > basic protections between processes. > > On the other hand, the WWW and first browsers were originally done on > workstations that had stronger systems underneath -- so why were they so > blind? > > As an aside I should mention that there have been a number of attempts to > do something about "OS bloat". Unix was always "too little too late" but > its one outstanding feature early on was its tiny kernel with a design that > wanted everything else to be done in "user-mode-code". Many good things > could have come from the later programmers of this system realizing that > being careful about dependencies is a top priority. (And you especially do > not want to have your dependencies handled by a central monolith, etc.) > > So, this gradually turned into an awful mess. But Linus went back to > square one and redefined a tiny kernel again -- the realization here is > that you do have to arbitrate basic resources of memory and process > management, but you should allow everyone else to make the systems they > need. This really can work well if processes can be small and interprocess > communication fast (not the way Intel and Motorola saw it ...). > > And I've also mentioned Popek's LOCUS system as a nice model for migrating > processes over a network. It was Unix only, but there was nothing about his > design that required this. > > Cutting to the chase with a current day example. We made Etoys 15 years > ago so children could learn about math, science, systems, etc. It has a > particle system that allows many interesting things to be explored. > > Windows (especially) is so porous that SysAdmins (especially in school > districts) will not allow teachers to download .exe files. This wipes out > the Squeak plugin that provides all the functionality. > > But there is still the browser and Javascript. But Javascript isn't fast > enough to do the particle system. But why can't we just download the > particle system and run it in a safe address space? The browser people > don't yet understand that this is what they should have allowed in the > first place. So right now there is only one route for this (and a few years > ago there were none) -- and that is Native Client on Google Chrome. > > But Google Chrome is only 13% penetrated, and the other browser fiefdoms > don't like NaCl..... Google Chrome is an .exe file so teachers can't > download it (and if they could, they could download the Etoys plugin). > > Just in from browserland ... there is now -- 19 years later -- an allowed > route to put samples in your machine's sound buffer that works on some of > the browsers. > > Holy cow folks! > > Alan > > > > ------------------------------ > *From:* Duncan Mak <duncan...@gmail.com> > *To:* Alan Kay <alan.n...@yahoo.com>; Fundamentals of New Computing < > fonc@vpri.org> > *Sent:* Wednesday, February 29, 2012 11:50 AM > > *Subject:* Re: [fonc] Error trying to compile COLA > > Hello Alan, > > On Tue, Feb 28, 2012 at 4:30 PM, Alan Kay <alan.n...@yahoo.com> wrote: > > For example, one of the many current day standards that was dismissed > immediately is the WWW (one could hardly imagine more of a mess). > > > I was talking to a friend the other day about the conversations going on > in this mailing list - my friend firmly believes that the Web (HTTP) is one > of the most important innovations in recent decades. > > One thing he cites as innovative is a point that I think TimBL mentions > often: that the Web was successful (and not prior hypertext systems) > because it allowed for broken links. > > Is that really a good architectural choice? If not, is there a reason why > the Web succeeded, where previous hypertext systems failed? Is it only > because of "pop culture"? > > What are the architectural flaws of the current Web? Is there anything > that could be done to make it better, in light of these flaws? > > -- > Duncan. > > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
