- On the one hand, he plays a mean guitar; on the other hand, he also plays a mean guitar
- Periodic table of elements — the YouTube version (thanks JM)
- Freescale demos QNX multimedia on an i.MX31 processor
7/30/2008
This week's random hits
7/25/2008
Reflections on the DSO ghost site
Isn’t it time someone turned off the lights at www.dso.com? It’s been two years since anything has been posted on the site. No blog entries, no interviews, no press releases, no whitepapers, no anything. Just a “New” entry dated July 28, 2006.
Did you ever hear about DSO (device software optimization)? It was labeled as a “methodology” that aims to optimize embedded development through a combination of standardization, choice, partnerships, and best practices.
Three years ago, industry analysts were singing the praises of DSO. RTOS vendors were tripping over one another in a rush to proclaim their DSO support. Magazine articles were speculating that DSO might be the next big thing. One article even claimed that the DSO market was valued at 8 billion dollars — even though DSO was defined as a methodology, not a market.
Today, all I see is an abandoned web site and a few perfunctory references in press releases. Wind River is the exception: it still promotes DSO in its glossy brochures. But then again, it came up with the DSO concept in the first place.
What about you? Do you think DSO was a laudable attempt at establishing a baseline for embedded software vendors? Or is it simply yesterdays’ marketing campaign?
Did you ever hear about DSO (device software optimization)? It was labeled as a “methodology” that aims to optimize embedded development through a combination of standardization, choice, partnerships, and best practices.
Three years ago, industry analysts were singing the praises of DSO. RTOS vendors were tripping over one another in a rush to proclaim their DSO support. Magazine articles were speculating that DSO might be the next big thing. One article even claimed that the DSO market was valued at 8 billion dollars — even though DSO was defined as a methodology, not a market.
Today, all I see is an abandoned web site and a few perfunctory references in press releases. Wind River is the exception: it still promotes DSO in its glossy brochures. But then again, it came up with the DSO concept in the first place.
What about you? Do you think DSO was a laudable attempt at establishing a baseline for embedded software vendors? Or is it simply yesterdays’ marketing campaign?
7/24/2008
This week's random hits
- Snake robots
- Snake robots based on QNX
- The first(?) electronic digital computer
7/23/2008
Buggy medical software: Is static analysis the cure?
Recently, the Baltimore Sun published an article on how the FDA is using static analysis tools to uncover software defects in medical devices. Software defects now account for about 20% of medical-device recalls, so it's no surprise that the FDA has become interested in tools that can: a) detect existing defects, and b) prevent new defects from occurring.
The article has generated response from editors of medical device publications, developers of medical software, a ZDnet blogger, and even medical malpractice lawyers.
Nobody has a problem with the FDA uncovering errors that could harm or kill someone. Some folks seem worried, however, that the FDA will force medical-device companies to adopt static analysis as a standard development practice. Their objections fall into several categories, including:
Static analysis tools are expensive — I’m no expert on the total cost of buying, learning, and maintaining static analysis tools. But, in their defense, they can detect a variety of bugs early in the development cycle. And the earlier you catch bugs, the cheaper it is to fix them.
Static analysis tools make too many false positives — Static analysis tools can report a software error when, in fact, none exists. Some argue that this shortcoming wastes precious development time. However, vendors of static analysis tools say that their products now implement highly advanced techniques to minimize this problem.
Static analysis can’t always predict how software will behave when it’s actually running — Agreed, but I doubt that anyone believes static analysis tools should be used alone. At QNX, we recently published a whitepaper on how developers can combine static analysis tools and runtime analysis tools to achieve higher product quality.
What about you? Do you use static analysis tools? Do you develop them? Do you think the FDA would be justified in forcing medical-device companies to use static analysis? Or are there other, better ways to ensure software quality?
The article has generated response from editors of medical device publications, developers of medical software, a ZDnet blogger, and even medical malpractice lawyers.
Nobody has a problem with the FDA uncovering errors that could harm or kill someone. Some folks seem worried, however, that the FDA will force medical-device companies to adopt static analysis as a standard development practice. Their objections fall into several categories, including:
Static analysis tools are expensive — I’m no expert on the total cost of buying, learning, and maintaining static analysis tools. But, in their defense, they can detect a variety of bugs early in the development cycle. And the earlier you catch bugs, the cheaper it is to fix them.
Static analysis tools make too many false positives — Static analysis tools can report a software error when, in fact, none exists. Some argue that this shortcoming wastes precious development time. However, vendors of static analysis tools say that their products now implement highly advanced techniques to minimize this problem.
Static analysis can’t always predict how software will behave when it’s actually running — Agreed, but I doubt that anyone believes static analysis tools should be used alone. At QNX, we recently published a whitepaper on how developers can combine static analysis tools and runtime analysis tools to achieve higher product quality.
What about you? Do you use static analysis tools? Do you develop them? Do you think the FDA would be justified in forcing medical-device companies to use static analysis? Or are there other, better ways to ensure software quality?
7/17/2008
7/15/2008
Clean socks? Thank QNX.
In 2005, QNX issued a press release that described 25 ways in which people encounter QNX technology every day. I'm on a personal mission to expand the list and, in January, suggested Item 26: taking your medicine. Now let me suggest Item 27: washing your boxer shorts.Every year, Diehl Controls, a multinational headquartered in Germany, builds more than one million control panels for stoves, refrigerators, cooking hoods, washing machines, and other appliances. Diehl sells these control panels to appliance manufacturers, who then integrate the panels into their end products.
On the face of it, the control panels on most washing machines look pretty much the same. Look closer, however, and you'll find that their functions and control sequences vary from one model of machine to another. As a result, a one-size-fits-all approach to programming and testing washing-machine panels simply doesn’t wash.
Enter VIP-CAT, a QNX-based system that helps Diehl speed up the process of configuring control panels for multiple customers and product models. When an operator plugs a control panel into VIP-CAT, the system’s software configures the panel for a specific model of washing machine and then tests the panel to ensure that it functions correctly.
4D Engineering, a company headquartered in Wessling, Germany, developed the software for VIP-CAT. The software takes advantage of several QNX technologies, including the QNX Photon microGUI and QNX distributed processing. For instance, the system is controlled by four QNX-based machines: a master controller and three station controllers. When the master controller receives configuration files and other data from a corporate back-end system, it uses QNX distributed processing to share the information with the station controllers.
The system also takes advantage of QNX’s modular architecture, which allows software tasks to run as user-space processes that can be developed, tested, and validated individually. This modular approach not only makes the system more reliable, but also allowed engineers at 4D and Diehl to divvy up the work and develop the system’s various software tasks in parallel.
For more details, check out 4D’s overview of the VIP-CAT project.
7/09/2008
This week's random hits
- Zombie caterpillars
- The loudness war
- Berkeley DB 4.7 comes to QNX
7/07/2008
In memoriam: Dan Hildebrand
Dan Hildebrand, who died 10 years ago today, served as an inspiration to everyone at QNX Software Systems. When other people said no, he said yes. When other people said impossible, he said possible. When other people said give up, he said keep trying.
Dan was many things at QNX: software architect, technical evangelist, invaluable teacher, and supportive colleague. He constantly amazed me with his encyclopedic knowledge and with his innate ability to grasp industry trends. But most of all, he impressed me with his fundamental respect for other people's ideas and contributions.
Case in point: During a hallway conversation, I mentioned something that gave Dan an idea for a new product feature. He subsequently sent an email to several senior developers and department heads, describing the idea and claiming that I came up with it. Upon seeing the email, I quickly phoned him and protested, "Dan, nice of you to say that, but really, it was your idea. You should get the credit, not me." But Dan was adamant: the credit was mine.
It's been 10 years, but I still can't talk or write about Dan without coming to tears. Perhaps that, more than anything, testifies to his virtues as a colleague and human being.
God bless you, Dan.
A short Danh bibliography
In memoriam: Rob Oakley
Earlier this year, we mourned the passing of another former QNX colleague, Rob Oakley. Rob worked at QNX during the 1990s, in roles ranging from software developer to marketing director.
I spent a couple of years working for Rob and grew to enjoy his idiomatic mastery of English and unique sense of humor. I remember a conference where Rob convinced 500 software developers to sing "Port, port, port your code, port your code to QNX" to the tune of "Row, row, row your boat." Few people would have the imagination to think of something like that. Fewer still would have the gumption to get up and do it.
God bless you, Rob.
Dan was many things at QNX: software architect, technical evangelist, invaluable teacher, and supportive colleague. He constantly amazed me with his encyclopedic knowledge and with his innate ability to grasp industry trends. But most of all, he impressed me with his fundamental respect for other people's ideas and contributions.
Case in point: During a hallway conversation, I mentioned something that gave Dan an idea for a new product feature. He subsequently sent an email to several senior developers and department heads, describing the idea and claiming that I came up with it. Upon seeing the email, I quickly phoned him and protested, "Dan, nice of you to say that, but really, it was your idea. You should get the credit, not me." But Dan was adamant: the credit was mine.
It's been 10 years, but I still can't talk or write about Dan without coming to tears. Perhaps that, more than anything, testifies to his virtues as a colleague and human being.
God bless you, Dan.
A short Danh bibliography
- Usenix interview
- A Scalable Microkernel POSIX for Realtime Systems
- An Architectural Overview of QNX
- Adapting PC Technology for Internet Appliances
In memoriam: Rob Oakley
Earlier this year, we mourned the passing of another former QNX colleague, Rob Oakley. Rob worked at QNX during the 1990s, in roles ranging from software developer to marketing director.
I spent a couple of years working for Rob and grew to enjoy his idiomatic mastery of English and unique sense of humor. I remember a conference where Rob convinced 500 software developers to sing "Port, port, port your code, port your code to QNX" to the tune of "Row, row, row your boat." Few people would have the imagination to think of something like that. Fewer still would have the gumption to get up and do it.
God bless you, Rob.
7/02/2008
Get your gurus working
I'm embarrassed to admit that, until today, I had never heard of embeddedgurus.net, a blog community of embedded developers that includes a former editor of Embedded Systems Design magazine.
The posts cover a range of topics, from "RTOS Myth #4: The RTOS is in Charge" to "Make the most of side-by-side code differencing." It's well worth checking out.
I learned about the site from a recent Jack Ganssle article on resources for embedded developers.
The posts cover a range of topics, from "RTOS Myth #4: The RTOS is in Charge" to "Make the most of side-by-side code differencing." It's well worth checking out.
I learned about the site from a recent Jack Ganssle article on resources for embedded developers.
Subscribe to:
Posts (Atom)