you made the cd experience suck. as a result, the only cds i've bought in the *PAST FIVE YEARS* were imports from small labels. instead, i moved to itunes. you are now attempting to fuck with itunes. if you force your variable pricing scheme through, i can guarantee that i'm going to stop buying any music from you whatsoever. you are a bunch of greedy bastards, as many artists have testified, and i am sick of it.
you don't need white to be the cue. i've seen similar things which cue off motion alone, in which case the camouflage won't help you (other moving things could, however, confuse it). in fact, cueing off motion alone makes things quite a bit easier --- no need to track (pick out the biggest blob of foreground pixels, aim at the middle, fire)
scientists are required to methodically and meticulously document everything. not the case in open source (don't believe me? take a look at opencv, gtkmm, etc.) some projects do a really excellent job (the gnu tools, in general, are documented well. qt has really great docs, as does kde), but the vast majority of the packages i've worked with don't.
if open source folks documented to the same level of rigor and completeness that scientists are held to, about 60% of my gripes with open source would go away. if open source folks were held to the same standards in terms of experimental protocol, precision, accuracy, and repeatability, the remaining 40% would also go away.
thanks for saying that. i suspect you'll be flamed heartily, but i'm pretty damn convinced you've nailed the problem.
case in point: octave. it does about 80% of what i need. fixing the remaining 20% will require about a man year's worth of effort, if not more. matlab (the tool that octave is trying to clone) plus relevant tool kits costs roughly 30 hours of my time.
opencv is particularly galling in this: the documentation covers maybe 15% of the total api, the headers have very few comments, the source code itself is cryptic in the extreme, and in spite of being given a "generic" image type, algorithms are very much married to the type of the underlying pixel and number of bands in the image.
the most frustrating part to me is that so many of these packages are 80-90% there, and the remaining portion/shouldn't/ be hard. if, after 8+ hours at the office working on this stuff, i still had the inclination to fix things, i would. but after a long day at work, i don't want to see a computer, never mind fight with code.
dual g5 @ 2.7GHz, 4+GB RAM, dual monitors (probably dual 23" cinema displays), fast external storage for backups (a g5 raid w/ fibre channel or an external firewire b raid enclosure).
software wise: matlab with all the relevant toolkits, maple, emacs (there are worse bad habits to have), xcode, office, omnigraffle, virtual pc with whatever the latest visual studio is and intel's c++ compiler, ibm's misc. compilers for power pc, a nice l-shaped desk with at least one and more likely two big whiteboards within easy viewing distance/orientation, appropriate storage for books, network drop + kvm for a laptop, suitable seating and deskspace for at least one other person, lots of power outlets, at least one switch (gige), suitable cable storage, integrated firewire and usb drops + hubs/switches. a couple lab power supplies and at least two of every kind of rca / coax / svideo / etc. cable and converter. plus a east german border patrol guard to severly maim anyone who attempts to walk off with my cables or converters without asking me first;-) a dv camera would be good, too. a comfortable roll-y chair that can recline, ms natural keyboard (bonus for wireless / bluetooth), and probably the mighty mouse that apple's so worked up over.
then again, i do slightly different work than you do;-)
intro. to parallel computation is known as one of the nightmare master's level classes (the sort of class that most folks only took because they were either a] utter masochists, b] far too clever, or c] didn't have any other choices) at my alma mater. i kinda fell into all three of those categories and ended up doing pretty well. the question you asked is one that my prof posed to us our first night of class and one that came back to haunt us almost every class thereafter (and certainly on the final)...
anyways, it's a good question to ask --- shows you're at least thinking about things. ultimately, clusters will have such low latencies that they'll move in the direction you're talking about --- distributed-but-sufficiently-low-latency-that-we'l l-pretend-that-it's-a-single-ram. until then, we're still stuck with MPI and friends...
a nit to pick: java has threading built in as a primitive. this is something java takes advantage of when using javaspaces, jini, and jxta. that said, you still suffer the issues imposed by network topologies in a distributed memory multiprocessor.
pick an algorithm (say matrix multiply). write the fastest possible serial implementation you can (hint: you can do better than O(n^3)). then implement a parallel matrix multiply using MPI. now make the parallel one run as fast as possible.
i can guarantee that the serial algorithm is about a day's worth of effort to implement; however, the parallel one will require at least a week. as you start working through the parallel implementation, you'll quickly discover that all the things that are true in a shared memory multiprocessor are no longer true in a distributed memory multiprocessor. you'll quickly appreciate the communication costs and overheads imposed by the cluster. you'll also appreciate just how much of a bitch attempting to debug parallel programs is (where did stdout go? depends on your MPI implementation... whee!). topology also becomes a major factor: parallel sorts which are efficient on toroidal grid topologies are no longer efficient on hypercubes, and vice versa.
don't fix it. *ESPECIALLY* if you don't know what you're doing.
allow me to don my flame proof suit before continuing.
i'll start with a little example to illustrate. i do a lot of prototyping of image processing algorithms. typically, this is done in matlab ($$$ and then some); however, the powers that be are not willing to buy a copy of matlab at present. i am therefore forced to work with octave. octave does about 80% of what i need. unfortunately, the remaining 20% is incredibly painful. i did a little number crunching and came to the conclusion that in my company, a matlab license needs to save between 20 to 30 hours of effort in a year before it's paid for itself. given that i spent two solid weeks reimplementing functionality already in matlab or fixing octave's less-than-stellar implementations of certain things i use on a regular basis, a copy of matlab would have paid for itself twice over.
this isn't a big deal if all you're doing is switching your servers to linux. if you set things up correctly, your users should never even notice. however, once you start talking about replacing the tools that get used on a daily basis you've got a big challenge on your hands. ask yourself this: how much will switching to linux cost in terms of lost productivity? the cost is non-trivial. if the cost per worker per year is greater than the cost of your current setup per worker per year, sticking with the m$ products makes the most business sense.
... why everyone is harping on about where the compressed gas comes from. i don't imagine that it would be very hard to design a steam based compressor to drive the thing. heck, you could use livestock to power it during the day and rely on really good insulation at night to keep things cold. near a source of flowing water? fantastic — use that current.
i was thinking more along the lines of, "and i am a dogmatic jerk who is not willing to entertain the notion that a closed source option may well be better suited to what i am trying to do."
i would not have my current job if i hadn't worked my ass off taking the extra theory and math classes. i end up using almost all my math and ai classwork on a daily basis. the stuff i did in my os and networking classes also come back to haunt me on a fairly regular basis (which is pretty damn galling --- i despised those classes, but i did well in them anyways). i find myself regretting the fact that i didn't do any ee beyond my required digital logic class on an almost daily basis (so much so that i'm looking around at local universities to see about maybe starting a part time m.s. in ee). then again, i teach robots how to see — i'm pretty convinced that i have about the most awesome job ever (the only way it could be more awesome is if i had the budget and what not to research and develop whatever took my fancy).
so, in summary: if you'd like a job that's easily off-shorable, take dan's advice. if you'd like career that keeps you excited and has you in a position to solve challenging problems on a daily basis, you're going to need a different plan.
or those could be the natural market corrections and lucky timing.
you do make a fair point re: spending versus income. you are correct in that my major issue is not so much with the amount of cash being spent as with the deficit being racked up.
... white and male and heterosexual and well off are all going to have to get used to the idea that for the next several years, we are all going to collectively be sodomized with large cacti.
people tell me why i lament rehnquist's passing. the answer is simple: 1) he is a human being, 2) while he was conservative, his likely replacements make him look like a hippy by comparison, 3) not only has bush's tax cuts and utterly irresponsible fiscal policy ensured that we will be feeling the sting of his tax cuts for many,/many/ years to come, his judicial appointments will last even longer. prepare to be raped from both ends.
octave needs a hell of a lot of work. some suggestions:
1) a non-sucky plotting interface (there are some packages which claim to do just this, but i can't get bloody VTK to compile, so they're basically useless)
2) an optimization engine for octave
3).oct functions which can read a multitude of image formats, write a multitude of image formats, display images, implement the equivalent of ginput, and provide the basic functionality of the image processing toolkit (if you pick this and do a good job, i will buy you dinner). what meagre image processing functions octave has all fork off a copy of imagemagick, which is *painfully* slow
4).oct functions to read and create movies (possibly as part of #3)
all of these projects demonstrate several key skills: good c++, good matlab, and the fundamentals of engineering with existing code.
other suggestions:
5) something like mtl (matrix template library, c++ code which uses expression templates and what not to try to help the compiler produce optimized code) that doesn't suck (their lu factorization produced plain/wrong/ results last time i used it). major bonus points for implementing matrix factorizations, and eigendecompositions
6) fix gnu's binutils so that they can use libraries generated by VC++
7) an optimized c++ toolkit for developing digital video processing and computer vision software under linux. i envision this as a kind of directshow lite --- you'd supply standard interfaces and a set of plugins providing basic transforms (color space conversions, for example), thread pools, and a nice gui to edit processing graphs and run them
incidentally, most of these things have been on my todo list for a long time. i think i'm going to crack at least the image reading and display portion of #4 over labor day weekend.
1) i try to avoid active sensing wherever possible. sonar (and, i suspect, ultrasonics too) have the same problems that gps has: multiple returns. there are tricks you can use to try to limit those (phase modulation, frequence modulation, and so on), the problem is that in sonar those problems are only exacerbated by the incredibly complex geometry to man made environments. as i pointed out, sonar in shallow waters has this same problem.
there is also a question of what happens when you attempt to build a team of collaborative robots using active sensing. you either have to be very careful about tuning their sensors so that they don't get confused when they're near each other or you have to limit your use of active sensing to only when other robots aren't close enough to get confused.
2) EO/IR imagery can alse be used to compute more than 3D information. we use it to do terrain classification on an (almost) daily basis.
3) doesn't work for my applications, or any application where you have an actuated vehicle moving at highway speeds. this is (plus uavs) is where the bulk of my work is done.
4) you are correct in that it does depend on my application. the technology that i build may, eventually, be incorporated into high end vehicles, but i doubt that it will ever be a part of a consumer electronic product. however, if it ever does get incorporated into consumer electronics, the interference issues that i described earlier will become even more of a problem (imagine if every furrby sold had a sonar in it!)
i do not disagree that bats prove that sonar / echolocation can be useful; however, the current state of sonar leaves a great deal to be desired. once vendors are able to deliver sonar units which offer the same kind of performance that other ranging and visual phenomenologies offer with significant utility (either for cheap, magnitudes easier to process, magnitudes lighter / smaller, etc.) i will gladly incorporate sonar into whatever sensor suites i'm using. that said, i'm not holding my breath.
1) it's an active sensing modality (unless you've got a really bigass submarine with phased passive sonar arrays and a huge baseline, you're not going to get any range data out of the thing passively).
2) it's really damn tricky to process properly. sonar tends to fail in littoral waters because of multipath, echos, etc. in man made environments, the multipath + echo issues become really damn hard to solve without some good 3D models of the world around you (but if you can build those models, why bother with the sonar?)
3) signal to noise ratios are killer. this coupled with the innate difficulties in processing sonar/anyways/ pretty much seal the deal.
4) compared to other sensing modalities for non-aquatic environments, sonar just can't compete. if you have a single, calibrated camera and know its pose relative to the ground, you can calculate the exact position of any object on the ground. (more generally: if you know the pose of the camera relative to a known plane, you can precisely determine the position of any point on that plane up to what the camera's resolution will allow) if you have a stereo head, things get a lot more interesting (you can combine stereo imaging with structure from motion and get some highly accurate ranges).
that all said, if this research can solve those problems, i know i will gladly use their sonar / echolocation stuff (it can't be blinded by the sun, unlike ladars, although both will have major issues with rain).
you shell out $45-60 for the game, plus $10-15/mo to play and then they shove advertising down your throat?
how long until ms adds this as a "feature" to office? apparently the new aim client already includes monstrously obtrusive advertising in im windows, so i can't imagine that it will be too long before the less scrupulous software vendors out there insist on interrupting your work every ten minutes with a full screen ad....
do they have enough business in the embedded sector that this isn't going to hurt them, or has apple's move to intel basically screwed them beyond hope of recovery?
in order to make it to the qualifying round, your vehicle must show path following abilities and obstacle avoidance. the darpa guys tested this during the site visits by placing some obstacles on the way points (gps coordinates) and some near way points. so, to answer your question: it should handle arbitrary, unknown obstacles. that said, they may well incorporate a priori knowledge of the course into their control.
this is all about the laptop market. you can't upgrade the display on a laptop, thus, to play this content your choices are: 1) buy a new laptop ($ for bill from the longhorn license and dell+intel than you for your support), 2) be screwed.
Slashdot Mirror
you made the cd experience suck. as a result, the only cds i've bought in the *PAST FIVE YEARS* were imports from small labels. instead, i moved to itunes. you are now attempting to fuck with itunes. if you force your variable pricing scheme through, i can guarantee that i'm going to stop buying any music from you whatsoever. you are a bunch of greedy bastards, as many artists have testified, and i am sick of it.
you don't need white to be the cue. i've seen similar things which cue off motion alone, in which case the camouflage won't help you (other moving things could, however, confuse it). in fact, cueing off motion alone makes things quite a bit easier --- no need to track (pick out the biggest blob of foreground pixels, aim at the middle, fire)
let's continue your analogy:
scientists are required to methodically and meticulously document everything. not the case in open source (don't believe me? take a look at opencv, gtkmm, etc.) some projects do a really excellent job (the gnu tools, in general, are documented well. qt has really great docs, as does kde), but the vast majority of the packages i've worked with don't.
if open source folks documented to the same level of rigor and completeness that scientists are held to, about 60% of my gripes with open source would go away. if open source folks were held to the same standards in terms of experimental protocol, precision, accuracy, and repeatability, the remaining 40% would also go away.
thanks for saying that. i suspect you'll be flamed heartily, but i'm pretty damn convinced you've nailed the problem.
/shouldn't/ be hard. if, after 8+ hours at the office working on this stuff, i still had the inclination to fix things, i would. but after a long day at work, i don't want to see a computer, never mind fight with code.
case in point: octave. it does about 80% of what i need. fixing the remaining 20% will require about a man year's worth of effort, if not more. matlab (the tool that octave is trying to clone) plus relevant tool kits costs roughly 30 hours of my time.
opencv is particularly galling in this: the documentation covers maybe 15% of the total api, the headers have very few comments, the source code itself is cryptic in the extreme, and in spite of being given a "generic" image type, algorithms are very much married to the type of the underlying pixel and number of bands in the image.
the most frustrating part to me is that so many of these packages are 80-90% there, and the remaining portion
money is no object you say? *grin*
;-) a dv camera would be good, too. a comfortable roll-y chair that can recline, ms natural keyboard (bonus for wireless / bluetooth), and probably the mighty mouse that apple's so worked up over.
;-)
dual g5 @ 2.7GHz, 4+GB RAM, dual monitors (probably dual 23" cinema displays), fast external storage for backups (a g5 raid w/ fibre channel or an external firewire b raid enclosure).
software wise: matlab with all the relevant toolkits, maple, emacs (there are worse bad habits to have), xcode, office, omnigraffle, virtual pc with whatever the latest visual studio is and intel's c++ compiler, ibm's misc. compilers for power pc, a nice l-shaped desk with at least one and more likely two big whiteboards within easy viewing distance/orientation, appropriate storage for books, network drop + kvm for a laptop, suitable seating and deskspace for at least one other person, lots of power outlets, at least one switch (gige), suitable cable storage, integrated firewire and usb drops + hubs/switches. a couple lab power supplies and at least two of every kind of rca / coax / svideo / etc. cable and converter. plus a east german border patrol guard to severly maim anyone who attempts to walk off with my cables or converters without asking me first
then again, i do slightly different work than you do
intro. to parallel computation is known as one of the nightmare master's level classes (the sort of class that most folks only took because they were either a] utter masochists, b] far too clever, or c] didn't have any other choices) at my alma mater. i kinda fell into all three of those categories and ended up doing pretty well. the question you asked is one that my prof posed to us our first night of class and one that came back to haunt us almost every class thereafter (and certainly on the final)...
l l-pretend-that-it's-a-single-ram. until then, we're still stuck with MPI and friends...
anyways, it's a good question to ask --- shows you're at least thinking about things. ultimately, clusters will have such low latencies that they'll move in the direction you're talking about --- distributed-but-sufficiently-low-latency-that-we'
a nit to pick: java has threading built in as a primitive. this is something java takes advantage of when using javaspaces, jini, and jxta. that said, you still suffer the issues imposed by network topologies in a distributed memory multiprocessor.
you managed to communicate what i was attempting to in a far more succinct way than i managed to.
pick an algorithm (say matrix multiply). write the fastest possible serial implementation you can (hint: you can do better than O(n^3)). then implement a parallel matrix multiply using MPI. now make the parallel one run as fast as possible.
i can guarantee that the serial algorithm is about a day's worth of effort to implement; however, the parallel one will require at least a week. as you start working through the parallel implementation, you'll quickly discover that all the things that are true in a shared memory multiprocessor are no longer true in a distributed memory multiprocessor. you'll quickly appreciate the communication costs and overheads imposed by the cluster. you'll also appreciate just how much of a bitch attempting to debug parallel programs is (where did stdout go? depends on your MPI implementation... whee!). topology also becomes a major factor: parallel sorts which are efficient on toroidal grid topologies are no longer efficient on hypercubes, and vice versa.
don't fix it. *ESPECIALLY* if you don't know what you're doing.
allow me to don my flame proof suit before continuing.
i'll start with a little example to illustrate. i do a lot of prototyping of image processing algorithms. typically, this is done in matlab ($$$ and then some); however, the powers that be are not willing to buy a copy of matlab at present. i am therefore forced to work with octave. octave does about 80% of what i need. unfortunately, the remaining 20% is incredibly painful. i did a little number crunching and came to the conclusion that in my company, a matlab license needs to save between 20 to 30 hours of effort in a year before it's paid for itself. given that i spent two solid weeks reimplementing functionality already in matlab or fixing octave's less-than-stellar implementations of certain things i use on a regular basis, a copy of matlab would have paid for itself twice over.
this isn't a big deal if all you're doing is switching your servers to linux. if you set things up correctly, your users should never even notice. however, once you start talking about replacing the tools that get used on a daily basis you've got a big challenge on your hands. ask yourself this: how much will switching to linux cost in terms of lost productivity? the cost is non-trivial. if the cost per worker per year is greater than the cost of your current setup per worker per year, sticking with the m$ products makes the most business sense.
... why everyone is harping on about where the compressed gas comes from. i don't imagine that it would be very hard to design a steam based compressor to drive the thing. heck, you could use livestock to power it during the day and rely on really good insulation at night to keep things cold. near a source of flowing water? fantastic — use that current.
oh. wait. i'm thinking rationally again.
i was thinking more along the lines of, "and i am a dogmatic jerk who is not willing to entertain the notion that a closed source option may well be better suited to what i am trying to do."
:)
but i like yours too
"readers, i am starting my own adult entertainment site on the cheap."
i would not have my current job if i hadn't worked my ass off taking the extra theory and math classes. i end up using almost all my math and ai classwork on a daily basis. the stuff i did in my os and networking classes also come back to haunt me on a fairly regular basis (which is pretty damn galling --- i despised those classes, but i did well in them anyways). i find myself regretting the fact that i didn't do any ee beyond my required digital logic class on an almost daily basis (so much so that i'm looking around at local universities to see about maybe starting a part time m.s. in ee). then again, i teach robots how to see — i'm pretty convinced that i have about the most awesome job ever (the only way it could be more awesome is if i had the budget and what not to research and develop whatever took my fancy).
so, in summary: if you'd like a job that's easily off-shorable, take dan's advice. if you'd like career that keeps you excited and has you in a position to solve challenging problems on a daily basis, you're going to need a different plan.
or those could be the natural market corrections and lucky timing.
you do make a fair point re: spending versus income. you are correct in that my major issue is not so much with the amount of cash being spent as with the deficit being racked up.
... white and male and heterosexual and well off are all going to have to get used to the idea that for the next several years, we are all going to collectively be sodomized with large cacti.
/many/ years to come, his judicial appointments will last even longer. prepare to be raped from both ends.
people tell me why i lament rehnquist's passing. the answer is simple: 1) he is a human being, 2) while he was conservative, his likely replacements make him look like a hippy by comparison, 3) not only has bush's tax cuts and utterly irresponsible fiscal policy ensured that we will be feeling the sting of his tax cuts for many,
octave needs a hell of a lot of work. some suggestions:
.oct functions which can read a multitude of image formats, write a multitude of image formats, display images, implement the equivalent of ginput, and provide the basic functionality of the image processing toolkit (if you pick this and do a good job, i will buy you dinner). what meagre image processing functions octave has all fork off a copy of imagemagick, which is *painfully* slow
.oct functions to read and create movies (possibly as part of #3)
/wrong/ results last time i used it). major bonus points for implementing matrix factorizations, and eigendecompositions
1) a non-sucky plotting interface (there are some packages which claim to do just this, but i can't get bloody VTK to compile, so they're basically useless)
2) an optimization engine for octave
3)
4)
all of these projects demonstrate several key skills: good c++, good matlab, and the fundamentals of engineering with existing code.
other suggestions:
5) something like mtl (matrix template library, c++ code which uses expression templates and what not to try to help the compiler produce optimized code) that doesn't suck (their lu factorization produced plain
6) fix gnu's binutils so that they can use libraries generated by VC++
7) an optimized c++ toolkit for developing digital video processing and computer vision software under linux. i envision this as a kind of directshow lite --- you'd supply standard interfaces and a set of plugins providing basic transforms (color space conversions, for example), thread pools, and a nice gui to edit processing graphs and run them
incidentally, most of these things have been on my todo list for a long time. i think i'm going to crack at least the image reading and display portion of #4 over labor day weekend.
1) i try to avoid active sensing wherever possible. sonar (and, i suspect, ultrasonics too) have the same problems that gps has: multiple returns. there are tricks you can use to try to limit those (phase modulation, frequence modulation, and so on), the problem is that in sonar those problems are only exacerbated by the incredibly complex geometry to man made environments. as i pointed out, sonar in shallow waters has this same problem.
there is also a question of what happens when you attempt to build a team of collaborative robots using active sensing. you either have to be very careful about tuning their sensors so that they don't get confused when they're near each other or you have to limit your use of active sensing to only when other robots aren't close enough to get confused.
2) EO/IR imagery can alse be used to compute more than 3D information. we use it to do terrain classification on an (almost) daily basis.
3) doesn't work for my applications, or any application where you have an actuated vehicle moving at highway speeds. this is (plus uavs) is where the bulk of my work is done.
4) you are correct in that it does depend on my application. the technology that i build may, eventually, be incorporated into high end vehicles, but i doubt that it will ever be a part of a consumer electronic product. however, if it ever does get incorporated into consumer electronics, the interference issues that i described earlier will become even more of a problem (imagine if every furrby sold had a sonar in it!)
i do not disagree that bats prove that sonar / echolocation can be useful; however, the current state of sonar leaves a great deal to be desired. once vendors are able to deliver sonar units which offer the same kind of performance that other ranging and visual phenomenologies offer with significant utility (either for cheap, magnitudes easier to process, magnitudes lighter / smaller, etc.) i will gladly incorporate sonar into whatever sensor suites i'm using. that said, i'm not holding my breath.
sonar does, indeed, suck. and not in the fun way.
/anyways/ pretty much seal the deal.
why, you ask?
1) it's an active sensing modality (unless you've got a really bigass submarine with phased passive sonar arrays and a huge baseline, you're not going to get any range data out of the thing passively).
2) it's really damn tricky to process properly. sonar tends to fail in littoral waters because of multipath, echos, etc. in man made environments, the multipath + echo issues become really damn hard to solve without some good 3D models of the world around you (but if you can build those models, why bother with the sonar?)
3) signal to noise ratios are killer. this coupled with the innate difficulties in processing sonar
4) compared to other sensing modalities for non-aquatic environments, sonar just can't compete. if you have a single, calibrated camera and know its pose relative to the ground, you can calculate the exact position of any object on the ground. (more generally: if you know the pose of the camera relative to a known plane, you can precisely determine the position of any point on that plane up to what the camera's resolution will allow) if you have a stereo head, things get a lot more interesting (you can combine stereo imaging with structure from motion and get some highly accurate ranges).
that all said, if this research can solve those problems, i know i will gladly use their sonar / echolocation stuff (it can't be blinded by the sun, unlike ladars, although both will have major issues with rain).
you shell out $45-60 for the game, plus $10-15/mo to play and then they shove advertising down your throat?
how long until ms adds this as a "feature" to office? apparently the new aim client already includes monstrously obtrusive advertising in im windows, so i can't imagine that it will be too long before the less scrupulous software vendors out there insist on interrupting your work every ten minutes with a full screen ad....
do they have enough business in the embedded sector that this isn't going to hurt them, or has apple's move to intel basically screwed them beyond hope of recovery?
what else would geeks partner with?
in order to make it to the qualifying round, your vehicle must show path following abilities and obstacle avoidance. the darpa guys tested this during the site visits by placing some obstacles on the way points (gps coordinates) and some near way points. so, to answer your question: it should handle arbitrary, unknown obstacles. that said, they may well incorporate a priori knowledge of the course into their control.
this is all about the laptop market. you can't upgrade the display on a laptop, thus, to play this content your choices are: 1) buy a new laptop ($ for bill from the longhorn license and dell+intel than you for your support), 2) be screwed.
bastards.
didn't they already do this?
oh wait, that was internet exploder...