8 bit processors. Still? Seriously?

Maybe I'm showing my age, but I remember the good old days. The first processor I programmed for was a 6502. Followed by a list of other illustrious 8-bit processors, like the 8088, the Z80, and the 8080. All either in assembly or a mix of assembly and Pascal--remember Borland, anyone? Sometimes assembly and C.  Then came all their 16-bit friends, which were more of the same ilk.  Life was simple then--there wasn't any code in the system that you didn't write.  Total transparency.  And total control.

But the good old days weren't always so good.  The romantic simplicity of those times is overshadowed by the memories of all the hassles and engineering challenges in dealing with those 8-bit dinosaurs.  The constraints on those processors were huge: very little memory, very sparse registers with dedicated functions, and arcane mixes of available instruction/register combinations.  Lots of time packing and repacking functions, rewriting to save every spare byte because the chip couldn't address any more than a squeak of memory.  Making your code impossible to fix or edit, because you had a clever trick to save ten bytes by manually chopping out snippets out of the generated assembly.  Confusingly overloading functions, inexorably linking code for two totally unrelated purposes, like the calculating the display column offset and delaying for proper timing of an A/D read.  You know... in hindsight, those days were truly awful.

Still today, although the 8-bit well has almost dried up, companies are selling and creating products that use 8-bit and 16-bit processors, when 32-bit and 64-bit processors are available.

Why?
The answer is easy--cost. 

Unbelievably, it's still cheap to make those antiques.  Either that, or there is just some warehouse in New Jersey that's piled ten stories high with the junk.  Having known how difficult it is to squeeze some life out of these tired old dogs, I can only pray that they just go away for good. 

Why?
Because I care about software engineers and their mental health.

The true cost of programming for 8-bits is lost productivity.  Engineering time is not cheap, and although it often isn't considered, an accurate cost assessment needs to amortize engineering effort over the life of the product.  For a consumer electronics device, the life of the product is preciously short, and for every cent you save on using an 8-bit processor, you add a dollar's worth of engineering time to the bill of materials.  In the brave new 32-bit world, productivity is amazing--you can crank out code in a fraction of a time using modern tools, libraries, OSes, and applications frameworks.  32-bit tools can completely blow away what is even possible an 8-bit micro, all the while the other guy is still debugging his old fashioned bubble-sort routine.

For the sake of software engineers everywhere, let 8- and 16-bits die, once and for all.  I'm there for you, you poor non-32-bit engineers.  Until that day.

Sink or swim with the GPL (GNU General Public License)

Here's a headline you might find interesting:

New York, NY, December 14, 2009//Best Buy, Samsung, Westinghouse, and JVC are among the 14 consumer electronics companies named in a copyright infringement lawsuit filed today in New York by the Software Freedom Law Center (SFLC).

(Here's the URL for the full article: http://www.softwarefreedom.org/news/2009/dec/14/busybox-gpl-lawsuit/ )

The full list of companies being sued is Best Buy, Samsung, Westinghouse, JVC, Western Digital, Robert Bosch, Phoebe Micro, Humax USA, Comtrend, Dobbs-Stanford, Versa Technology, Zyxel Communications, Astak, and GCI Technologies.  This is similar to GPL violation lawsuits brought against Cisco, Verizon and a number of smaller companies like Super Micro, Extreme Networks, Bell Microproducts, High Gain Antennas, Xterasys, and Monsoon Media among others.

The newest lawsuit is because those companies are illegally using BusyBox.  BusyBox is a super useful program (released under the GPL, of course), which is an embedded-Linux swiss army knife, providing many functions that would otherwise require dozens or hundreds of binaries.  Its a life-saver for an embedded developer, but it, or any other GPL software including Linux itself, can be an iceburg to your company if you aren't fully aware of the restrictions that GPL imposes.

I've boiled this down to some simple principles.  (But as they say, I'm not a lawyer, I just play one on T.V., so please consult your own legal experts!)

FOR ENGINEERS:

• If you are using open source software, make sure your management and your legal department knows about it.  They may be blissfully unaware, but ignorance unfortunately does not stand up in court.  The life of your company and your own livelihood can be on the line if your company is sued, and even out-of-court settlements can bankrupt a company.  Your company's management needs to assess the risk and put into place any mitigation strategy in case your product is discovered to contain open source and your company is not upholding the conditions of the license.
• If you are not using open source software, help your management team by providing adequate information to explain why you chose a proprietary software solution.  They will need to justify the costs required to purchase that software, and avoidance of GPL compliance measures can be one of those factors.  Companies are always in pursuit of the lowest cost, and free sometimes is too difficult a temptation to avoid.  What is often not realized is that open source is not free--there is a cost required in compliance with open source licensing, and that cost is rarely factored into the total cost of ownership.

FOR LEGAL:

•  Understand what GPL means for your company, and be familiar with the restrictions and regulations that it imposes on your product development.  One of the primary things to understand is that GPL enforces you to provide and publish your source code, which can be a detriment to protecting your company's intellectual property.
• Look into purchasing software management products from companies Black Duck Software, which can identify the orgin of source code throughout your source tree.  Black Duck provides an easy way to prove that your software is conformant, and if not, it gives you a quick way to find out what is required to make it conformant.

FOR MANAGEMENT:

• If you are using open source, you should employ a conformance officer, who has enough technical skill to understand the engineering aspects of software development, as well as understanding enough legalese to communicate effectively with your legal department.  This person's responsibility is to make sure that all code that's used in your products has a known orgin, that all of the many software licenses in your product are collected, managed, and tracked, and that your company is doing what is necessary to be compliant to those licenses.  For GPL this basically means contributing all your software changes back to the open source community and providing your software's source code free for download or included with the product.  Other licenses may have more strict or more leniant requirements.
• Encourage your engineering staff to fully disclose the orgin of software they are using that they did not write, and make sure you enable the controls and processes needed to track software origination and licensing terms.
• Understand that there is a hidden cost associated with GPL in addition to the loss of intellectual property.  Publishing or distributing your software, or making available the source for your software, whether that is through email, website, or CDs, and tracking your conformance are all extra burdens on an organization.  Weigh in that cost when deciding on software usage terms based only on price that otherwise look "too good to be true" to understand if they really are as beneficial as they look at first glance.

One final piece of advice to everyone: realize that even if you are a small company, this does not make you any less of a target or an example in a GPL conformance lawsuit.

Now that you've got the basics, you can take a safe swim through the open source sea.  Just don't forget to keep an eye out for the crocs!

Detroit ngConnect Launch: The Motor City delivers for Christmas

Last Tuesday, just a week and change before Christmas, QNX and Alcatel-Lucent hosted the launch of the LTE connected car for the automotive audience.  Whereas Alcatel-Lucent spearheaded the NYC event due to their connections with the carriers, QNX was the prime for this event because of our close connections with the auto industry.  Which explains why we had the event in Detroit.  Despite premature reports of Detroit's death, and having the international infamy of a town being on life-support, the Motor City still is the center of the world when it comes to cars.  There couldn't have been more interest or excitement by those in attendance; we had a full day booked with press, automakers, industry analysts, automotive tier one suppliers, and automotive partners, most getting their first hands-on experience with the LTE connected car.  People who are all working towards designs that will blow away customers in a scant couple years.

Was it as "funky" as New York?  Nope.  Instead of a chic retrofitted carriage house in Hells Kitchen, we held it in the rather conventional, but very well appointed, Rock Financial Showcase in Novi, which they had outfitted for the season with some beautifully ornamented Christmas trees.  This was generally a crowd with a more a roll-your-sleeves up approach, so I don't think the slightly more pedestrian surroundings were even noticed. 

LTE Connected car, right before the show opened...

But what was noticed was the car.  Again, the star of the show, there was hardly a time when all four seats weren't filled with wide-eyed engineers, managers, and execs.  Everybody was getting a glimpse of a stocking stuffer that will be available within a year or two. It was like Christmas came a little early to Detroit!  Now if only Santa can be nice to everyone this year and deliver some car buyers...