andylim writes "At EclipseCon 2010 attendees were challenged to create a robotic control system to drive a NASA-provided robot across a prototypical Mars landscape. To win the EclipseCon e4-rover Mars challenge, developers could either prove their e4 programming skills by creating the best e4-Rover client, or use an e4 client to operate the Rover through a series of tasks to collect points. Software architects Peter Friese and Heiko Behrens built an iPhone client for the EclipseCon challenge which controls the robot around NASA's Mars landscape using the iPhone's accelerometer."

Krishna Dagli writes to tell us of an investigation, by Michael Sutton, attempting to get an estimate of how widespread SQL-injection vulnerabilities are among Web sites. Sutton made clever use of the Google API to turn up candidate vulnerable sites. You might quibble with his methodology (some posters on the blog site do), but he found that around 11% of sites are potentially vulnerable to SQL injection attacks. He believes the causes for this somewhat alarming situation include development texts that teach programmers insecure SQL syntax, and point-and-click tools that allow the untrained to put up database-backed sites.

derek_farn writes, "Google now has a page that supports source code searching. I hope they extend it to be more programming-language aware (e.g., search for identifiers and functions) like the specialist code search sites (Krugle, Koders, and Codease), who probably now have very worried investors. I don't see any option to search for Cobol. I guess there is not a lot of Cobol source available on the Internet, even although there is supposed to be more Cobol source in existence than any other language (perhaps that statement is not true in the noughties)." From the Cnet.com article: "Google engineers, many of whom participate in open-source projects, already use these code searching capabilities internally. Since it is a Google Labs project, the company is not yet seeking to monetize searches through ads."

Carla Schroder writes "IPv6 is halfway here, so network administrators need to learn their way around it whether they want to or not. Adoption has been slower in the United States because we possess the lion's share of IPv4 addresses, but even so, someday IPv4 is going away for good. And, there is more to it than just increasing the pool of available addresses. IPv6 has enough improvements over IPv4 to make it worth the change even if we weren't running out of IPV4 addresses, such as built-in IPSec, simplified routing and administration, and scalability that IPv4 simply can't support. We're moving into gigabyte and multi-gigabyte backbones, and high-demand real-time services like voice-over-IP and streaming audio and video that require sophisticated QoS (quality of service) and bandwidth prioritization. IPv6 can handle these, IPv4 can't." Read on for the rest of Carla's review.