A related but more general question: When people talk of bits of infrastructure being connected or disconnected from the Internet, are they talking about the presence of direct, layer 3 connectivity (can I ping the airport's tracking systems?), any layer (if I hack the contracting company's intranet can I view aircraft positions through a series of proxies and application layers?) or actual electronic disconnection from the Internet (can you get only get in via getting your man on the inside the tweet the secrets from his cell)?
Distributed infrastructural systems communicate Somehow...
"Just come to the site and begin using the application."
That was the idea behind a techdemo/test game that a friend of mine and I made. AjaxWar, inspired by Wil Wright's SimWar, uses only javascipt on the client side to produce an N-players in N-games, bandwidth concious, non-polling, visually interesting (although most effects were disabled for the demo), robust, realtime strategy game. In the demo, the two browser windows are shown side by side but could have been behind NAT, firewall, proxies, etc on completely different networks than the server and each other. Oh, sorry, I know the demo requires flash (the real game required some modifications to php on the server side that we didn't want to make on a public web server).
Now, enough showing off. The thing we realized by the time we stopped working on the game is that doing things like making pretty multiplayer games with complex IO patterns is something thats really a lot easier, and more predictable using something like Flash or Java. It kinda felt like we were programming in a hostile atmosphere where you can't breathe without a helmet -- I mean can't get data pushed from the server unless you had a multipart encoded stream hanging in the ready. The latency was not bad at all, and neither was throughput of large chunks of data, however we reached a bottleneck when experimenting with several small updates in a short amount of time -- we couldn't reset our transfer mechanism fast enough to make something like an FPS viable at all. A majority of our time was spent expermenting with methods of moving data from the client to the server, politely, asynchronously, quickly, the actual gameplay was mostly an afterthought. While there aren't many web applications that demand the kind of IO we wanted, the pipe to the server is going to be a limiting factor for Ajax-ONLY type applications. Sure, you can use sockets in javascript if you require a certain browser and make the user click ok to a dialog, but if you have them doing that, you might as well have them install Flash. This issue of plumbing needs to be resolved before smart-client apps become ubiquitous.
Thats quite a bit of Amperage, my friend.
My results:
# normal operation, not plugged in (same as 2^62-2055)
Amperage: 18446744073709549561
# just plugged in (says Calculating)
Amperage: 0
# juicing up from the wall
Amperage: 2647
# just unplugged (Calculating again)
Amperate: 0
# full brightness backlight
Current: 1496
# no backlight, hmm
Current: 1484
# guess my battery is pretty healty
Capacity: 4468
AbsoluteMaxCapacity: 4400
About 75% of the time in my phone interview for an internship with the NASA Ames Research Center Intelligent Robotics group was spent discussing a project I had been doing with one of my professors at UCSC for free.
I'm doing an internship at NASA Ames Research Center in the Intelligent Robotics group, while I'm a first year Ph.D. student, I work with several high school students in the group. One is working on integratin g an open source speech-to-text and text-to-speech engine into a larger system designed to facilitate humans and robots working together. Another is developing a joystick control application for a nifty 8-legged robot. There are a few more who are working on things I might not be able to mention. They'll give you a project that challenges your skills (often half of the skills you'll need for the project you'll learn while you are there) and they provide excellent guidance when you need it.
http://server-mpo.arc.nasa.gov/Services/eap/About/ associate.tml
If you think you're good, they'll find something hard enough to challenge you.
Though I'm sure it would violate the ToS of whatever you subscribe to, sharing your connection with a neighbor (especially if they are a just-teh-email type) is a simple, effective, and mutually beneficial way to trade bandwidth for cost without waiting for the larger market to make it happen.
Its all fun and games until... someone combines the two and makes a fun game. Here are from stats from a match in a wardriving game my friends and I ran a few years ago: http://web.archive.org/web/20040210184050/www.driv ebyctf.com/stats.php?game=6
Instructions here (archive.org, sorry, I'm poor).
Required a strong hand at the wheel and a keen ear on the midi blips for signal -- four laptops in each car and a lot of fun.
Slashdot Mirror
The project treats game design as a math/science discovery problem where hypotheses must be created and tested via concrete games.
A related but more general question: When people talk of bits of infrastructure being connected or disconnected from the Internet, are they talking about the presence of direct, layer 3 connectivity (can I ping the airport's tracking systems?), any layer (if I hack the contracting company's intranet can I view aircraft positions through a series of proxies and application layers?) or actual electronic disconnection from the Internet (can you get only get in via getting your man on the inside the tweet the secrets from his cell)? Distributed infrastructural systems communicate Somehow...
If we just blurred all maps, the terrorists couldn't even find their targets!
Funny you mention that, I've already blurred all the maps. Enjoy: http://www.adamsmith.as/blurry_maps/
"Just come to the site and begin using the application."
That was the idea behind a techdemo/test game that a friend of mine and I made. AjaxWar, inspired by Wil Wright's SimWar, uses only javascipt on the client side to produce an N-players in N-games, bandwidth concious, non-polling, visually interesting (although most effects were disabled for the demo), robust, realtime strategy game. In the demo, the two browser windows are shown side by side but could have been behind NAT, firewall, proxies, etc on completely different networks than the server and each other. Oh, sorry, I know the demo requires flash (the real game required some modifications to php on the server side that we didn't want to make on a public web server).
Now, enough showing off. The thing we realized by the time we stopped working on the game is that doing things like making pretty multiplayer games with complex IO patterns is something thats really a lot easier, and more predictable using something like Flash or Java. It kinda felt like we were programming in a hostile atmosphere where you can't breathe without a helmet -- I mean can't get data pushed from the server unless you had a multipart encoded stream hanging in the ready. The latency was not bad at all, and neither was throughput of large chunks of data, however we reached a bottleneck when experimenting with several small updates in a short amount of time -- we couldn't reset our transfer mechanism fast enough to make something like an FPS viable at all. A majority of our time was spent expermenting with methods of moving data from the client to the server, politely, asynchronously, quickly, the actual gameplay was mostly an afterthought. While there aren't many web applications that demand the kind of IO we wanted, the pipe to the server is going to be a limiting factor for Ajax-ONLY type applications. Sure, you can use sockets in javascript if you require a certain browser and make the user click ok to a dialog, but if you have them doing that, you might as well have them install Flash. This issue of plumbing needs to be resolved before smart-client apps become ubiquitous.
Excellent link!
Thats quite a bit of Amperage, my friend. My results: # normal operation, not plugged in (same as 2^62-2055) Amperage: 18446744073709549561 # just plugged in (says Calculating) Amperage: 0 # juicing up from the wall Amperage: 2647 # just unplugged (Calculating again) Amperate: 0 # full brightness backlight Current: 1496 # no backlight, hmm Current: 1484 # guess my battery is pretty healty Capacity: 4468 AbsoluteMaxCapacity: 4400
About 75% of the time in my phone interview for an internship with the NASA Ames Research Center Intelligent Robotics group was spent discussing a project I had been doing with one of my professors at UCSC for free.
I'm doing an internship at NASA Ames Research Center in the Intelligent Robotics group, while I'm a first year Ph.D. student, I work with several high school students in the group. One is working on integratin g an open source speech-to-text and text-to-speech engine into a larger system designed to facilitate humans and robots working together. Another is developing a joystick control application for a nifty 8-legged robot. There are a few more who are working on things I might not be able to mention. They'll give you a project that challenges your skills (often half of the skills you'll need for the project you'll learn while you are there) and they provide excellent guidance when you need it./ associate.tml
http://server-mpo.arc.nasa.gov/Services/eap/About
If you think you're good, they'll find something hard enough to challenge you.
Heres a transcript of my chat with a scammer on Y! messenger. We had been talking via email for about a week. http://adamsmith.as/typ0/crack.txt
Though I'm sure it would violate the ToS of whatever you subscribe to, sharing your connection with a neighbor (especially if they are a just-teh-email type) is a simple, effective, and mutually beneficial way to trade bandwidth for cost without waiting for the larger market to make it happen.
Its all fun and games until... someone combines the two and makes a fun game. Here are from stats from a match in a wardriving game my friends and I ran a few years ago: http://web.archive.org/web/20040210184050/www.driv ebyctf.com/stats.php?game=6
Instructions here (archive.org, sorry, I'm poor).
Required a strong hand at the wheel and a keen ear on the midi blips for signal -- four laptops in each car and a lot of fun.