Cross-posted from my blog on the Yocto Project site. Please go there for lots of great embedded Linux information.

Here in Hillsboro, Oregon, we have an open office area, and I really wanted a monitor set up which would display the status of our Yocto Project autobuilder for all to see. Since

I have a little embedded system in my office, our project's Build and Release Engineer, Beth Flanagan, offered to set it up for me. I thought that was a pretty brave offer, given that we're in the final dance of our Yocto Project v1.2 release. So I really appreciate it!

The system is some pre-release hardware which Darren Hart has been working on to get a BSP together. The box itself has a bunch of radios, but to make this exercise relatively easy, we just plug it into an ethernet port. The little box is designed mostly for "headless" applications not requiring a monitor, but it does have a couple of HDMI ports, so we just plugged the display in.

The display is just the Grid View of our autobuilder, so you can build your own display. There are other views as well, but this is a nice one for me to get an idea of what's going on. We did discover a number of interesting issues here like some gaps in our web browser support in our standard build profiles. We're looking into this, and some other issues we discovered.

I also fully realize that showing a static web page refreshing periodically is a pretty boring thing for a powerful processor to do. We should probably run some analytics or video transcoding or something. I just hate the thought of idle hands!

As you can tell from the photo, at the moment I took the snap, our BSP builds were all failing. A moment later they all came up green. Go figure. Darren and Beth say it is really easy for all of the builds to come up green - just a .css change!

If you're a geek like me, you might find yourself watching some science fiction movie or show and wondering "why is it that we have no problem talking to extraterrestrials?" Sure, a wookie on Star Wars may speak some strange tongue, but the humans all seem to understand wookie and Chewbaca can understand human really well. How can this be possible?

One of the goals we have for the Yocto Project is to get everyone in the embedded Linux world to speak the same language when it comes to Board Support Packages. It's because without some standardization here, the effort to get your OS working with a new board can be quite difficult. And if you have done the hard work to get Linux running on a new board, it's hard to share that work with a truly broad community of developers.

Think about it: in a world where everyone's embedded Linux OS can understand all of the BSPs that are out there, developers no longer waste time porting their boards to new OS's or struggling with porting their embedded software to new boards. In this kind of world, Linux can grow freely without impediment in the embedded world.

To get us closer to that world, a number of Yocto Project developers got together last Monday, April 2, and held a BSP Summit. This event was held prior to the 6th Linux Foundation Collaboration Summit, and was hosted by our good friends at Mentor Graphics.

Tom Zanussi shared with us a terrific presentation on our BSPs and the new Yocto Project BSP tools designed to make it easier to get started with your own BSP. Then Denys Dmitriyenko shared about Texas Instruments' work with the meta-ti repository of BSPs.

There was a lot of discussion and conversation through these talks. The good news is that the summit participants agreed to keep the existing format for Yocto Project BSPs. There was a request to add some documentation for the case where someone is taking modifying an exising BSP and making only a few changes to it, which is likely the most common case. We also had some discussion about some broader Yocto Project issues, but the BSP summit successfully agreed on the BSPs.

There were a lot of people to thank for the event:

• Sean Hudson of Mentor did a hurculean job pulling the event together, making sure we had a great space to work in, providing us breakfast, lunch and dinner and connecting up with folks on the phone. Thank you Sean for doing such a terrific job!
• Tom and Denys for their presentations.
• Jeffrey Osier-Mixon for organizing and collecting survey results.
• All of the many participants who came from far and wide to add their voices and expertise - thanks to you all!
• And, thanks finally to Bill Mills who took off time from his family vacation to join us ... and came up with the phrase "Yocto Yumminess".

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!

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!

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

A couple of months ago, the Yocto Project reached a kind of strange milestone. Some of my friends like Bill Mills suggested I should be blogging about it, but for some reason it was hard for me wrap my head around it. Here's my attempt.

It was on May 19, 2010 that someone sent an email (Hi, Sven!) suggesting the name "Yocto" for our new embedded Linux project. We had been really struggling to come up with a good name, something which would not be offensive in other languages and which was not already taken.

A year later, when you google the term "yocto", the first result listed is the Yocto Project website rather than the definition of the scientific term.

Granted, the "yocto-" prefix is not the most commonly used scientific term, and I'm not sure how many of the uses of the scientific yocto prefix link link back to the Wikipedia page. Google ranks its search results based on some proprietary and ever-changing algorithm, but I have heard that it's based on the number of pages that link to yoctoproject.org. So this does represent a bit of a threshold or tipping point of awareness of the project on the internet. Huzzah!

Personally, though, I've never felt really comfortable with the idea of getting big just to be big. There is a danger to it. You set expectations that may not be realistic, and you may find yourself having grown too big and needing to retrench or reset expectations.  In the US, we call this getting "too big for your britches" for some unknown etymological reason.

So I dislike anything which sniffs too much like hype. I would rather offer something of true value to people, and when people learn about it, they will want to take advantage of it. But at the same time, without the awareness which comes with being big, you might never reach the audience who could benefit the most from what you are doing. There is a beneficial reinforcing cycle which kicks in when there is awareness which comes from size.

I took a job 25 years ago at a little technology startup. The company started hiring a bunch of people and I remember telling a manager there that I was a bit nervous about the company getting too big. His response was, "If you don't think we should grow, then you should be getting your resume together about now." Implying of course that in order to survive and make an impact, we really did need to grow and I needed to get on board with this or find someplace else to work.

I'm still resistent to give in to hype. It's tough because I have a lot of enthusiasm for embedded Linux and the Yocto Project. But  I'm not afraid to be bigger.

(For the sake of completeness, as of the time of this writing, bing.com and yahoo.com still had the project below the scientific term. For now!)

Today we dropped another development milestone build for the Yocto Project. Introducing the M2 build.

Our intent for these regular milestone drops is to synch up everything in the project and pause feature develoment, stabilize the software through some QA runs and bug fixing, and make it available to you, the community. This way you can evaluate the progress we have made, help identify and/or fix bugs and accelerate us to completion. It's also a way for us to be totally transparent in the project.

(And in the interest of complete transparency, I need to confess that I'm writing this in a little rental house on the Oregon coast, where at least part of my family is visiting with friends from college and their kids. For the Oregon beach, the weather is amazingly good - no wind, sun blazing away. But the sun, surf and sand does not excuse me from getting a blog post done).

Beth Flanagan gave a very good description of our M2 release on the Yocto Project mailing list. I thought I would highlight a couple of important features which are available now:

A word on this version of the Hob: There are a couple of issues which are present in this version, and which are being fixed. These are eay to work around, and we would appreciate it if you would try out this version with these caveats and give us your feedback.

First, before you try the Hob, we recommend that you do a bitbake build of an image from the command line. Then, Hob should work fine for generating images. So if the build directory is new, I recommend that you do:

$ bitbake core-image-minimal

before you try to use Hob.

Second, there is a problem if you disable packages in Hob. Some of the code paths work, but there are several which do not. Best bet for the M2 version of Hob is not to play with package disabling. This should be fixed in the M3 version, which should be coming out in a few weeks.

Launching the Hob in the M2 version is as simple as typing

$ bitbake -t xmlrpc -u hob

... once you have sun the usual environment setup script and done a minimal image build, as mentioned above.  This will be even simpler in a future milestone release, which will introduce a wrapper script.

Thanks again for checking out the M2 version of the Yocto Project. We really appreciate the contributions and support of the community, and we're interested in your feedback.