My Profile
Active Members
TodayLast 7 Days
more...
Awards & Gifts
Online Exams
Fresher Jobs
Our fresher job section is exclusively for fresh graduates! Find jobs for freshers in major Indian
cities including Bangalore, Chennai, Hyderabad, Pune or Kochi
Resources
Find educational articles, blogs, discussion threads and other resources.
Colleges
Find details about any college in India or search for courses.
|
MEDIA WISE
Posted Date: 22 Mar 2008 Resource Type: Articles/Knowledge Sharing Category: Computer & Technology
|
Posted By: arunkumar Member Level: Gold
Rating:  Points: 5
|
|
|
IEEE Spectrum
The Rise Of The Body Bots
EXOSKELETONS ARE STRUTTING out of the lab—and they
are carrying their creators with them. Erico Guizzo and
Harry Goldstein of the IEEE Spectrum give us an insight
into this future possibility
Science-fiction fans have long become accustomed to the idea
of steely commandos clad in robotic exoskeletons taking on
huge, vicious, extraterrestrial beasts, shadowy evil cyborgs, or
even each other. Supersoldiers encased in sleek, self-powered
armor figure memorably in such works as Robert A. Heinlein’s
novel Starship Troopers, Joe W. Haldeman’s The Forever War,
and many other books and movies. In A Good Old-Fashioned
Future, for example, Bruce Sterling writes of a soldier dying
after crashing in his “power-armor, a leaping, brick-busting,
lightning-spewing exoskeleton.”
Today, in Japan and the United States, engineers are finally
putting some practical exoskeletons through their paces outside
of laboratories. But don’t look for
these remarkable new systems to bust
bricks or spew lightning. The very first
commercially available exoskeleton,
scheduled to hit the market in Japan
next month, is designed to help
elderly and disabled people walk,
climb stairs, and carry things around.
Built by Cyberdyne Inc., in Tsukuba,
Japan, this exoskeleton, called HAL-5,
will cost about 1.5 million yen (around
US $13 800).
Meanwhile, in the United States,
the most advanced exoskeleton projects are at the University
of California, Berkeley, and at Sarcos Research Corp., in Salt
Lake City. Both are funded under a $50 million, five-year
program begun by the Defense Advanced Research Projects
Agency, or DARPA, in 2001. During the past several months,
each group has been working on a second-generation
exoskeleton that is a huge improvement over its predecessor.
Little information about the new models had been officially
released by press time, but IEEE Spectrum has learned that the
Berkeley unit was successfully tested in a park near the
campus this past summer and the latest Sarcos model was
demonstrated to a panel of military observers at Fort Belvoir,
VA., last April.
http://webench.national.com
HAL-5, in Japan, and the systems by Berkeley and Sarcos,
in the United States, appear to be the first of a platoon of
considerably more capable exoskeletons aimed at real-world
uses that may soon, quite literally, be walking near you.
Most of these systems are designed to help physically weak
or injured people gain more mobility or perform rehabilitation
exercises. But researchers are quick to mention other
commercial possibilities for their creations: rescue and
emergency personnel could use them to reach over debrisstrewn
or rugged terrain that no wheeled vehicle could
negotiate; firefighters could carry heavy gear into burning
buildings and injured people out of them; and furniture
movers, construction workers, and warehouse attendants could
lift and carry heavier objects safely
wired.com
Battling Bugs: A Digital
Quagmire
HOW EFFECTIVE ARE our computer bug battling techniques?
Why is it that we slip up in the same areas all the while? This
article by Simson Garfinkel tries to find the reasons
In 1976, computer pioneer Edsger W. Dijkstra made an observation
that would prove uncanny: “Program testing can be quite effective
for showing the presence of
bugs,” he wrote in an essay,
“but is hopelessly inadequate
for showing their absence.”
Thirty tears later, Dijkstra’s
words have the ring of
prophecy. Companies like
Microsoft and Oracle, along with
open-source projects like
Mozilla and Linux, have all
instituted rigorous and
extensive testing programs, but bugs just keep slipping through.
Last month, Microsoft’s monthly drop of bug patches included fixes
for 14 security holes that escaped prerelease testing, four of them
rated “critical.”
On Tuesday, the company fixed three more Windows bugs, and
all three were the same basic genus of bug—the “buffer overflow”—
that helped spread the first Internet worm in 1988. It seems
programmers and software architects manage to make the same
mistakes generation after generation. Even back in 1988, many of
the bugs that haunt us today were already old hat.
“We solved buffer overflows and the Y2K problem with Multics
in 1975,” says Peter Neumann, a senior scientist at SRI International
who has been researching bugs and their impact on society for
more than two decades. But while Multics—the first secure multiuser
operating system—addressed some thorny problems, bug
history keeps repeating itself.
The reasons for that are both simple and complex, experts say,
having to do with the programming languages themselves or with
programmer psychology and the environment in which software is
developed. To understand why bugs occur, it helps to start by
looking at the general classes of faulty code.
Bugs can be broadly divided into two categories. Typographical
bugs and errors in reasoning are one type. Then, there are the
deep, conceptual bugs that make a program malfunction even
though all the code is more or less correct.
Memory misdeeds
Buffer overflows and race conditions are examples of the first
kind of bug. A particularly tenacious beast, the potential for a
buffer overflow is created when a programmer allocates a certain
amount of memory to hold a piece of information—for example,
nine characters to hold a Social Security number. But then the
program tries to store more data in that space when it actually
runs. The rest of the data overflows the pre-allocated buffer and
overwrites something else in the computer’s memory—frequently
with disastrous results.
The 1990s saw buffer overflows reach near-epidemic
proportions in programs written in the C and C++ programming
languages, because these languages require coders to manually
manage the memory used by their programs. Like driving a
performance car, control of the memory might let a skilled
programmer eke a bit more out of the computer, or accomplish
neat tricks and stunts. But the danger of a stall or a crash is
ever present.
|
Responses
|
No responses found. Be the first to respond and make money from revenue sharing program.
|
|
Watch TV Channels
|