I sat down this morning to jot down a few words about the latest Yocto Project development milestone, which has the very homely name of "M2". We pause at this time to branch our code, run a full pass of our QA suite and make sure we are on track with major features. (This is all good by the way).

The developers working on the Yocto Project are a very interesting bunch - we have people who have worked in open source projects for their entire careers and others who come from the world of product development. It's fascinating to see these worlds intermix as we try to do the right thing to make Linux the  best choice for embedded development.

Now before you think I'm totally confused on this point, let me assure you, I am not. The Yocto Project is not a product. It is an open source project, which will form the upstream for products, ranging from devices to board support packages to operating systems from the like of Mentor Graphics and Wind River Systems. To be a stable basis for these products, we take seriously the need to track the health of our bits as we develop them.

You can track project health with all kinds of metrics and dashboards and charts. Often it comes down to the experience and intuition of the project leaders to figure things out.

In 2001, the Oakland Athletics baseball team was eliminated from the playoffs by the New York Yankees, a team with three times the money available for players. How could the Athletics (or A's as they are called) ever hope to beat a team with so much money to spend? The tale is told in Moneyball, nominated for the 2011 Best Picture Oscar.

Now, I will confess, I am not such a fan of baseball, and I have a hard time caring about such things. What drew me in was the way players are traditionally chosen in baseball. Professional scouts, who are quite experienced in baseball, will evaluate a player based on everything from their statistics to how pretty their girlfriend is.

How in the world could you evaluate a player on whether they had an attractive girlfriend? This was part of the intuition the scouts would use to indicate a player's confidence.

The A's general manager tries a different tactic. Could you apply economic theory and create a formula that would boil down all of the metrics for a player and create a single number to evaluate them? And can the movie's makers take such a dry topic and make it interesting, as Aaron Sorkin did with The Social Network, 2010's Best Picture.

Well, you can judge that last bit for yourself. I thought it was very good (and beautifully photographed as well).

How about the Yocto Project? Can we as leaders boil all those statistics down to a single number to tell us the health of the project? I'd like to think we do.

Meet the Weighted Defect Density:

This is just a snapshot I grabbed from the end of https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend - you can see all kinds of other statistics in there as well. But this is the one I look at first when I want to know how we're doing. TO compute it, we eliminate the bugs which are not defects (there are enhancements and features tracked in Bugzilla as well) and then weight the open bugs by their severity and track this number over time.

This single trend chart gives us a lot of insight into the project. It helps us to ask more questions about what is going on, to drill into other data and to potentially change course. Do we think we're going to hit our goals for the release? Do we need to stop development work and focus people on bug fixing for a while? Maybe we need to stop testing so much and work on fixing bugs. Or maybe the line is lower than we expect it to be and we should be doing more testing.

Using a Weighted Defect Density in a project is not a new idea[1]. I first heard about it and used it way back in the early 1990s. But it has proven to be a good indicator of Yocto Project health and helped us make informed decisions.

In Moneyball, the hero played by Brad Pitt says his ultimate goal is to change the way the game of baseball is played. He sounds like he could be on the Yocto Project. We're trying to change the way the world develops devices. Time will tell if we're right.

[1] Robert Baetke, an associate at Sequent Computer Systems learned about the Weighted Defect Density metric at a talk given about how Boeing developed the 787 aircraft. He brought the tool to Sequent and employed in there, and I am very grateful for his contribution to my way of thinking about development.

As the calendar year winds down, I find myself tapping away at the keyboard at my sister's house in Denver, Colorado in a snowstorm. I just spent the morning digging out our rental car and shoveling my sister's driveway and her next-door neighbors. It is a time like this to reflect and, yes, to remember that one of the reasons I moved to Portland, Oregon was to escape the snow!

This has been a busy month in the Yocto Project, with all kinds of activity jumping along:

• We launched a maintenance release 1.0, dubbing it Yocto Project v1.0.2. Our 1.0 release was last April, but we try to provide update support for at least a year after release. This release includes security patches as promised and some fixes to make sure the build works with more recent Linux distributions.
• We're also working on a maintenance release for 1.1, which came out last October. Nobody should ever fear that compatability has been broken in a maintenance release. My mental rule of thumb after a few decades in the software game is that you should have no more than 10 - 12 bug fixes in a maintenance release, which also constrains the amount of QA you need to do. 1.1.1 though will have a few more changes in place because we want to address some issues raised by Matthew at FreeScale and to make sure that the release meets their needs. More on this later.
• Our development, QA and release engineers also produced the first milestone from our 1.2 release, due this coming April. We produce these milestone releases every 6 weeks or so. Our idea is to constrain the length of time that the development window is open to make sure we can freeze, stabilize and run a full QA sweep. Then we provide these little milestone releases to you so that you can have some demonstratable features to use in a somewhat more stable form. At least, it should be more stable than developing on the Master branch! As I wrote this, we decided to go ahead and release the M1 milestone.

It may seem like we're putting an inordinate effort into producing these maintenance releases. In fact, we had hoped to have 1.1.1 out in December, but putting three releases out in one month was just too much for our release engine to handle.

Why make the effort to do maintenance releases? Here's the way I think about it:

• The Yocto Project is an open source project, not a software product. So we're not supporting our releases for years and years. We're looking for our friends at Mentor Graphics, Montavista, Timesys, Wind River and others to produce software products which use Yocto as the upstream.
• On the other hand, by providing these additional stable releases, it shows that we care about the developers who base their products on the Yocto Project. We know not every product development cycle perfectly aligns with the every six month Yocto Project cycle. Having these maintenance releases helps to support them.
• As I mentioned, we try to keep these releases as stable as possible, just fixing critical bugs or security patches from upstream.
• So we think these maintenance releases matter, to demonstrate that we care about you the developer who uses the Yocto Project to make the magic happen on your devices.

By the way, I'd like to offer a shout out to Joshua Lock, who has been spearheading the development side of these maintenance releases, Beth Flanagan for release engineering work, Jiajun and the project-wide QA team. And also to Paul Eggleton for reminding us to get the 1.0.2 maintenance release on the schedule.

The Linux Foundation did a nice little two-minute video clip of Jefro, our Yocto Project Community Manager, talking about last October's 1.1 release, and the upcoming 1.2 release planning. Check it out!

Jefro discusses the Yocto Project 1.1 release

Jefro claims that he looks kind of sleepy, but clearly the camera loves him!

Intel(R) Cluster Studio XE

 

Gergana Slavova, Technical Consulting Engineer, will be presenting on Dec 7th at 9am PDT on the following topic:

Analysis of hybrid applications with the Intel(R) Cluster Studio XE 2012

Please register for this presentation using the following link:

https://www1.gotomeeting.com/register/369788936

Here is a short abstract of the presentation:

With the launch of Intel® Cluster Studio XE 2012, Intel enhanced the premium software development tools package for clusters with the inclusion of MPI support in Intel® Parallel Studio XE, and added new features for better scalability and improved performance. This session will introduce you to all MPI components of the new Intel® Cluster Studio XE 2012. You’ll learn how to use the new and more scalable startup mechanism to run MPI applications well up to 90000 cores, you’ll take a dive into benchmark data, and the improvements and details of the mpitune tool, and you’ll see, in an interactive demo, key elements and new scalability features of Intel® Trace Analyzer and Collector.  Finally, you’ll be shown how to enable the new MPI support in the Intel® VTune™ Amplifier XE and Intel® Inspector XE tools.

Here is a short bio of the presenter: 

Gergana Slavova received her bachelor’s degree in computer science at the University of Illinois at Urbana-Champaign in 2005. Following graduation, she joined the Intel Software and Services Group as a Technical Consulting Engineer, a position she has held for the past five years.  She works in the high performance computing area where she provides technical support, training, and consulting expertise for a suite of MPI and cluster development tools.

Please register for the presentation now and attend it on Dec 7th at 9am PDT. You can ask Gergana questions during the second half of the presentation.

I've noticed a disturbing trend amongst a few of the high quality wineries in my state. They have abandoned the cork to close their high-end wine bottles and turned to screw caps.

This is good news to people who struggle with how to get a cork out of a wine bottle. And wine snobs will point to the countless studies which show that metal tops eliminates the possibility that the cork has gone bad and spoiled the wine.

I think this totally misses the point. These people are making a product that costs $40 US per bottle and up. Why in the world would anyone spend this much on a bottle of booze? They must be getting more out of it than just high-priced liquid. They are in essence buying into an experience which includes the ritual of pulling a cork. (And, I guess, the ritual of liver disease, dilerium and all the rest, but I degress).

This is in part why people fall in love with the iPhone. Every cell phone makes calls, many will allow you to take photos or load applications. But people fall in love with the magical experience that the iPhone offers. (I am quite immune to this love, by the way).

What does this particular rant have to do with embedded Linux?

The Yocto Project is still very focused on providing the best build system, metadata and application development toolkit that we for developing your own custom embedded Linux. In addition, we're trying to radically improve the experience that developers have, particularly first-time developers trying their hand at Yocto.

Why should we care? I have talked to a few people who don't have a terrific out-of-the-box experience with Yocto. These are not dummies - they are brilliant. I can only conclude that we can do better in this area.

I hope that this will make a big difference as the developer base continues to expand on the Yocto Project and helps make it easier for Linux to grow in embedded. I hope we can have a good experience as well as good wine.

Much has been written about how the Internet has revolutionized collaboration and made it possible for your brilliant ideas to make a difference no matter where you live on the planet. Bill Gates is famously quoted in Nick Kristoff's "The World is Flat" that "... so many people can plug and play from anywhere, natural talent has started to trump geography." This is of course true, but even with the Internet, there is no replacement for face-to-face interaction. The tribe, it seems, still needs to gather around the fire to have a talk now and then.

The conference setup was in a very new and modern hotel called the Hotel Clarion Congress in Prague, which was a terrific venue. Since the Yocto Project was a co-sponsor of the event, we got a nice booth location, and Tracey Erway did a fantastic job setting up the booth and populating it with demos, videos, giveaways and t-shirts. You can also see Darren Hart manning the booth behind the Gource video that he rendered showing the many contributors on the project from many places.

I was impressed by how much the booth became a gathering spot for people wanting to talk about Yocto and what we were doing in the project.

There was a lot of opportunity for people to interact with Richard Purdie, who is the Yocto Project architect, and a very approachable guy. Koen Kooi is a TI guy and a long-time Open Embedded and Angstrom maintainer, who really helped us out a lot in the booth, and showed off his Beagle Board as a demo.

I also appreciated the work of Jeff Osier-Mixon, better known as jefro, who is the Yocto Project Community Manager, and always helps us make sure we are taking care of the community and helping it to be nurtured and grow.

It was fun catching up with Marcin, who works for Linaro, but is a long time heavy contributor to Poky and OpenEmbedded. Here is a photo of him with Richard and Dirk Hohndel from Intel.

And like any good Linux Foundation event, there were some excellent parties to give us a space to hang out with each other and appreciate the unique culture and food of Prague.

But in spite of being in such a beautiful city, these folks are sometimes hard to break away from hacking. On a Saturday with nothing planned but some tourist activities, I actually had to "encourage" Saul to take a break from his computer. (I actually closed the lid of his laptop to make sure he actually stopped working. I hope he forgives me.)

More kudos to Sean Hudson (Mentor Graphics), Paul Eggleton (Intel), Bill Mills (TI), Nithya Ruff (Wind River), Philip Ballister (OpenSDR), Jessica Zhang (Intel) and too many others to count who helped us so much in the talks, booth and discussions about Yocto.

Oh yeah, I guess there were some more or less official things going on as well:

• There were talks and classes on a number of new developments in the new release of the Yocto Project. I was very surprised that my overview talk drew so many people.
• The Yocto Project Advisory Board had a combination face-to-face / conference call meeting, where we talked about the the new Shoeleather lab, the new neutral board lab contributed by Mentor Graphics and about the project's budget (woo hoo).
• The OpenEmbedded e.V had its annual General Assembly meeting. I learned more about German law in that three hour meeting than I ever knew existed, because the OpenEmbedded Project's non-profit entity is chartered in Germany. We did have some useful talking points about which conferences to cover.

The problem with mentioning anyone in a blog post like this is that I'm sure I have missed somebody who will be hurt because I didn't mention them. I am so sorry about that, and I hope you can forgivde me!

http://www.zdnet.com/blog/hardware/forget-the-gaming-pc-buy-a-console/15969#comments

While the author brings up a few interesting discussion points; I’m not entirely convinced that it’s a fair assessment and here’s why.

1) Pricing: When the Xbox 360, and PS3 first released their real street price was no way nearly as low as they are today. Were you really out the door, after tax, etc; for $399? Once you accessorize, get the larger hard drives, etc, you’re arguably left with a device, which for what it’s capable of, is priced comparably to a PC; maybe even a tad higher. For example: If my Console (PS3 in my case), was scaled in terms of cost for a comparably priced PC with 4GB of System Memory (vs. 512mb), how much more would it have cost? The Blu-Ray player more than offsets this IMHO; but I digress and I think you get the point. PC’s simply having a ton more packed inside of them. Also; the OS cost seems to me to put PC OEMs at huge disadvantage against the Consoles which effectively are giving their OS away for free.

2) Easy to Use: Let’s look at the OS again. When a game is easy to access, install, launch, etc.; this is a credit to the OS, and the Developer tuning the game for that environment. I see no logical reason why we couldn’t have that same ‘ease-of-use’ story for PC Gaming (Mac or Windows). IF something is broken on the OS side who’s responsible for addressing it? (Who is responsible for tending and stewarding their own ecosystem? This also applies to drivers, updates, etc.). IF something is broken on the game side, only the Developer is capable of providing that fix.

3) Grab a bootleg version? Really? Did you really say that? First – can’t do that with a free to play game. Second – I don’t know about you; but instead of a grabbing a bootleg – the Console industry saved a ton of people the trouble of pirating, by simply just being able to loan games back and forth. I have over $300 worth of Console games on loan to me right now. No ‘boot-legging’ required!

The best part about this blog, speaking for me anyway, wasn’t so much the blog, but the survey. After making my vote here are the results.

As you can see, for all of the supposed detractors for PC Gaming, it still comes out #1. Even when the Console’s are all added up in one lumped bucket. Had the survey listed everything out separately it probably would have shown the percentages to be more like: PC 57%, Wii 17%, 360 10%, PS3 10%, etc; or thereabouts.
What would happen if the PC enhanced and optimized its ease of use story for PC Gaming? I would say that this is already starting to slowly happen. One of the cool things taking place is that the platform story has now shifted. It’s no longer about the device: PC, Wii, PS3, 360, iPhone, Android, iPad, Slate, etc; but what it’s really about is the Cloud and accompanying services. The new platform is the Cloud.

Oh, and for the record, I love my Gaming Laptop! It beats the value proposition of any Console hands down. Was very affordable (Barely $700) does 100x, and allows me mobility and freedom to play my games anywhere, and when I want. (Living room, Den, Bedroom, Airports, Hotels, you name it!)

Shannon Cepeda, Technical Consulting Engineer, will be presenting on Nov 9th at 9am PDT on the following topic:

Using Intel(R) VTune(TM) Amplifier XE to tune software on Intel(R) Microarchitecture Codename Sandy Bridge, Part 2: Common Issues & Tuning Suggestions

Please register for this presentation using the following link:

https://www1.gotomeeting.com/register/133712545

Here is a short abstract of the presentation:

This webinar is the second part of our 2-part series on Using Intel(R) VTune(TM) Amplifier XE to Tune Software on Intel(R) Microarchitecture Codename Sandy Bridge.  We recommend you watch part 1 first unless you are already familiar with the VTune Amplifier XE Sandy Bridge interface and the pipeline slots methodology.  This webinar will discuss common performance issues, how to measure their impact on Sandy Bridge, and specific suggestions for resolving each.

Here is a short bio of the presenter: 

Shannon Cepeda is an Intel® Black Belt Software Developer who specializes in micro-architectural performance tuning.  She has a BS and an MS in Computer Science from North Carolina State University. She has worked for Intel for approximately 10 years, all in roles dealing with performance analysis. She has worked on servers as well as client systems, and hardware/system performance tuning as well as software.

Please register for the presentation now and attend it on Nov 9th at 9am PDT. You can ask Shannon questions during the second half of the presentation.

During this webinar discussion we’ll be outlining a couple of key proposals that should not only help PC Gaming, but most other gaming ecosystems as well. A couple of the key trends we’re seeing in the research from the PC Gaming Alliance, and in discussions with Game Developers, is an increased desire to support and adopt various ‘Cloud gaming’ scenarios that are accessible across a wide spectrum of devices and displays. (aka. Compute Continuum, 3 screens, etc). This ‘Cloud Gaming’ movement is critical to comprehend in tandem with another key trend as games increasingly move towards a games-as-a-service (aka GAS) model. Due to the global popularity, massive install base, and extensibility of Personal Computers as gaming devices, the PCGA’s set of proposals will be largely targeted at addressing the PC Ecosystem.

I’m very excited and looking forward to this webinar, as it ties into my previous roots working for Microsoft Game Studios in the early 2000’s determining Minimum System Requirements for the PC Games we were shipping during that era. It also culminates a near eleven year journey’s worth of conversations with Game Developers, and collected research for more than a decade.

If you’d like to join us for this Webinar, or know of someone that would like to join, details for the Webinar can be found here:

http://www.pcgamingalliance.org/NEWSEVENTS/Events/tabid/384/Default.aspx

Press Release: ">Here

If you have any questions please don’t hesitate to contact me.
Matt

Back in my college days, I sang in the University Chorus, one of those big choirs who sang a variety of pieces, mostly classical and rarely a more contemporary song. One time we had a young music director who was rehearsing us on a newer piece with just a piano player. When we had most of the vocal parts worked out, he announced that at the next rehearsal, the piano would be joined by guitars and percussion. "Then," he said to us with a twinkle in his eye, "the piece will really begin to cook."

And it was amazing! The addition of those impact players really added a lot to the experience of the music, more than just adding individual singers. The whole song cooked and sizzled and sprang to life.

This is the kind of experience I have seen with the Yocto Project over the past six months. In addition to the growing chorus of individual developers, we are seeing key impact players like TI, FreeScale, Intel, Mentor Graphics, Wind River and MontaVista join the ensemble and make critical contributions.

And it seems to show by the number of downloads we are seeing - our build and release engineer Beth Flanagan tells me that in the first two days after the bits came online, we already had like one fifth of the downloads we had through the entire lifetime of the 1.0 release.

The complete release notes for "edison" are a good read, since you see everything from the complete list of 21 features, the 76 unique contributors and the number of yocto-seconds it took to do the official build. Here are a few key highlights that I picked out, see the release notes for the complete list.

• Hob - Using the Yocto Project to build Linux images, you usually need to learn which configuration file is located where so you can change it with a text editor. We wanted an easier and quicker way for someone to build an image by bringing all of these options together in a single place. The Hob is our answer to this. We have plans to enhance it further, making it a place to solve other usability issues as we discover them.
• System builder support in Eclipse - similar to our work on the Hob, we have added automation for the system developer in Eclipse in addition to the application developer support. What this means is that with 1.1 you can use Eclipse as the center of your embedded development world. Now you can load up the recipes for a Linux system into an Eclipse project, edit the recipes right in Eclipse, then kick off the Hob to do the build. You can still use Eclipse to create an application, deploy it to the embedded device, poke at it with analysis tools (like the newly added systemtap) and debug it remotely. We have a little video which shows these features working.
• OE Core branding - With the Open Embedded Core as the common upstream project between the Yocto Project and the Open Embedded Project, we have renamed some things derived from that core. For example, to build small footprint images in Yocto 1.0, you would build "poky-image-minimal" which raised questions about why "poky" was used in this context. This is now the less confusing "core-image-minimal".
• Layer Tooling - A very powerful part of the Yocto Project architecture is "layers." This feature allows customizations to be added to the system at every step in the value chain from sand to finished device. Some of the clear feedback we received from folks was that we needed an enhanced set of tools to work with layers. These perform a variety of functions, like complaining when a .bbappend file refers to a .bb file which doesn't exist to combining layers together into a single one.
• Multi-lib and x32 - Common processors in embedded systems are coming with some not-so-common features these days. 64 bit support and multi-core used to be features you would find only in big iron servers. But these features come with a price. For example, to take advantage of 64 bit data types, you would normally be forced to compile the entire system to run in 64 bits. But if there are only a few parts of the software which need this large data support, then you have wasted a considerable amount of the system's resources by compiling everything to use 64 bit support. And frankly, some common applications have not been ported to work with 64 bits and might never be. Multi-lib support is an excellent solution, allowing the developer to select 32 or 64 bits as appropriate. X32 is another option, which allows an x86-64 system to run with 64 bit registers but 32 bit data types. x32 is still being developed in the Linux ecosystem, but we have the first steps of this support in the Yocto 1.1 release.
• Developer Guide and Videos - We're constantly trying to make embedded Linux development more accessible to more users, whether they are experience Linux geeks or not. To enable a broader community of developers, we have a new Developer's Manual and instructional videos for using Hob and the Eclipse tools.

And as usual, we have updated the kernel (v3.0.4) and toolchain (gcc 4.6.1) to the most recent stable community releases, as well as upgrading numerous other Linux user-land versions.

We hope you enjoy this release, that it enables you to create the next insanely great device. Thanks to everyone who contributed and to the community at large who make this song really cook.

If you are at the Embedded Linux Conference - Europe, I hope I get a chance to see you. We will have a number of Yocto Project talks and demos and contributors on hand in Prague.

• Hands-on Lab: Create a Custom Embedded Linux* OS for Any Embedded Device using the Yocto Project - Wednesday (9/14) at 1:05PM, repeated at 3:20PM, Room 2012 - This is a fantastic opportunity to get your hands on the Yocto Project software to see how easy it is to set up and build your own custom Linux OS for an embedded device.  Here is the abstract:

Audience: Embedded Device OS System Architecture Developers, Embedded Application Developers, or Technical Hobbyists: Moderate/Advanced technical experience with device OS or firmware development

Create your own custom embedded Linux* using an industry supported, open source infrastructure designed for embedded use – the Yocto Project* (www.yoctoproject.org). Test your Linux* on an Intel® Atom™ processor based development platform and other emulated platforms. Learn an alternative to wasting your time and money hacking apart and testing components from a huge, non-embedded Linux distribution when you build an OS for your prototype or product.

• Poster Chat: Finally, a Great Set of Tools to Create a Custom Embedded Linux using the Yocto Project -12:00PM and 2:30PM Tuesday, Poster Chat Station 5 - this is an unstructured way to connect with both business and technical folks to engage, ask questions and find out how to get involved.

Are you responsible for, or interested in easily building a custom embedded Linux* OS for a prototype or product? Are you tired of using some huge, non-embedded Linux* distribution that you have to hack apart and then re-test and validate for your device? Learn about the Yocto Project*, an open source collaboration project that provides templates, tools and methods to help you create custom Linux-based systems for embedded products regardless of the hardware architecture. Be introduced to the process of developing your own custom embedded Linux distribution for an embedded product or prototype using an Intel® Atom™ processor based development platform and other emulated platforms, how single instruction porting from architecture to architecture is possible, automatic application SDK creation, and the ease of upgrading to a commercially supported open source Linux* such as Wind River Linux*. Come learn how appropriate these tools may be for your project and how to quickly get started saving time and money. If you like what you hear and want to try it out, attend the Hands-on Lab: Create a Custom Embedded Linux* OS for Any Embedded Device using the Yocto Project*.

I highly recommend that you check these out. I will try to be there as much as possible... I would love to meet you.

We finished up all of our expected feature development on the Yocto Project version 1.1, due out in October. After some stabilization and bug fixing, we're encouraging everyone to try out our bits. Would you check it out? You just need a Linux system (a recent release of Fedora or Ubuntu works best) and the necessary workarounds for git and http to work with any network proxy you might have. (Instructions for this are below).

Check out the Hob, our visual build user experience and let us know what you think.Use our normal communication channels (yocto@yoctoproject.org or #yocto on freenode) if you need help. We would be really happy if you would use Bugzilla to file any bugs you find: http://bugzilla.yoctoproject.org

Thanks!

I was just in Los Angeles this week for a few days of holiday with my family. With apologies to the Angelinos who might read this post, we got an excellent exposure to the local culture: Traffic snarls, over-the-top personalities in restaurants, loud vocal complaints about "tourists" and agressive negotiations.

"Agressive negotiations" are constantly on display in the competition for parking spaces. On-street parking meters in Beverly Hills (ah, those heavenly hills in zip code 90210) are now able to take credit cards. Seriously, the traditional coin meter is about the last annoying need for small pocket change that I never seem to have on me. So I for one welcome our new credit card masters.

Other cities like Prague and Portland have taken a slightly different approach - instead of individual meters for each space, a city block is covered by a larger machine that produces a paper receipt which is then posted inside the parked car's window. Here is a shot I took of the Prague version in 2008:

The Prague and Portland version have a "green" edge in that they are solar powered, but since they depend on a printed paper tag to be produced, they seem more prone to breakdown and lost their green cred as well.

And the LA meter seems better suited to a town where nobody (and I mean nobody) walks anywhere. No need to walk as much as a half block to a common parking machine; just pop out of your car and plug your platinum card into the slot.

But as I have written before on this blog, the door is now wide open for municipalities to provide interesting services with more advanced embedded computing.

For example, I noticed that there are a lot of very expensive cars in Beverly Hills. Why not offer (for an additional fee of course) to watch your car to make sure it isn't vandalized or sideswiped? With just a motion sensor, keypad for an unlock code and a wireless phone connection, this service could be offered for permanent residents of the city, thus giving you another reason to snub the tourists.

Fortunately, I had coins available from my wife to use in the meter, so I didn't need to trust my credit card credentials to such an easily hacked device.

I better stop here before I can no longer travel through LAX.

Working at as a software person at Intel can be pretty awesome.

A few weeks ago, we had a video crew stalking our offices, rolling tape on some of our work day. I heard last night from Sarah Sharp that the result was up on YouTube. It was intended as a recruitment tool, but it's a nice artifact of everyday life here. Some highlights from the video:

• My boss, Imad Sousou, talking about how his group acts like a small software company within Intel
• Men and women from all nationalities talking about the intellectual challenges and opportunity for balance
• Quite accurate depiction of our workplace (in Jones Farm, Hillsboro, Oregon) although to be honest, every day is not so sunny as in the video. The Nerf gun battles do actually break out periodically.
• A brief shot of Joshua Lock, one of the guys on my team, perhaps because he has a few visible tattoos
• Nice interview with Sarah, one of our Linux kernel hackers and some of the other technical females from our group
• And even a brief cameo appearance by me!

Of course, there is a huge variety of working situations and projects. But this makes me proud and happy to be working here.

Explore Intel Software

Here's the link ... check it out:

http://youtu.be/wY7Kl85qnqU

One difference between x86 and ARM is the memory alignment requirements for data. Let’s look at a simple example:

This example just logs the size and offset of variables in TestStruct. The output for this program isn’t too surprising:

ARM
I/libtestjni( 5025): TestStruct (size: 12)
I/libtestjni( 5025): -- Var1 offset: 0
I/libtestjni( 5025): -- Var2 offset: 4
I/libtestjni( 5025): -- Var3 offset: 8

x86
I/libtestjni( 4175): TestStruct (size: 12)
I/libtestjni( 4175): -- Var1 offset: 0
I/libtestjni( 4175): -- Var2 offset: 4
I/libtestjni( 4175): -- Var3 offset: 8

But now, let’s change TestStruct to the following:

The output is now:

ARM
I/libtestjni( 4675): TestStruct (size: 24)
I/libtestjni( 4675): -- Var1 offset: 0
I/libtestjni( 4675): -- Var2 offset: 8
I/libtestjni( 4675): -- Var3 offset: 16

x86
I/libtestjni( 4079): TestStruct (size: 16)
I/libtestjni( 4079): -- Var1 offset: 0
I/libtestjni( 4079): -- Var2 offset: 4
I/libtestjni( 4079): -- Var3 offset: 12

The 8-byte (64-bit) mVar2 results in different layout for TestStruct. This is because ARM requires 8-byte alignment for 64-bit variables like mVar2. In most cases, this won’t cause problems because building for x86 vs ARM requires a full rebuild.

However, if an application serializes class or structures, this could cause a size mismatch. For example, say you create a save file on an ARM application and it writes TestStruct to a file. If you later load this file on an x86 platform, the class size in the application will be different than the saved file. As you can imagine, similar memory alignment issues can happen for network traffic that expects a specific memory layout.

The GCC compiler option “-malign-double” will generate the same memory alignment on x86 and ARM. However, since the OS was not built with this flag, it will break some OS calls.

You can control the alignment of variables through compiler attributes. So, if we tell GCC to align(8) for mVar2, x86 and ARM will have the same alignment:

The output is now:

ARM
I/libtestjni( 4675): TestStruct (size: 24)
I/libtestjni( 4675): -- Var1 offset: 0
I/libtestjni( 4675): -- Var2 offset: 8
I/libtestjni( 4675): -- Var3 offset: 16

x86
I/libtestjni( 4678): TestStruct (size: 24)
I/libtestjni( 4678): -- Var1 offset: 0
I/libtestjni( 4678): -- Var2 offset: 8
I/libtestjni( 4678): -- Var3 offset: 16

Once you understand the memory alignment difference between x86 and ARM, rebuilding your ARM Android NDK application for x86 should be pretty simple! Go grab the latest NDK and give it a try.