Actually, we can do great particle systems with the shader language for WebGL. This is a kind of native client mode expressed as a kind of SIMD, with even better performance than star-squeak had. The reality is still that a great algorithm will still win, especially when coupled with strategically defined performance enhancements, as Squeak was. I agree that NaCl is a revolution about to happen and we are in a very exciting time,
David On Wed, Feb 29, 2012 at 6: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
