RIM acquires TAT

The Astonishing Tribe is kind of a strange little name for a company, so most people refer to it by just the letters T. A. T.  (Note to those of you like me who have incorrectly pronounced it "tat" like "tit for tat"; instead they spell the letters out.) They are a small Swedish company that does some pretty amazing UI design.  QNX has encountered them before via a number of shared automotive accounts, although they're much better known to the rest of the world for their work in the mobile space.  They've created the designs of a huge number of mobile handsets, and they were the prime contributor to Android's look & feel.

Now, we're happy to have them as a sister company.  As of December 2nd, RIM acquired TAT.  Although we worked with TAT before, I'm sure this means a lot more interaction between QNX and TAT in the weeks to come.

Automotive Meets Communication (AMC) 2010

It appears I am unable to do "live blogging"--my blogs are always at least a week after the fact.  Maybe I'll do a blog about this sometime :-)  In any case...

Last week, I attended the AMC 2010 conference held in Bonn, Germany.  Lots of participation from the telecom and automotive industry, talking about how they could and are working together to build the future of connected automobiles.  I had a speaking panel spot that, although it was the only non-German language presentation, seemed to be quite well received.  My presentation was about emerging trends in automotive, and the thanks to the material has to go to my colleague Andrew Poliak, whom I plagiarized from mercilessly. Of course, "borrowing" material happens all the time throughout the business world.

Here's a great case in point: one of the AMC speakers from BMW had a great word bubble diagram (attached below). The picture was a great one, mainly (in my view) because it included a "QNX" plug (red text; look in the lower right hand part of the "cloud"). Coming from BMW, who has been a big supporter of Linux, I just loved this slide.

The funny part of the story is that I was talking about how I was going to blog this with my colleague Paul Leroux, who is a ferocious blogger.  I started out with, "say Paul, I've got this pic I want to show you, but you have to promise that you won't blog about it first."
"No problem," Paul said, as I opened the pic.  Paul immediately gave an exclamation of surprise and then added, quite seriously, "I've already blogged about it, about a year ago.  That guy is using my diagram!"  He showed me in his blog where he had created the diagram.

It is getting so frustrating blogging about anything before Paul does--he even goes back into time to preempt me!  Even if I start blogging during the event next time, I can't beat Paul!

Some things just never change

Here's a picture that my dad dug up for me--it's me sitting in a 1985 Corvette test vehicle.  My Dad was a GM engineer back in those days, and GM loaned cars out to employees to test and collect feedback. This was when I had just recently gotten my driver's license, and I was all about cars (and girls).  Fortunately, he trusted me enough to let me take it to the end of our driveway and back.  I wanted one of those babies forEver after that.

Here's a pic from last week at Convergence.  Anything look similar?  The Corvette has gotten sexier, and well... let's just say I haven't.  Being that this is the new QNX Connected Car 2.0, it doesn't get driven too much.  I got to back this beautiful machine out of the QNX garage before the show, for about 15 feet driving distance total.

I just hope it's not another 25 years before I get another chance at taking one out on the road.  Not only would my retirement-age body probably break a hip getting down into such a low-riding car, I'd like it if I could still drive over 40 mph on the highway.

QNX CAR with Apple iPod out

Everyone's allowed a little self-promotion once in a while!  Here's a video of me showing off a new QNX CAR feature:  iPod Out Video

I don't think I'll be moving to Hollywood anytime soon!

Oracle sues Google over Android

I guess it shouldn't be too much of a surprise.  Android gets big enough and it'll attract lawsuits... Oracle is suing Google over some of the contents of Android.  Google's reimplementation of Java through it's Dalvik VM and Android's success obviously makes Oracle want a piece of the action.

The specific patents involved: 6,125,447; 6,192,476; 5,966,702; 7,426,720; RE38,104; 6,910,205; and 6,061,520.  Oh, and they also claim copyright infringement to boot.

Is this a legitimate lawsuit?  Is Google going to have to retract portions of Android or Dalvik?  I could see Google trying to out-technology Oracle to solve the patents just out of spite, even if that has a big slowdown to the growing Android community.  I don't know, and I'm not a lawyer.  But I did read through the patents involved, and it seems that there are three groups of complaints.

One is on security mechanisms and resource protection of Java.  That one seems like it will be hard to defend against, since Dalvik mimics much of the Java mechanism.

The other is on how class files are processed and packaged.  My guess is that Google could probably get around this one without too much trouble by redoing their tools.  You already have to recompile Java anyway for Android, why not redo how class files are handled?

The third area is around how the VM optimizes instructions. Parts of the claimed patents seem easy to avoid, but others do not.  This could be a difficulty to work around, but I'm not certain.

Of course Google's other option is just to pay Oracle off.   Would Oracle ask for an injunction on shipping Android devices to spite Google?  Don't know.  Either way, I suspect there will be interesting times ahead for the Android ecosystem.

Lies, Damn Lies. (or, QNX was *not* hacked in a car.)

A colleague of mine pointed me to this blog from Dave Kleidermacher, which, although hosted on the EE Times website, sounds suspiciously like a GreenHills ad:
“Hello, I’m a VxWorks device. Would you like to own me?”

Dave makes some "interesting" claims in his blog.  Here's a quote:

This may sound eerily similar to my car hacking blog which discusses how a diagnostics port was used to subvert a car’s brakes and engine. What I didn’t mention then is that this hacked system also runs an RTOS: QNX. 

Hmmm.  Sounds damning, doesn't it?  He follows this with an immediate pitch for a GreenHills Security Kernel product.  I work for QNX, so I just had to look further.

I read the actual academic report that he bases his "information" on. Dave apparently doesn't understand cars or doesn't understand what problems his own company's product is supposed to solve.  The reasoning  used to implicate QNX by interpreting the academic report is faulty at best.  The premise of the study is that with an OBDII tool you can send arbitrary messages on the vehicle bus.  Since every car has an OBDII port (by government mandate for emissions monitoring and control), you can "hack" into every car.  This "hacking" allows you to do all types of things to the car, from shut off the engine, control the brakes, reflash the telematics unit, etc.

In a word (or maybe two), "no duh".  When you bring your car into the dealership, how do you think the techs communicate with it?  They don't whisper it back to health!  The paper describes doing things to the car while moving: they've set up a laptop with WiFi that they've plugged into the vehicle bus while driving along side in a chaser car.  Not exactly something that is practical without physical access to your car.  One of the things done in the hacking test is to replace the telematics unit firmware (the module running QNX) with a custom firmware image that lets them transfer messages between the low-speed and high-speed CAN buses as a bridge.

Oh my goodness!  How could QNX allow a hacker to replace the RTOS firmware image?!  In fact it's not a surprise, because that requirement is written into the specification.  That's right.  For a dealership to update the modules within the car, those modules need to be able to be reflashed.  Every module has this requirement. I don't care if your car module is running the QNX Neutrino RTOS, or the QNX Neutrino RTOS Safe Kernel, or the GreenHills Superfragilisticexpialidocious kernel or Kumquat OS 9.9.  If the module is actually operating properly, it will allow itself to be reflashed. Period. The purported problem cannot be solved by use of a security kernel whether from GreenHills or anybody else.

The true problem being pointed out by the academics is that the car vehicle network, for better or worse, was designed as if it were a closed system.  The only thing that prevents malicious mischief is the difficulty of gaining physical access to the vehicle bus connectors.  I would agree that vehicle buses probably need to start considering authentication / identity verification / challenge / response protocols in their design. Because the dealers will always have the requirement to fix/diagnose/update cars, they will have access to tools to let you do this.  No matter what you could design to solve the "closed network" problem, it can be abused by unscrupulous people.

GenIVI report slams QNX. Independent view seems to differ.

While Canada was sleeping (yesterday was the Civic Holiday in Canada), the GenIVI Alliance released a report that "predict[s] QNX will withdraw from the IVI market eventually. Questionable future is also due to lack of a consortium (such as GENIVI) to drive the architecture."

Seems a little self serving for GenIVI to state that we won't be successful because we're not GenIVI.  It's news to me also that we're withdrawing from the market, especially since we're hiring more people every day in support of the business we're continuing to grow.

Apparently the report doesn't hold water with independent analysts either.  Roger Lanctot in his Strategy Analytics blog disputes quite a few points in the GenIVI report as simplistic or overstating the facts.  He shows too that the report attempts to bolster the GenIVI point of view without providing any real evidence.  Interestingly enough, the GenIVI report claims that it interviewed people throughout the industry, including QNX.  I'd be interested to know who exactly they interviewed at QNX and what they contributed to that report.

The GenIVI Alliance publishes the summary report, but of course you can't read the full version of the report without joining GenIVI.  (No wonder they have so many members!  Maybe I should publish a slanderous white paper about GenIVI, but you have to join QNX CAR to read it :-)

QNX, BMW and Apple iPod Out

QNX has had a long tradition of being independent.  When we were acquired by Harman International, a big automotive tier one (Harman Becker) suddenly became our sister company.  Many of our automotive customers were concerned if we would still support them, since Harman Becker was one of their competitors.  Non-auto customers were worried that we would just drop their market altogether.  We proved our commitment to our customers with more than just words, and some of the most vehemently concerned customers eventually admitted that we were treating them even better after the acquisition than before.  That is, more responsive, more proactive, more resources, and quicker technology rollouts.

After RIM acquired QNX, I expected another round of the same customer concerns about QNX and our continued direction.  It really hasn't materialized, I guess because this time around everyone clearly sees that there is a very natural fit to RIM and QNX.  About the only thing we hear these days is the occasional question from customers about whether or not we will still support the technologies they care about.  An example is: "since Apple and RIM are competitors, are you going to continue supporting Apple devices?"

The answer is, of course "yes," but the proof in the pudding, as they say.  How about this:
http://www.ubergizmo.com/15/archives/2010/07/bmw_to_support_ipod_out_in_the_future.html

Apple's iPod Out feature is a brand-spanking new feature that Apple just released in OS4 that allows an iPhone or iPod Touch to pump an Apple-customized video HMI to an automotive head-unit. It's not available in any production models today, and BMW is the very first car company to announce support for it. I'll give you just one guess which operating system is being used for this project.  (And despite BMW's highly public Linux strategy, please don't waste your guess on GenIVI :-)

Although the feature is hot off the presses, here's a shaky-cam snapshot of our very own Mike Shane running the QNX Neutrino RTOS with a preliminary version of the iPod out feature integrated into our iPod driver.

Biking in Oregon

Although I've been back for a week now and the post-vacation buzz has subsided to a whisper, I thought I'd share a couple pictures from my recent trip to Oregon where I spent some time biking down part of the coast.  It was a fantastic trip!

The key fob is dead! Long live the key fob!

Here's some food for thought.  I was reading in the latest SAE about how key fob powers are becoming broader vehicle personalization devices.  They are doing much more than just an unlock: remote start, rolling down windows, checking temperature, controlling vehicle seat settings, radio presets, colors, and almost any other preferences you can think of.  The article by SAE goes on to quote Lear and talk about how they see the fobs requiring feedback so that you can monitor the vehicle settings remotely as well.  To handle all these capabilities, they're bumping up the processors from 8-bit to 16- or 32-bit processors (can't say that I'm sad about that), as well as putting in small LCD screens.

Okay.  Combine that fact with some other recent announcements.  Like the smart phone apps from Chevy for the Volt or the OnStar smartphone app that lets you access your vehicle.  Delphi makes a system today that right now uses a combination smartphone with a souped-up key fob and range extender.

It's not hard to see that key fobs as we know them are going the way of the dinosaur.  Why on earth are you going to carry one more huge lump on your key chain when you've already got your phone?  I predict that within the next 3 years, key fobs will be those extra-expensive optional add-ons that will be sold only to the severely technologically challenged.  Everyone else will download their OEM's specialized key fob app into their smartphone.  Those key fob apps will use WiFi, Bluetooth, or a cellular network to communicate with their vehicle--unlocking it, starting it, and setting it up specifically for you.  Smartphone apps won't require additional hardware costs.  And they're already an indispensable part of the everyman's (and everywoman's) arsenal.

I'm looking forward to the day when I don't have a key fob, but a key fob app.

"Honk if you love Jesus...

...Text if you want to meet him."

Amusing bumper-sticker a friend of mine recently saw.  I think it accurately encapsulates many people's thoughts on Texting while driving.  It's also very interesting to note how many of us do it.  I think it's one of those hypocritical things humans think where "everyone else is a danger, but not me--I'm the exception."  Rules are always made for everyone else.

Infotainment systems are starting to have a wide array of capabilities--certainly we're creating technologies that provide people with more productivity, more connectivity, and more entertainment than ever before.  Most people see this new technology as a good thing, but also understand the inherent risks of driver distraction.  It seems that the most vocal combatants of using in-vehicle technologies are from older generations.  The younger you are, and the more you take the Internet for granted, the less likely you are to see texting or calling or computer use while in travel as a problem.

Some driver distraction issues can be solved by system improvements like providing more intuitive and multi-modal (voice, button, touch) interfaces, by limiting what can be done while driving, by having smart systems that understand driver workload and scale back when necessary, or by providing configurable options to let drivers control their own environment.  At the same time that technologies within the car will continue to improve to assist the driver. Adaptive cruise control and tail gating prevention, lane departure warnings, and further driver assistance technologies will expand and become standard features to help the driver stay focused.

I think the long term shift will be a combined societal and technical view.  People will come to accept this informational bombardment and learn to work with it.  As an example, look at the changes in societal views towards driving under the influence.  Any movie from the 40's through the 60's shows an incredible caviler attitude towards alcohol. They don't seem to recognize it as a danger at all.  There was no peer pressure, no fatality statistics, no laws, no personal tragedies, all forces combining to cut down on drunk driving.  Today, albeit not perfectly so, people are in large part self-policing.  They understand the risks and dangers, and although there are still fatalities, the public stigma and peer pressure keep the number of violators down.

If anything, technology use in the car will expand, not shrink.  Today's youngsters are growing up with multitasked driving as part of their mental framework.  By the time that all today's teenagers become senators and parliamentarians, I'd expect that all laws about texting while driving will have repealed, and cars will practically drive themselves.

Except for the personal helicopters--you'll still have to pilot those yourself.  And they'll be hands-free only.

Earthquake at QNX

We just had a little shake and shudder from an earthquake (5.7 in Kanata).  Quite an experience, especially since I'm on the second floor.  I'd have to say that we do better in our fire drills than we did to evacuate the building this time--we all looked around at each other like "What was that?"  Anyway, all safe and sound, and no apparent harm.

(All I can hope is that my blog posts before my uber-posting blogging coworker, Paul.)

Google Android: When is free not free?

Free isn't free once it's become fodder for the IP patent trolls. HTC who is building an Android phone, now has to pay Microsoft for patent rights on that phone. And after Apple's lawsuit against HTC ends up getting resolved, I bet that they'll be making payments to Apple as well. Software patents give Microsoft and Apple the ability to punish Google for its audacity of entering the growing smartphone market. It's ironic that the only people who won't get paid for the HTC Android are the people who wrote the code in the first place.

I remember the first patently stupid patent I heard about was for an xor cursor (#4,197,590), when it was already in such common use everywhere it seemed ridiculous and offensive to patent it. Patents aren't supposed to be covering prior art, nor "obvious" inventions. That is one serious thing wrong with the software patent system. People who do open source development leave all their code out there to be examined and combed through. Combed through by lawyers for similarities to an existing patent arsenal.  When a developer is clearly ripping off someone else's work, then a software patent makes sense. But if it's already floating around in the either or its obvious, it shouldn't get patented. Neither of those things is anywhere near possible for the patent office to determine with any amount of rigor. It seems fundamentally unfair that the only people who get to profit from software inventions are the ones with the cash and the time to pursue the patent process: big sharks, not little fish.

I'm not arguing on the validity of Microsoft nor Apple's patents. They could all be great inventions and 100% absolutely legit. And it's not Google that I'm worried about for protection against patent lawsuits. They're plenty big enough to take care of themselves. And I'm sure that HTC can just bump up the cost of their phones by a few bucks to pay for all the patents they're now licensing or will have to license. It's all the other hordes of software developers creating open source software on their spare time using their goodwill.  Developers that don't have the time or resources to patent everything they've done. Developers who wouldn't know that what they're creating in the dead of night is accidentally similar to something in someone else's IP portfolio.

Watch out if your little pet open source project gets noticed. Patents aren't protection--they're a weapon in a software arms race. It's a minefield out there.

Response to “Thoughts on Flash”

Steve Jobs’ recent comments about the refusal to use Adobe Flash on Apple mobile platforms have gotten some notoriety in the technical world.  Although Adobe CEO Shantanu Narayenhas has provided a response, the debate has led to some QNX customers asking if there are issues that would impact their embedded system designs that use Adobe Flash or the QNX Aviage HMI Suite.  There are not.  This letter will address the concerns raised by Mr. Jobs about the suitability of using Adobe Flash.

• “Flash is a closed system.”

Mr. Jobs describes Adobe Flash as being “100% proprietary”, “only available from Adobe, and Adobe has sole authority as to their future enhancement, pricing, etc.”, and further comments about Adobe being closed.  However, that language would also describe the situation created by Apple. Apple controls the OS, the development tools, the development machines, the app store, the application approval process, and even the language used to create applications.  Objective-C is not used in any other environment besides Apple and is defined by Apple, just like ActionScript from Adobe. In itself, these facts are not an issue, since both companies develop and promote both proprietary and open portions of their technology portfolio.

However, Mr. Jobs goes on to talk about how Adobe Flash products are “available only from Adobe.” Whereas this statement is in fact true for Apple’s development products, it is not true for Adobe.  Adobe has published the definitions of the language, APIs, file formats and more.  In addition to the Adobe tools, there are a number of open source tools that are created and used by Flash developers, like the Adobe Flex SDK and Flash Develop (Flash IDEs), MTASC (Flash compiler), Ming (Flash library), Gnash (a GNU swf player) and Tamarin (a Flash VM with JIT).  Unlike the Apple environment, developers are able to do Flash development using open source and community tools, which is contrary to the “closed” stance that Mr. Jobs has mistakenly communicated.

• “Symantec recently highlighted Flash for having one of the worst security records in 2009.”

Contrary to Mr. Job’s statement, the referred to report from Symantec does not claim that Flash has one of the worst security records.  Rather, it points out that the broader the software availability, the more likely that exploits will be attempted against that software.  More specifically the report notes:

“Because [IE and PDF] technologies are widely deployed, it is likely that attackers are targeting them to compromise the largest number of computers possible. Of the Web browsers analyzed by Symantec in 2009, Mozilla® Firefox® had the most reported vulnerabilities, with 169, while Internet Explorer had just 45, yet Internet Explorer was still the most attacked browser. This shows that attacks on software are not necessarily based on the number of vulnerabilities in a piece of software, but on its market share and the availability of exploit code as well.”

Analysis of the actual report is needed to explain what is being claimed by Mr. Jobs.  Symantec lists the five top web vulnerability targets as:

1)      Microsoft Windows SMB Remote Code Execution

2)      Adobe Reader and Flash Player Remote Code Execution

3)      Microsoft IE 7 Uninitialized Memory Code Execution

4)      Microsoft Windows ActiveX Remote Code Execution

5)      Adobe Reader Collab Javascript Remote Code Execution

Only vulnerability #2 might apply to an embedded deployment of the Adobe Flash Player, since #5 refers to PDF files using the Acrobat reader. However, the details of vulnerability #2 affect browser plug-ins only and not embedded systems, since it requires running a maliciously crafted .swf file (the compiled Flash binary) hosted on an attacker’s web site.  On an embedded system the .swf file content is completely static, and .swf files are created and controlled by the developers. Even in embedded environments that use a browser, the system would be protected from potential malicious execution by virtue of QNX’s microkernel architecture. Under the QNX Neutrino RTOS, the browser process is completely isolated from every other system process, and exploits like memory overruns that can be used to gain kernel privilege in a monolithic operating system are not possible.

           

Most importantly, the attacks in question have been patched for some time.  The number of attacks reported by Symantec in 2009 is actually not related to existing vulnerabilities, as the report further explains:

“Many of the vulnerabilities observed through Web-based attacks in 2009 have been known and patched for some time. For example, the Microsoft Internet Explorer ADODB.Stream Object File Installation Weakness was published on August 23, 2003, and fixes have been available since July 2, 2004, yet it remains the second-ranked Web-based attack. This is likely because of the use of Web attack kits like Fragus, Eleonore, and Neosploit. These kits come bundled with a variety of different exploits, including some exploits for older vulnerabilities. Because an older vulnerability is likely to be included in more kits, it will probably be seen in more attacks than many of the newer vulnerabilities.” 

The number of attacks is not a correlation of actual vulnerability, as Mr. Jobs incorrectly assumes. There are no reports of Flash vulnerabilities when Flash is being deployed in an embedded system.

• “Flash is the number one reason Macs crash.”

The idea underlying this statement comes from reports about process failures that users choose to send back to Apple.  It is worthwhile to note that these are not instances where the Mac OS itself is crashing, but instead are Mac programs that crash.  Those user reports identify browser plug-ins as the most frequent source of process exceptions.  Further information that details the specific errors that are received has not been divulged by Apple.  Since Flash is the most pervasive software platform, reaching 99% of Internet-enabled desktops, and the assumption that Flash is the most popular and widespread plug-in, then it stands to reason that it will be responsible for a larger frequency of plug-in failure reports.  If a crash occurred once out of a thousand times an application was run, but it was run one thousand times more often, it would show up with identical crash statistics as a piece of software that crashed every single time it was run.  This is not an indicator of software quality, but of the depth of software deployment.

Adobe’s chief technology officer Kevin Lynch says in an interview with PC Magazine that “Regarding crashing, I can tell you that we don't ship Flash with any known crash bugs, and if there was such a widespread problem historically Flash could not have achieved its wide use today."  Flash is deployed on many embedded devices that do not experience the crash results that Mr. Jobs has claimed.

• “Flash has not performed well on mobile devices.”

This statement is not accurate, and reflects an outdated understanding of Flash. Current versions of Flash and FlashLite perform very well, and the Flash rendering engine can use hardware accelerated graphics on many platforms.  QNX has analyzed the performance of hardware accelerated Flash, observing a substantial speed up in most cases. External assessments of Flash 10.1 and HTML5 show that Flash compares nicely:

"When it comes to efficient video playback, the ability to access hardware acceleration is the single most important factor in the overall CPU load," concludes Jan Ozer, "On Windows, where Flash can access hardware acceleration, the CPU requirements drop to negligible levels. It seems reasonable to assume that if the Flash Player could access GPU-based hardware acceleration on the Mac (or iPod/iPhone/iPad), the difference between the CPU required for HTML5 playback and Flash playback would be very much narrowed, if not eliminated."

• “Fourth, there’s battery life.”

Mr. Jobs provides little evidence that Flash’s battery consumption is poor.  He instead explains the problem as fundamentally related to how people host their video content. Even this unrelated assumption is based on an incorrect understanding of Flash capabilities, namely that the Flash player does not support H.264 video format (which has been supported in Flash since 2007).

Video playback aside, most embedded Flash execution that concerns itself with battery life will be under control of the developer. FlashLite has been used for the user interface for mobile phones from Samsung, Sony Ericson, and LGE, shipping on over a billion phones, and is very capable of performing with optimal battery life.

• “Flash was designed for PCs using mice, not for touch screens using fingers.”

This is true, but it is also true for Apple’s technology.  However Adobe Flash, just like Apple’s development environment, was easily retrofitted to handle touch screens.  QNX has demonstrated many Flash based systems that employ a touch screen.

In summary, the claims levelled by Steve Jobs towards Flash are either not substantiated or untrue.  Adobe is fundamentally a cross-platform tool, which is noted by Mr. Jobs himself several times, and as a cross-platform tool it enables leveraging development effort across multiple platforms.  This means that developers using Adobe Flash would not be locked into the iPhone or iPad development target, and would be able to use their software efforts across a broad base of devices. It would appear that Mr. Jobs’ stance against Flash is for business reasons, not technical ones. Gartner research vice president Ray Valdes provides a similar assessment towards the purpose of this attack:

"This is not about technology. The criticisms from Apple about Flash can also be applied to many other systems that Apple has not directly opposed. Therefore Apple's stance appears driven by their business need to protect the iPhone platform against the threat of a cross-platform competitor."

ARM wrestling with Intel

I got passed this very interesting article by a colleague. It talks about the uphill battle Intel faces breaking into the smartphone space, primarily due to being a big monopolistic company that can survive only on high profit margins. Just as interesting is the huge variety of primarily well-thought-through comments below the post.

Why Intel Will Be a Mobile Loser

RIM breaks into top 5 cell phone makers

Now that I'm part of RIM, I'm a lot more sensitive to RIM-related news as you might guess. Like this: Reuters analysis of Smartphone market: RIM makes top 5. This happy little tidbit explains how RIM has finally broken into the top 5 cellphone makers, edging out Sony Ericsson.

Software is the key thing that differentiates the top smart phones from the rest of the pack. That puts the pressure on LG and Samsung, who haven't been traditionally strong in that area. And HP just acquired Palm to get the Pre software. It's going to be an interesting summer...

What's the newest Blackberry going to look like? Take a peek at this, announced last week at WES 2010:
Blackberry OS 6 preview video. One of my smart-alec coworkers said that apparently you have to learn how to dance to use the phone. Naw. You just have to like the Black Eyed Peas.

Atmel OS Survey

If you're using an Atmel board with QNX, please take this OS survey from Atmel.
Atmel Community Page, middle right-hand side, and vote for QNX.

I think the fact that the survey requires a registration may be putting people off, but I know you're out there.  Come on, show your support!

QNX at ESC 2010

Not an especially inspiring blog title, but maybe I'm still adjusting to the time zone change.  I just got back from the Embedded Systems Conference in San Jose last week, and it was a good show for us.  We showed the LTE Connected Car, based on our QNX CAR Application Platform. That was interesting enough that we got included in a video montage for the keynote on the third day.

ESC Keynote video, Day 3

(forward to 1:30 for my 15 seconds of fame :-)

Blue lighting for this show.  All... my... friends... know the Low Rider.

Also at this show was a demonstration of balancing an inverted pendulum.  Yes, we still do real-time.  Here's the shaky-cam version of it, with me giving it a couple pokes to show that it's really working.

Now, what went wrong? Nothing major, but end of the show was hectic. The fit between the lightboxes under the car was very tight. Enough air escaped from the tires where we had to manually lift the car to slide the boxes out during the show tear-down.  (Thanks Dave and Dave!)  We had to ship stuff from the show directly to Japan and Germany, which our shippers said they couldn't do, although our event coordinator Alison had checked with them first and they said they could.  So we had to literally run a bunch of stuff over to Kinkos.  (Thanks Kinko's crew!)  And ESC scheduled me for a presentation after the show ended. Yes, that's right. Right in the middle of the shipping and booth teardown was my presentation about Smart Screens. How completely stupid is that? Obviously, I didn't have great attendance--just a handful of diehards to hear me talk about solving design issues with Smart Screens, using our Smart Energy Reference Design as a use case. (Thanks to you who stayed for my talk!)

I rushed off right after the talk to attend the San Jose Sharks vs. the Detroit Red Wings, with just minutes to spare.  (Thanks Kroy and Ali!) I was one of the ten people in the stadium rooting for Detroit, but unfortunately we lost. There's still some time to make it up--go Wings!

Yesterday QNX Wins OCRI Award. Today QNX Acquired by RIM

I attended the Ottawa Carleton Research Institute awards last night as part of the QNX contingent. We were there as finalists for an award with Alcatel-Lucent for the OCRI Strategic Partnership of the Year. And we won! I was pretty excited to blog about that this morning.

Except that this morning there's a slightly more pressing bit of news and something a little more exciting to blog about. QNX will be acquired by RIM, which was announced this morning at 9AM. Exciting!

What does it all mean for our customers and our markets?

• We're staying in automotive, and increasing our focus on devices and connectivity with initiatives like QNX CAR.
• We're still going to be supporting Harman-Becker and all of our other automotive customers. 
• We're staying in the industrial space, and continuing to support those customers and processors with real-time improvements, industrial protocols, and multicore support.
• We're going to be continuing our innovation in products and strategies around HMI development
• We're going to be expanding our staff to handle new challenges.
• We are scaling back unfettered access to Foundry27, but we'll still provide all of our BSPs in source, and our source code will still be available free of charge to customers who need it.

There are plenty of questions I can't answer, even if I knew the answers. But expect that new and exciting developments will be coming your way...

Old Programmers Don't Die--They Go Embedded

Sometimes, I feel old. When I point this out, my friends older than I use that occasion to remind me that I'm really still quite young; my friends younger than me are quick to agree just how old I am. I know it's all relative. One way for sure I know I'm an "old tymer" is when I get a chance to talk to kids fresh out of university. Most think that the computers they know and love just sprang into existence. They're happy to be using Java or C# without a clue about all the machinery that's going on underneath the scenes. The concept of creating your own windowing system or memory management or OS or compiler never even occurs to them--it's a given. Why would anyone write to video memory directly? Yeah, just pull in that 30MB library--I really need that one function. What's an opcode, and why isn't the debugger showing me the source?

That's why it was fun to do a little reminiscing while creating my webinar. I roamed through a lot of my musty old code from years back. Sadly, I still remember programming over the years on a steadily improving array of equipment. I don't recall every line, but I do remember certain key lessons learned. For the reminder of those that should know better and the improvement for those who never knew, I tried to wrap up some of the most poignent best practices into my webinar.

My webinar's focus was on embedded programming, with good reason. Embedded is still an area where some of those older techniques are still useful. Yes, today there are better tools, compilers, frameworks, you name it. But you'll always have a few more limits and a little bit more constricted environment when programming an embedded device, no matter how powerful it is.

Case in point: I'm currently learning Objective-C for Mac/iPhone development. It's fun. It's been a while since I've had to completely bathe in a new environment, language, and paradigm, all in one. But most of the resources I've found are somewhat tedious. They cover details from a beginner programmer's standpoint. Instead of just telling me what's different, they insist on telling me everything and forcing me to wade through reams to get those little nuggets. Ugh. In this process, let me pass along a link to a very useful document, just in case you're a die-hard C++ programmer who wants to learn Objective-C and doesn't want to learn how to program from scratch. C++ and Objective-C are both object oriented dialects of C, but they're exceedingly different. (And thank you Pierre.)

What does learning Objective-C and the iPhone have to do with old-tyme embedded programmers? The iPhone has 32MB of RAM, but it doesn't support garbage collection, so you can't be lazy with your memory management. Not everything that Mac programmers have gotten used to will work on the iPhone. Because, it's (say it people) embedded. Maybe some of those old tricks will come in handy still after all...

QNX turns 30! What was happening way back then?

Sometimes it's very fun to be taking a trip through memory lane.  With QNX turning 30 this year, I've been hauling old QNX manuals out of storage, conveniently archived just feet away from my desk, and doing a bit of research for some interesting tidbits to share for our birthday celebration.  Looking through all those old typewriter banged out manuals with the occasional white-out and hand-penned corrections brought back fond memories.

I wasn't using QNX back in those days.  I was programming in both BASIC and 6502 assembly on an Atari 800.  Writing my own games, truth be told, since I didn't have lots of spare cash on a paper route income.  And I was typing in listings from magazines like "Compute!"--yes, in fact, once upon a time the best way to get programs was to type them in from a listing in a magazine.  Hard to believe in an era where you can download gigabytes of free software while sitting on your living-room sofa.

At that time, QNX was called Quantum Software Systems.  And Quantum Software System's first product was called QUNIX: a microkernel-based OS that felt a little like UNIX.  AT&T was very polite in requesting that we change the name, and so QNX was born.

QUNIX released as product in 1981

Description:First commercial microkernel OS

Inventor:Dan Dodge and Gordon Bell

Impact on civilization: Showed it was possible to have a multi-user, multi-tasking, multiprocessor OS with real-time performance running on a PC with only 64K of RAM. It and its successors (QNX2, QNX4, QNX Neutrino RTOS) spawned many uses in reliability-critical industries.

What else was going on at the time of QNX's first product?  Two other notable software products were created right around then: one about 6 months before, and one about 6 months after.  You'll certainly recognize one.  If you've been around in this industry for long enough, you should recognize both.

Visicalc introduced on PC in 1981

Description: First commercial spreadsheet

Inventor: Dan Bricklin and Bob Frankston

Impact on civilization: Made personal computers a serious business tool instead of a hobbyist orgame machine. Visicalc was first created in 1979, but it effectively launched the Personal Computing industry, by bringing IBM to the party in 1981.

I remember this pretty distinctly--my Dad bought Visicalc for the Atari 800. It made heavy use of the slash key for doing almost anything. It was pretty limited compared to Excel.  At the time, it was amazing to see numbers magically recalculated all over the page when you changed one little thing. All done in 48K. If you're feeling nostalgic, you can run a real version of this on your Windows PC for old-tymers found on Dan Bricklin's website.

MSDOS 1.0 released in 1982

Description:Common PC OS

Promoter/Inventor:Bill Gates / Tim Paterson

Impact on civilization: Created a common architecture for software development, spawning an industry. And created the world’s wealthiest person. (As of Mar 10, 2010 due to Mr. Gates' generous philanthropy and the depressed state of the stock market he was bumped down to the second wealthiest.)

By the time the IBM PC XT came out in 1983, I was gainfully employed writing statistical quality control software. Yes, it was in high school, but a real job, nonetheless.A 5MB hard drive--WHOA. That was big time. How on earth could you fill the whole thing? (Easy--put one single mp3 song on it.) In the intervening year, Microsoft DOS 1.0 had been replaced by MS-DOS 2.0. A major improvement and still with lots of warts, but it was the OS of choice for business applications. GW-BASIC was the language that my company used back then. I remember the good times when we'd have compiled basic programs give the occasional "Syntax error". Think about that for a second. It's a lot funnier now than it was at the time. We eventually replaced GW-Basic with Turbo Pascal, but I digress. Maybe that's fodder for another blog.

Embedded World Germany 2010

I've just returned from a trip to Embedded World Germany in Nuremberg, which is probably the biggest show for the embedded market.  You see a lot of the familiar faces in the embedded space from all around the world there.  Where else could you be talking to German, Norwegian, French, American, Canadian, and Japanese business people all within the span of ten minutes?  

My days were filled with press interviews, conference presentations and talking to customers.  My nights filled with scouring the schnitzel and sausage-filled menus for something, anything, green to eat.  The Olympics wrapped up while I was in Germany, and I got to have all my Canadian colleagues give me a good natured razzing after the Canadian hockey team beat the US 3-2 in overtime.  I guess I can finally admit that hockey is Canada's game and winning the silver is not bad!  Congratulations Canada!


The year's show was a great one for QNX.  There was lots of activity and interest in our Industrial developments--our Smart Energy reference design, our Building Automation demo, our Industrial protocol work with partners, and our real-time control demo.  On the automotive side, we were showing our latest QNX CAR with all the extra ng Connect features.  That same QNX technology went into the 2010 Audi A8 MultiMedia Infotainment system with full multimedia and Google Earth maps which had everyone drooling.  More than one person told me "this is my next car," and I don't blame them!

The show is now all packed up and everybody is home recovering from jet lag.  So I guess I'll see everyone next year!

Toyota's woes: why simplistic solutions are dangerous

Automotive Designline has had a couple of opinion articles targeting the latest trials and tribulations of Toyota.  One is very fatalistic, and seems to call for removing all software in the car:

http://www.automotivedesignline.com/222601160;jsessionid=R0JLVIU0OI4O1QE1GHPSKHWATMY32JVN?pgno=1

Much of the issue Toyota faced had to do with floor mats, which doesn't involve software, and broadening the "software-is-buggy" concern to the entire recall is alarmist. Even if the recall were wholly due to software, it is not realistic to remove software from today's automobile.  Cars are not going to be designed without software, period.  In fact, if anything, the opposite is happening: more and more software is going into cars.  Customers want piles of features for cheap, and automakers want the flexibility that comes with software solutions.  Innovation and driver safety is enabled by software: adaptive cruise control, digital instrument clusters, pedestrian and animal warning, hybrid powertrains, parking assist, and fuel saving ignition systems all require software to work.  Lightweight drive-by-wire saves cost and enables safety features like lane drift adjustment .  Anti-lock brakes, once a "scary" feature have now become common-place and standard issue.  And infotainment and navigation systems are continually growing in popularity and demand.  Becoming a luddite or a technophobe will not stop progress.

The other commentary is from a hardware engineer who is rather naive when it comes to software:

http://www.automotivedesignline.com/howto/222900488;jsessionid=S04CYVBB1KFZNQE1GHPSKHWATMY32JVN?pgno=1

His effective point is that "hardware validation is successful, and hardware engineers can get it right, so move those methods to software."  Firstly, that does not reflect my reality, where hardware problems and corner cases are found all the time in embedded development.  Hardware bugs slip through the validation net for lots of reasons: inappropriate tests, unanticipated use, incomplete testing, improper design, and bad requirements to name a few.  Hardware bugs are far more expensive to fix, so it's usually software to the rescue.  Hardware appears "perfect" because there are almost always software workarounds helping the hardware along!

It is also almost insulting to think that applying hardware verification methods to software is the "fix" for automotive software quality control.  It belies a poor understanding of software development, and can only be because the author does not understand software processes, the complexity of software, or how software is created. There is already an entire body of knowledge around software development processes, quality management methods, and best practices.  Software methods are fundamentally differently than hardware methods because the two products are created and designed using orthogonal methodologies.  Software engineering disciplines may not be as clear cut as designing a circuit board or an IC, but they exist already!  Those methods are already well understood by automotive companies and suppliers.

If software keeps coming into the vehicle, and we need to make the vehicle safe, what can be done?  What's done in industries like aerospace is things like dual-system redundancy, triplicate voting systems, or exhaustive test beds.  Those things add tremendous cost and lengthen development.  Car customers like you and me are not governments or airlines with multi-million dollar budgets buying products that will be maintained for several decades.  No: customers are not only price sensitive, but time sensitive.  Fickle buyers want this year's features today, not in five years.

You can use software to help.  The earlier you find bugs, the better, and some systems are better at early identification of bugs than others.  Multiple-address space designs are than single-address space designs by forcing erroneous code to crash.  This is a good thing--it leads to far quicker isolation, identification and resolution of problems.  A microkernel design like the QNX Neutrino RTOS isolates every system process so that device drivers, software stacks, and applications are all treated with that same level of rigor.  Pro-active measures like high availability systems can ensure that software recovers gracefully from faults.  It is your insurance that the software will still operate properly, even in the face of undetected errors.  Time partitioning systems can be added to ensure that software is always getting the minimal required CPU cycles.  Time partitioning protects against unanticipated log-jams of system activity that would otherwise cause missed deadlines and system failures.

QNX has been helping people design bullet-proof software in use in safety-critical systems for 30 years now.  We know that it isn't easy.  And we know that it requires discipline.  But it doesn't require throwing out the baby with the bathwater.  Nor does it require some kind of silver bullet.  Just good practices and good software.  And good management to pay attention to engineers when they say something isn't yet ready to go.

The Power of a Tweet

I was reading Science News the other day: the full article is here, but I'll summarize for you.  Basically, the USGS has a program that scours Twitter to look for earthquake related words.  What they've found is that they can get immediate feedback on location and severity of earthquakes by dredging up and analyzing those tweets in real-time.  The "tweet-powered" software works much faster than the normal earthquake-related analysis, which can take up to 15 minutes after the actual shake happens.  And that 15 minutes can give emergency assistance teams the edge in reaching quake victims.

Did anyone ever think Twitter could save lives?  Not me.  I hate to say, but I might be coming around on Twitter.

What is a Software Ecosystem?

I'm putting together a slide deck, and I wanted to find some ideas for software ecosystem images.  The software industry uses "ecosystem" all the time to refer to all the companies that are participants, purchasers or providers of software related to your company.  For example, with QNX and our Neutrino RTOS, it means companies that are providing software on top of Neutrino, software tools that work with it, libraries that are ported to it, etc.  Naturally, we have a huge QNX ecosystem (which I was trying to brag about in my slides), and I thought it might be cute to have a nice little image to accompany the slide.

So I found it exceptionally amusing that the first whole page of Google Image results on "ecosystem" were all the circle of life like this:

Why I find this funny is that (unfortunately for most everyone in the diagram) all the members of this ecosystem are trying to eat each other.  This is not what we normally are trying to imply by the use of "ecosystem" in software.  In fact, we're trying to more imply something far more cooperative, like a indigenous village.  But "come join our software indigenous village" just doesn't roll off the tongue.

I posted this blog entry because on even further reflection, the food chain metaphor is actually quite appropriate. All the software companies are:

• Trying to eat each other (corporate aquisition)
• Trying to eat someone else's lunch (competitors)
• Eating someone's waste products (startups filling niches left by the big guys)
• Creating basic food at the bottom of the food chain (open source development)
• In a symbiotic relationship (services organizations)
• In a parasitic relationship (consulting)

Of course, this isn't such a flattering image of the software ecosystem.  But it is an accurate (and hilarious) view of just what we mean when we say "ecosystem".  Just hope that you're a carnivore (too bad I'm a vegetarian!)

Canoeing in the Everglades

This blog entry isn't about work, but it's about play.  Provided that you consider play to be taking a 75 mile paddling trip through the Everglades on the ocean and through mangrove swamps.  Let's just say that I had a remarkable Christmas vacation, and that I didn't think about work once.  There's nothing like non-stop physical exertion leagues removed from civilization to give you true peace of mind, in touch with the human condition and with the earth itself.

I didn't take many pictures, but this is one of my favorites.  It's Highland beach on the Gulf of Mexico, where we had a beautiful campsite and a very memorable sunset.  That morning we spied suspicious hoof marks around our tents, and after we launched the canoes in the morning sun, saw an endangered Key Deer investigating the beach.  Truly amazing.

Okay.  Back to work.