EDITOR'S EYE

The World of Software Development.

July 2007

Three topics are on tap for today, all of which involve some fun stuff:

1. I have a fun project in mind, but need some help. You see, when it comes drawing, I have a hard time creating a circle. Squares I can handle, but those darn circles flummox me. So are you a budding cartoonist? A cartoonist wanna-be? If so, drop me some e-mail at jerickson@ddj.com. Let's talk.

2. Don't forget about Dr. Dobb's Wide World of Programmers photo album project. Send in your photos to ddj.photos@gmail.com and get on the board.

3. And if you haven't seen it, take a look at some of the new video stuff we're doing. When I say "we" I really mean Deirdre Blake and John Dorsey. Whatever. They're doing some fun new stuff like this video news report on Symantec's Internet Security Threat.

Posted by Jon Erickson at 01:09 PM  Permalink |

Well, you probably thought you'd heard the last of me in regards to India, what with SD Best Practices India several months in the rear-view mirror. And that would have been the end of it until my next trip to India until I ran across an IBM/University of Michigan study that examined transportation issues in India.

What the study's authors discovered was that India faces challenges in the areas of transportation infrastructure, product quality, and skilled workers, not to mention labor and tax regulations -- challenges that are impacting growth. To come to this conclusion, the authors interviewed industry executives, academics, industry experts, and government officials to get a picture of what India itself sees as the real future state of its automotive industry. From where I was sitting in the backseat of a taxi in Bangalore, they should have also interviewed taxi drivers, not to mention motorized rickshaw drivers.

According to studies, India is expected to be one of the top 10 countries in terms of vehicle sales by 2015. The number of four-wheelers sold in 2006-2007 was about 1.4 million, but industry executives expect sales to double to 2.8 million by 2010 and triple to 4.2 million by 2015. And here's the really good news -- they expect an increase from 7 to 17 million two-wheelers from 2005 to 2015. That's a lot of mopeds. Of course, from the seat of my scooter, you can never have enough two-wheelers on the road. Less gas, fewer emissions, and more fun.

The study's specific findings include:

• The small car (especially the inexpensive "1 lakh car" at about $US2,500) is a key growth strategy. Indians view design, development, and manufacturing of small, inexpensive cars as their country's global niche and also as a way to fulfill the needs of India's domestic buyers. India, however, will likely be challenged by other global manufactures who can leverage economies of scale.
• India needs to strengthen its own R&D capability. To be a global player, it must be considered an innovative designer of vehicles and components in the automotive industry.
• Costs need to be contained. India's path to the world stage has been through low-cost production. Wages and infrastructure costs, such as electricity and shipping, are starting to rise. The industry is suffering from an undersupply of skilled labor. Labor laws and regulations also seem to be hampering business.
• Combating air quality, oil dependency, and congestion issues should be a coordinated effort between government and industry.

A key action item suggested for India to become a major player in the world market, is that manufacturers need to accelerate the perception that "quality" comes from India. India's government needs to strengthen India's own R&D capabilities.

Putting mopeds aside, what's interesting about this are the parallels between the Indian software development and transportation industries. For instance, it wasn't that long ago that we heard software produced in India was substandard. That's clearly not the case today. Software coming out of India is world-class and it is being written by world-class programmers. I know because I met a lot of them. Secondly, the refrain that the transportation industry needs to strengthen its R&D capacity is something we've also heard in regards to software. Moreover, because wages are rising in the automotive and related industries, India will be challenged by competitors from less wealthy countries. We're already seeing this in the Indian outsourcing industry, where companies from South America, Russia, and China, among other countries, are positioning themselves as less-expensive alternatives to Indian outsourcers.

Still, the future is rosy for India. How can it not be with 17 million scooters around the corner.

And speaking of India, I'd like to thank and congratulate Ashish Sharma of Mohali (Punjab) India for being the first entry into the Dr. Dobb's Wide World of Programmers" photo album. Thanks Ashish, and yes I do miss that spicey food. I'd also like to thank Oliver Shikaloski from Macedonia who also sent in his photo.

For a bit of background on the Dr. Dobb's Wide World of Programmers album, look here

And be sure to start sending in your photos and captions to us at ddj.photos@gmail.com. The more the merrier, and you don't have to have a moped to participate.

Posted by Jon Erickson at 06:05 PM  Permalink |

A few weeks ago -- right after the iPhone was launched, in fact -- I heard from frequent Dr. Dobb's contributor Tom Thompson who had been mulling over the new device. He shared his initial musings about the iPhone with us.

So the iPhone has been out -- what? a month or so now? -- giving Tom, who knows a lot of Apple software and mobile phones, a chance to further consider the iPhone. Here are his most recent musings on the iPhone.

-- Jeffrey Veen

Jeffrey was talking about Web design when he said that, but he could have been talking about consumer electronics. Everything about the hardware and software design of consumer electronics is a trade-off. Engineers struggle to build a gadget that has good mix of features, with long battery life...all while trying to hit a price point that won't make the consumer balk at buying the product. Really good engineers and UI designers can deliver the right blend of capabilities while concealing the compromises.

Which brings us to the iPhone. Countless hours have been spent trying to breach the device so that third-party applications -- and I don't mean scripts in the phone's Safari web browser -- can be installed, and it looks they've succeeded in doing it. The techniques used to accomplish this feat are far beyond what the casual consumer is capable of. During these endeavours, it was discovered that all of the phone's software ran at root level. That is, everything executes with administrator privilege. The security implications are obvious: an errant program has unfettered access to *everything* in the phone. Not only could it do damage to the iPhone's system software, but it could make off with your personal information.

"Idiots," some developers say of Apple for doing that. However, given that the iPhone appears to run a desktop operating system, it's easy to jump to the conclusion that they got sloppy. Nothing could be further from the truth. Let's take a closer look and speculate why the Apple engineers did this.

Steve Jobs says the phone runs Mac OS X. I'll grant that this statement is true, but the iPhone's Mac OS X implementation is as similar to the desktop version of Mac OS X as a Subaru wagon is to a Ferrari. Like the cars, the iPhone Mac OS X has the same core components as its desktop sibling, but otherwise in key ways they are also quite different. The desktop Mac OS X has access to loads of memory, massive amounts of storage, and has little concern about power consumption. The iPhone Mac OS X uses a limited amount of RAM (unlike the desktop world, for consumer devices RAM is the most expensive part in the device, and not the CPU), limited storage (the OS itself is supposedly shoehorned into only 700 MB), has Flash storage options that top out at 8GB, and power consumption is paramount. Things are going to be different for the iPhone OS.

Why would Apple use its desktop OS in a consumer device? Because it attacks two critical problems at once. First, it contains software costs because you're not starting from scratch: you're beginning with stable code that's been field-tested for years. Second, the OS has been ported to two processors, the PowerPC and Intel CPUs. (Mac OS X started life as NextStep running on a 68030 CPU.) These code ports made the core OS code sufficiently hardware-agnostic so that a port to the ARM processor derivative (supposedly an ARM1176JZF CPU) wouldn't be costly. Using Mac OS X as the iPhone's OS therefore brings reliability and reduced software development costs to the design. Apple also had an army of engineers seasoned from the recent Intel port to tackle the job.

The ARM1176JZF processor chosen as the iPhone's CPU has a number of features that appeal to mobile device designers. Among these were: a powerful yet compact ARM 6 instruction set, low power consumption, on-chip caches, a vector floating-point coprocessor (handy for 3D graphics), Single-Instruction, Multiple Data (SIMD) instructions for optimized graphics and video processing, a Jazelle coprocessor for hardware-supported Java execution, and last but not least, TrustZone technology for the protection of critical code and data.

Keep in mind that the ARM1176JZF is not a fully-fledged desktop CPU. Its primary function is to achieve many things while going easy on a battery. As a case in point, unlike a typical desktop CPU with MMUs that seamlessly implement memory protection, the ARM1176JZF's TrustZone mechanism requires some changes in the software to provide memory protection. Specifically, the software must be factored into non-secure and secure elements. A software monitor manages communications between the non-trusted and trusted environments.

From a code porting standpoint, right away you can see problems with this scheme. TrustZone requires a considerable code rewrite to split the software into secure and non-secure elements. And as any software engineer knows (or should), code modifications are guaranteed to introduce bugs that adversely affect the reliability of the OS. This requires more testing to ensure that the enhancement isn't going to create more problems than it solves. The one-two punches of rewriting the software and testing it drives up the cost of implementing the TrustZone mechanism.

Another issue with the TrustZone mechanism is that it adds overhead. Considering that the processor is running a full-blown OS, and this overhead probably degrades performance significantly. If Apple has learned anything from its into forway into the PDA market with the Newton, it's that performance is critical.

Given all of these negatives, the Apple engineers probably decided not to use the processor's TrustZone feature. Understand that I'm not criticizing the TrustZone feature of the CPU. If the design team had more time, they probably would have used it. This is one of those design trade-offs that must be made, particularly when you're trying to get the product to market.

Having given up on memory protection, Apple did do things to lock down the system. Shoehorning the OS into less than a gigabyte of storage meant discarding a lot of software utilities, such as console and ssh, which are avenues for trouble. Copy-and-paste also didn't make the cut possibly because of UI issues, but more likely because it's hard to anticipate the memory consumption of such an operation, which is deadly in a device with severely-constrained memory resources. Furthermore, cut-and-paste can present an opportunity for breaching the system. For similar reasons, saving video clips and interactive Flash payback in the browser wasn't supported.

In the end, it was left up to the Safari browser to function as a secure sandbox for "applications" downloaded over the air from the Internet. Based on the exploit announced by Independent Security Evaluators, it seems that Safari's security on the iPhone has been compromised. To their credit, the outfit has notified Apple and given them time to correct the situation. The browser can and will be fortified, although this is always a cat-and-mouse game, with Apple trying to outpatch the black hats. Perhaps the Jazelle coprocessor and a Mobile Java implementation -- accelerated by Jazelle -- can be used create a safer sandbox.

In summary, it's easy to criticize the flaws of the iPhone, while ignoring the fact that it offers many capabilities such as messaging, browsing, and music playback on top of the phone functions, and seems to do them well. Let's keep in mind that a lot of difficult trade-offs were made in getting the iPhone to market. As Jeffrey says: "Good design is problem-solving."

It's just that sometimes there aren't ideal solutions to some of these problems. Apple could have easily done far worse. I have every reason to believe they'll fix these problems in time.

Posted by Jon Erickson at 01:20 PM  Permalink |

From all indications, Intel is taking open source seriously. First it was the news that the Threading Building Blocks was going open source. Then on the heels of that announcement, Intel announced thatits Mobile Platform SDK 1.2 would be an open source project too.

The Mobile Platform SDK 1.2 provides a set of libraries and runtime components, along with an API that is common across supported Windows platforms and runtimes. In addition to being hosted on an Intel site, the SDK is also available on SourceForge.

Then there is the recently announced Mobile and Internet Linux Project, an open source project for mobile Linux development on Intel-based mobile devices. It focuses on projects such as Ubuntu's Mobile and Embedded Edition and Red Flag's MIDINUX, and serves as an incubator for prototyping new ideas and projects targeting devices such as the Intel-based Mobile Internet Device (MID) and other consumer electronic devices.

Power's your problem? Intel is covering that in an open source kind of way with PowerTOP, a tool that helps you determine what software that running on mobile systems (like laptops running Linux) is using the most power. By addressing power-hungry hotspots, you can save battery power. The tool lets you see estimated time left for battery power if you are running Linux on an Intel-based laptop running.

And don't forget drivers for Intel graphics controllers. Intel has open sourced drivers for its 965GM Express Chipset-based mobile graphics controller. These Linux drivers include support for 2D and 3D graphics features for the mobile version of Intel graphics architecture.

To be truthful, there's a lot more open source that Intel has been working on. This is just the most recent stuff. If you want to keep up with it, a good place to start is the Open Source Technology Center.

Posted by Jon Erickson at 09:18 AM  Permalink |

Here's what we need to do -- start up of photo album of programmers around the world. Of course, I could've -- and should've -- started the ball rolling on this Spring's meanderings in India, Russia, Portugal, and wherever the heck else I was. And I can contribute, but I can't do it alone. Which I why I hope you'll jump in.

What you need to do is send me a digital photo of yourself holding a copy of Dr. Dobb's Journal in your hands in front of a recognizable feature of the country, city, or locale that you're in. You know: If you're in India, a photo of you standing in front of the Taj Mahal with a copy of the magazine. Okay, if not the Taj Mahal, at least stand next to a motorized rickshaw. Or if you're in Finland, stand in front of a Nokia building. (That shouldn't be hard; it seems that just about every other building in Finland says "Nokia" on it.) And if you don't have a copy of the magazine, that's okay too. Send in your photo anyway.

It's okay if you're just traveling too; it doesn't have to be just where you reside. If you're on a trip, send us photos from your stops along the way. That's fair game too.

Of course, you could be in San Francisco's Chinatown and telling me that you're in Beijing and I probably wouldn't know the difference. The California license plates on the cars driving by might give me a hint, however.

What I'd appreciate your doing then is take the digital photo (it doesn't need to be the *highest* resolution; those can be BIG file sizes) and attach it to a note that gives your name, location, email address, and what you do and send it to me at:

ddj.photos@gmail.com.

Put "photo project" or something relevant in the subject line. If you want to ZIP up that package, that's fine too. GIF or JPG would be fine. Am I missing anything?

Oh yes, what's in it for you? Well, you get the fame associated with Dr. Dobb's. Which means that my mother, who regularly reads (but does not understand) the magazine and website, will see your smiling face.

When I asked the staff what you should get, they all chimed in to say "a visit from Erickson". But then, I figured out that that was just their way of getting me out of the office some more. So I'm still working on it. I'm thinking CDs or t-shirts or something like that. No promises yet. Need to check what's in the closet. As for your mailing address, I'll drop you a note about that when I get your photo and email address. (Unless, of course, you want to include it in the ZIP archive.)

So what do you say? Sound like fun? I hope you will participate and I look forward hearing from you. Let's see who will be the first to show up in Dr. Dobb's Wide World of Programming Photo Album project.

Posted by Jon Erickson at 05:29 PM  Permalink |

It's about time to hit the road again, what with a spate of upcoming events. I don't want to miss them, and you won't want to either. Here are a few:

Dr. Dobb's Architecture and Design World

When: July 24-27 (Holy cow! That's next week!)

Where: Chicago McCormick Place

Who: There will be several speakers who you'll recognize from the pages of Dr. Dobb's Journal, including Scott Ambler, Ivar Jacobson, and Arnon Rotem-Gal-Oz. From what I hear, Contributing Editor Mike Riley will be hanging around too.

The sessions focus on four tracks -- Architecture and Design, Modeling, Process and Methods, and Usability -- and there looks to be some great presentations.

Other speakers of note include Robert C. Martin who will be covering Design Patterns in Depth, Clean Code, and other topics. I particularly want to catch Charlie Krueger's session on Software Product Line Development. (Charlie is an interesting guy. Check out this conversation I had with him a while back.)

You can find out more about the entire conference here.

SD Best Practices

When: September 18-21 (Whew! At least there's time to plan.)

Where: Boston Hynes Convention Center

Who: A lot of speakers who have been in Dr. Dobb's Journal -- and a lot more who ought to be. Let's see, there's: John Graham-Cumming, David Intersimone, Kirk Krauss, Joe Marasco, Tracy Ragan, and Robert Seacord, among others.

Best Practices will be focused on eight tracks: Build and Deploy; C++; Design and Architecture; People, Projects and Teams; Process and Methods; Requirements and Analysis; Testing and Quality; Web Services/SOA; plus Secure Design mini-track. It's worth mentioning that a couple of other events will be co-located at the same place, same time: RFID World and the Embedded Systems Conference.

You can find out more about the entire conference here.

Extraordinary C++

Right after Best Practices, there's another, what looks to be, excellent conference on the other coast.

When: September 23-26

Where: Astoria, Oregon Hotel Elliott.

Who: A lot of folks who know a lot about C++, including: Scott Meyers, Eric Niebler, Andrei Alexandrescu, Walter Bright, and Dave Abrahams.

Sessions: An Overview of TR1; C++ Callbacks for C APIs; Choose your Poison: Exceptions or Error Codes?
Memory Allocation: Either Love It or Hate It. (Or Just Think It's OK.); C++ Metaprogramming Concepts and Frameworks; Domain-Specific Embedded Language Design with Boost.Proto; Building Fast Lexers and Parsers; and Performance Tuning Your Application

Exceptional C++ looks to be an exceptional conference. I hope I can make it too.

You can find out more about the entire conference here.

Posted by Jon Erickson at 08:28 AM  Permalink |

Even robots are having more fun than I am this summer. Let's see, a week or so ago it was the RoboCup competition where robots played soccer. This past weekend, robots were cooling off in the pool at the 10th annual International Autonomous Underwater Vehicle competition.

Sponsored by the Association for Unmanned Vehicle Systems International (AUVSI) and the Office of Naval Research, the competition challenged students from 28 colleges and universities from around the world to design, build, and deploy autonomous underwater vehicles that could find pirate's hidden loot. To qualify for the competition, all of the underwater robotic entries had to be autonomous, able to sense their surroundings and respond accordingly, independent of any external control by an operator. All this for free admission to the pool and $20,000 in cash prizes.

Typical of the entries was the University of Southern California's SeaBee II -- a 50-pound underwater robotic submarine with three camera eyes, two arms, a water-cooling system, and related intelligence. Built by the USC Southern California Competition Robotics (USCR) team, SeaBee II is a BeoWulf Class I underwater cylindrical robot about 24-inches long and 7-inches in diameter. SeaBee II uses five thrusters for propulsion and depth control. They are arranged in two groups, with three thrusters aligned vertically and one pair aligned horizontally. The arrangement allows for five degrees of freedom to control the sub’s balance and orientation.

To recover the "treasure", the team had to design a simple arm mechanism, which sits underneath SeaBee II. When SeaBee’s vision system detects the X-shaped treasure and has centered itself above it, the sub is able to maneuver into position and lift it to the surface. According to Christian Siagian, a computer science doctoral student on the USCR team, the manipulator consists of two outstretched arms which are attached to the external frame of the vehicle "in a specific location so that the aft-most camera can judge when the sub has situated itself in the correct position to lift the treasure."

SeaBee’s many heat-producing elements, plus its Core Duo processors, created a heat problem, which the team had to solve before they could enter the competition.

So how did they do? Okay, but not good enough to win. That honor went to SubjuGator 6 from the University of Florida. The SubjuGator isn't new to the competition, having placed in the top spot 3 six times, including first place in 2005 and 2006.

The SubjuGator uses a single-board Intel Core 2 Duo based computer running the Windows XP provides processing power necessary for monitoring and controlling all systems. The behavior of SubjuGator is controlled with Microsoft Robotics Studio framework communicating with a network of intelligent sensors. The sensor systems include cameras, hydrophones, a Doppler Velocity Log, a digital compass, altimeter, and internal environment monitor sensors. The submarine also makes use of custom designed motor controllers with current feedback monitoring and other peripherals.

In the meantime, I was working all weekend.

Posted by Jon Erickson at 10:22 AM  Permalink |

Here's what happens when you combine a rare bit of spare time and searches with imprecise keywords. Words like "architect" (as in "software architect"), "embedded" (as in "embedded systems"), "programming" (as in "computer programming"), and "digital" (as in "digital").

What you end up with is something along the lines of "digital water walls". Huh?

As odd a phrase as that might seem, it is the real deal. Architects and engineers at the Massachusetts Intitute of Technology are designing buildings with the walls made of water. The building, dubbed a digital water pavilion, is an interactive structure made of digitally controlled water curtains and will be located Expo Zaragoza 2008 in Spain. It will house an exhibition area, cafe, and (presumably) public showers. (Just kidding.)

The "water walls" that make up the structure consist of a row of closely spaced solenoid valves along a pipe suspended in the air. The valves can be opened and closed, at high frequency, via computer control. This produces a curtain of falling water with gaps at specified locations -- a pattern of pixels created from air and water instead of illuminated points on a screen. The entire surface becomes a one-bit-deep digital display that continuously scrolls downward.

"To understand the concept of digital water, imagine something like an inkjet printer on a large scale, which controls droplets of falling water," explains MIT's Carlo Ratti. That helps.

William J. Mitchell, head of MIT's Design Laboratory and former Dean of Architecture at MIT, added that "in the digital electronic era, new combinations of sensor technology, embedded intelligence, networking, computer-controlled pumps and valves, and control software open up the exciting possibility of urban-scale, precisely controlled, highly interactive water."

The facade of the water pavilion will be like a very large display, with text, letters, and interactive patterns. "You could throw a ball at the wall, and then see an open circle drop down to meet it precisely where and when its trajectory intersected the water surface. And, with suitable programming, touching the water surface at any point can propagate patterns horizontally, along the wall, to other locations," Mitchell explains.

Okay, but I still like the idea of public showers.

Posted by Jon Erickson at 01:27 PM  Permalink |

You probably know this already because it has been hard to miss -- the current hot buzzword is "on-demand." Okay, technically that's two words, but when you hyphenate them.... Well, you get the idea.

Lately, we've heard about "on-demand security," "on-demand collaboration," on-demand CRM," "on-demand applications," "on-demand supply chain," "on-demand computing software environments," "on-demand strategies," and on and on. There's even an OnDemand Expo in the offing. There's Oracle On Demand, Adobe On Demand, and On-Demand IBM.

All this, even though Wikipedia says that "SaaS" has replaced "on-demand". You couldn't prove by me. I just received promotions for "on-demand adult videos" not to mention "on-demand router-to-router VPN connections" both in the same day.

Gee, if you didn't know better, you'd think we're an impatient lot.

But that's not to say that on-demand is unreasonably demanding. Say you were in a natural disaster -- like an earthquake -- and needed some help. To thisend the San Diego Supercomputing Center at the University of California-San Diego has introduced OnDemand, a new supercomputing resource that will support event-driven science.

The OnDemand system is a Dell cluster with 64 Intel dual-socket, dual-core compute nodes for a total of 256 processors. The 2.33 GHz, 4-way nodes have 8 GB of memory. The system, which has a nominal theoretical peak performance of 2.4 Tflops, is running the SDSC-developed Rocks open-source Linux cluster operation software and has the IBRIX parallel file system. Jobs are scheduled by the Sun Grid Engine. The system has StarP installed, a parallel version that provides a high-performance backend to packages such as Matlab.

The system is already in operation and formal allocations of time for the OnDemand system will begin in October. In addition to supporting important research now, this system will serve as a model to develop on-demand capabilities on additional TeraGrid systems in the future. TeraGrid is an NSF-funded computing grid linking some of the nation’s largest supercomputer centers including SDSC.

"SDSC's new OnDemand system is an important step forward for our event-driven earthquake science," said Caltech computational seismologist Jeroen Tromp. "We’re getting good performance that will let us cut the time to deliver earthquake movies from about 45 to 30 minutes or less, and every minute is important."

Posted by Jon Erickson at 09:28 AM  Permalink |

On the off chance you were in Atlanta, Georgia, this past weekend, I hope you were able to catch some of the RoboCup competition, an international joint project to promote AI and robotics (and related fields).

Nearly 300 teams from 37 countries competed in RoboCup 2007 Atlanta, the competition for research robotics at the Georgia Institute of Technology.

All in all, approximately 1700 students and faculty from universities, high schools, middle schools, and elementary schools competed in events ranging from four-legged and humanoid robotic soccer games to search-and-rescue competitions.

Interestingly, this year’s event featured a demonstration of the Nanogram League, a competition between microscopic robots. The The RoboCup Nanogram competition challenged teams from the Swiss Federal Institute of Technology, U.S. Naval Academy, Carnegie Mellon University, and Simon Fraser University to construct microscopic robots that competed against each other in soccer-related agility drills. These robots measured a few tens of micrometers to a few hundred micrometers in their largest dimension and with masses ranging from a few nanograms to a few hundred nanograms. They operate under an optical microscope and are controlled by off-board electronics using visual feedback. There were three competitions: a 2mm Dash and a Slalom Drill, and a Ball Handling Drill -- all won by the Swiss Federal Institute of Technology team.

Overall, the competition focused on three key application areas:

• RoboCupSoccer was an exercise in the design of autonomous agents, multi-agent collaboration, strategy acquisition, real-time reasoning, robotics, and sensor-fusion, with the ultimate goal of developing a team of fully autonomous humanoid robots that can win against the human world champion team in soccer.
• RoboCupRescue. Technologies for search-and-rescue operations in large-scale disaster situations. This area is inteneded to couple technology with significant issues by providing human rescuers with enough information to safely perform a rescue.
• RoboCup@Home. Fostering development of useful robotic applications that assist humans in everyday.

As for winners, going through the results about the only thing I could make out is the RoboCup@Home
The AllemaniACs team from Germany won the event, with the UT-Austin Villa from the University of Texas coming in second, and Pumas from Mexico's UNAM university.

Results from the other events are still coming in. Maybe I should take the easy way out on this, and just say that in an event like RoboCup, everyone is a winner. Okay, that's wimpy -- but it's true.

Posted by Jon Erickson at 11:00 AM  Permalink |

When you're as overworked and underpaid as I am, apologies are often in order. Not apologies made to me by the boss, of course, but apologies I make to others for (a) not responding in a timely manner, (b) botching up whatever it was I was supposed to do when I do get it done, and (c) forgetting what it was I was supposed to apologize for. So if my interactions with you fall into any of the above, I apologize. Profusely. Sincerely.

So today's apology is to a bunch of folks all at one -- everyone who presented papers at the Eighth Real-Time Linux Workshop held several months ago at the at the School for Information Science and Engineering, Lanzhou University, in Lanzhou, China. More specifically, I'd like to apologize to Dr. Peter Wurmsdobler, Director of Real-Time Linux Foundation and Nicholas McGuire, systems administrator and organizer of the workshops. And, again, everyone who presented papers at the Conference that Dr. Wurmsdobler, Professor McGuire, and others worked hard to put together.

So here's where the apology moves to the forefront. I made a committment to publish online all the papers presented at the Conference as quickly as possible. I had big plans, which included converting from PDF to HTML, packaging the papers in to appropriate categories, finding sponsors who were might be interested in helping out, and so on and so on. As if often the case with the best laid plans of mice and men, there ended up being more meetings and less action. Unfortunately, because there are some fine and interesting papers that focus on real-time, Linux, and Real-Time Linux.

As you probably guessed by now, all the papers aren't posted yet -- but I'm working on getting them there. I have several of the posted right, including

• Numerical Model Compiler: A Design for Generating Real-Time Numerical Simulation Code, which discusses building a Domain-Specific Language.
• A Pre-built Real-Time Scheduling Algorithm for Embedded Systems, which presents a new hard real-time scheduling algorithm.
• A Hardware Architecture Independent Implementation of GDB Tracepoints for Linux, which presents a tool for debugging of applications, especially in distributed environments.
• A Linux-based System to Monitor Train Speed and Doors for a Light-Rail System, which describes how and why Linux was selected to run on an ARM-based single-board computer for pilot tests of a control system to be installed on trains for the light-rail system in Guadalajara.
• A New Dynamic Frequency Scaling Algorithm for Power-Aware and Real-Time Systems, which focuses on the energy-critical hardware component -- the CPU.
• Real-Time Management for P2P Resources on Mobile Devices, which discusses P2P resource sharing.
• Implementation of a Forest Fire Monitoring System Based on Embedded Linux.
• Rapid Controller Prototyping at the SUPSI Laboratory, selected as the best paper in the category of "Real-Time Linux Application".
• RTL-IO: An Extension of RTLinux I/O, an efficient I/O system for real-time environments.

And you can expect many more related articles posted over the next few days.

This really is a trove of information about Linux, and I do feel badly about not getting it available sooner. But I will do better, and I'd like to close in congratulating all participants in the Conference for a job well done. Now if I can only do my job as well.

Posted by Jon Erickson at 11:57 AM  Permalink |

My next door neighbor has four dogs. Which to my way of thinking is about four too many. The reason why is that with all the barking they do -- day and night -- it sounds like 40 dogs instead of 4.

Which is just one reason why I like Stefan Schaal's dogs a lot more. Schall, who is a professor of computer science at the University of Southern California, builds four-legged dogs that are able to negotiate uneven, treacherous, and difficult terrain. If if he can program to do that, you can bet he can program them to be quiet about it.

But from what I can tell, Schaal is more worried about the mobility issues, than the audible ones.

"What you really want legged robots for is to negotiate difficult terrain," he says. "This project is designed to push that envelop."

To do this, the robotic dog calculates where and how it should proceed, "based on the current position, velocity, and acceleration" of its legs. If one effort fails, the dog learns from its mistakes and tries another route the next time.

After 15 months of experimentation -- sending back mechanical dog bodies to Boston Dynamics (which is building the robots that Schaal designs) at a rate of about one per month, but saving each one’s digital electronic experience -- Schaal's dogs can move at 1.6 centimeters a second. His goal is to triple the speed and double the difficulty of the terrain.

What about making them bark? "Once they can run, I’ll bark for them," Schaal says.

Fine, but don't move in next door to me.

Posted by Jon Erickson at 12:00 PM  Permalink |