Re: [fonc] visual environments created by present/former VPRI staff
On Wed, Mar 30, 2011, John Zabroski wrote: > I am trying to round up all visual programming kit research written by you Does your definition of visual programming include graphical programming (by children)? If so, I imagine you might want to include: Self Tweak TileScript (All had participation of current or former VPRI/Squeak Central staff or contractors. I don't know who were staff and who were contractors.) Hope that helps. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] visual environments created by present/former VPRI staff
John Zabroski wrote: > My understanding* is that Mitch does not want to see Scratch forked Scratch already has "higher ceiling" forks: Build Your Own Blocks and Panther. http://byob.berkeley.edu/ http://inst.eecs.berkeley.edu/~cs10 http://pantherprogramming.weebly.com/ (It seems to me that any graduate student or researcher that takes apart and rebuilds Scratch, Etoys or StarLogo, for example, can help start to map out the possibilities for 21st century visual programming tools and simulation construction kits.) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] OLPC related
The pricing and the processor of Raspberry Pi put it in the league of the XO 1.75. It is an inexpensive platform for the Fedora and Ubuntu communities to compile and run a complete desktop distribution for ARM as dogfood - which is what OLPC needs in the wild. It needs the resources of the West (really the Global North) to make it a programmable device - you need to beg or borrow a keyboard, a USB hub, a mouse, a storage card, (an optional network connection) and a screen with an HDMI input, or a whole computer. So it isn't _really_ as portable as an XO, nor is it quite so easy to play with interesting sensors. I bet it will be a lot less fuss than flashing the boot sector of an Android phone. If I understand the videos on the Raspberry Pi site correctly, it is targetted at creating a new generation of child hackers: the present day equivalent of the bedroom game programmer who used the Sinclair, BBC, TRS-80 or Amiga microcomputers. I guess this meshes with a FONC agenda. It is quite an exciting thing, and my guess is it will sit alongside Sugar on a Stick as a cool way to allow first world kids to have the Sugar / OLPC experience : or even just enjoy viewing the source or hacking with Emacs, Vi, Eclipse, or Squeak. Or, kids who experience it will get motivated to start programming their Android devices. (Also kids could use apt install / yum to turn these tiny boxes into cheap and low power TV game consoles and home media servers.) I am sure those who have been following it longer will have even better ideas. Just my random thoughts. I am getting excited, though I still think netbooks and Arduinos are cooler. Raspberry Pi Foundation is at: http://www.raspberrypi.org/ They have stickers for sale! David ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] OLPC related
Loup Vaillant wrote: > So at least, you can salvage your granma's TV, making the whole set a bit > less expensive. Great news! (I don't think those connectors were in the video I saw on the site.) Thinking over what I wrote last night, I am getting much more excited about the disruptive educational and democratic possibilities of this device. While the builtin sensors of the XO have the appeal of a standard platform to develop for, I remembered that the robotics community has a useful range of USB transducers that makes the Raspberry Pi an interesting robotics processor. There is even this: http://wiki.laptop.org/go/USB_Sensor David ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] History of computing talks at SJSU
John Zabroski wrote: > We have also yet to put into practice languages which limit the client > run-time of an algorithm on a server (assuming the client can > parameterize over the server's service in some disciplined way). > > Solving this problem will eliminate virtually all IT jobs. Thanks for being provocative. In my turn, I think everything but your last sentence is correct. Google engineers have said that a key design parameter for their services is the cost of instructions in kilowatt-hours. So the problem may be less about idle cycles than about wasted cycles such as context switches, inefficient algorithms and compiler optimization. Meanwhile, I suspect servers for interactive services are rarely more than 90% idle. So I would suggest that efficient scheduling and request run-time limits are important economic and environmental problems to solve, but the solutions are unlikely to eliminate many digital tech jobs, as it is unlikely to benefit society by more than the equivalent of two Moore's law doubling cycles. That is a huge prize, but not the end of the world as we know it. My 2 farthings. David ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] OT: Hypertext and the e-book
BGB said: > by contrast, a wiki is often a much better experience, and similarly allows > the option of being presented sequentially (say, by daisy chaining articles > together, and/or writing huge articles). granted, it could be made maybe a > little better with a good WYSIWYG style editing system. > > potentially, maybe, something like MediaWiki or similar could be used for > fiction and similar. Take a look at both Wikibooks and the booki project (which publishes flossmanuals.net) > a mystery is why, say, LCD panels can't be made to better utilize ambient > light Why isn't the wonderful dual-mode screen used by the OLPC XO more widely used? > the one area I think printed books currently have a slight advantage (vs > things like Adobe Reader and similar), is the ability to quickly place > custom bookmarks (would be nice if one could define user-defined bookmarks > in Reader, and if it would remember wherever was the last place the user was > looking in a given PDF). Apple Preview, and perhaps other PDF readers, already do this. Have fun! David ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] collections and rest
I am confused. 100 objects can as easily be created in one transaction as in a hundred transactions, can they not? Are you (John) trying to say that REST has some impact on a client's ability to enclose 100 objects in one transaction? This may be true: I have never tried big transactions over HTTP / REST. If it is, what impact, and how does it relate to FONC? Have fun! David ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] collections and rest
I mistakenly wrote: > I am confused. 100 objects can as easily be created in one transaction > as in a hundred transactions, can they not? ... Please ignore that message, which both represented my misunderstanding of the HTTP PUT method, and did not take into account the full context of the conversation. (I have since found the relevant thread.) Sorry for the noise. Have fun! David ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
