However, there still exist some corners of the tubes where actual technical conversation still happens. These are a few of those corners that cater to those of us with a taste for embedded Linux. Please feel free to add to this list in the comments below.

Social media:

These include communities dedicated to embedded Linux, wikis, etc. Blogs are listed in a separate section.

• Meld has been called the “Facebook of embedded Linux”, and not just by me. Conversations tend to get very technical. Stop in and join the discussion groups. [full disclosure: MontaVista sponsors Meld, and I am a Meld admin]
• Elinux.org is an excellent wiki maintained by CELF. The wiki contains a huge amount of embedded Linux information and is growing all the time.
• Embedded group on Linux.com, recently absorbed by the Linux Foundation.

Blogs:

Do blogs count as social media? Almost certainly. Here are just a few that discuss embedded Linux:

• Jeff’s Open Source Resource [full disclosure - that’s me]
• Kate Alhola’s Maemo blog
• Embedded Linux Interfacing, serving the Embedded Linux community since 2001

Embedded Linux appearances in other social media:

Our presence is small, but loud.

• Twitter supports many fascinating twigs and branches, some of which, like Meld and MontaVista, relate to embedded Linux.
• Google Groups hosts many groups related to specific projects, e.g. the Beagle Board discussion group.
• LinkedIn Embedded Linux group.
• Facebook Embedded Linux group. Be sure to also visit MontaVista’s page.
• MontaVista on YouTube. There are more embedded Linux videos there as well, just search on “embedded linux”.

The short answer is that I am an ambassador for Linux developers, currently acting within this corporate structure. Obviously I have a vested interest in helping MontaVista succeed. What that means to me, though, is that a major component of that interest is to help embedded Linux developers succeed in general, partly because they may someday become MontaVista customers, but mostly because they help to advance the cause and penetration of the current best embedded operating system.

As a community admin, technical writer, and developer, I have several avenues by which I advocate.

One is that I help to administer an open community called Meld. Meld is sponsored by MontaVista, but it is truly open, meaning that anyone can join and discuss any embedded Linux topic, including the merger of Wind River with Intel, the recent webinar about fault-tolerant memory management, or even the thrill of rolling your own kernel, none of which directly involve MontaVista. In company meetings about Meld and at conferences, I try to represent the needs of developers at large and help to keep Meld open and non-corporate, although I’m swimming with the flow in that case—MontaVista as a corporation and the entire Meld team are as dedicated as I am to that level of openness.

Another way I advocate for developers is as a technical writer, by helping to document important tools, like MontaVista Linux 6. It is fascinating to be a part of building such a complex tool and useful tool and to try to find the best ways to explain it.

A third method is to find ways we as a company can give back to the communities that support us. This is more than just the kernel community, of course: CELF and elinux.org, the Linux Foundation, OpenEmbedded and BitBake, and Moblin are all organizations and projects that share a common goal in helping embedded Linux succeed.

Actually, to boil it down, I figure it is my job to help embedded Linux developers succeed. I think that sums it up nicely.

If you are an embedded Linux developer, don’t be shy about letting me know how I can help YOU succeed, by email or in the comments below.

First, a little history. Intel has long been a player in the embedded space—I wrote documentation for GNU cross-development tools for the i960 as far back as 1992—but only as a side interest to their ever-booming x86 desktop and server business. Transmeta is widely acknowledged as having been the entity that forced Intel to address the low-power, low-heat market. The resulting competition ushered in entire new genres of devices that blurred the line between embedded systems and non-embedded, general-purpose computers. Intel’s investment in Moblin and the related introduction of Atom processors cements Intel’s commitment to following the thin-and-light market wherever it goes, leading wherever possible, and competing like a featherweight boxer with his girlfriend at ringside.

What this merger means for Intel is that their commitment to embedded (or at least thin-and-light) systems is tightly coupled with their commitment to Linux, the reasons for which are likely obvious to anyone reading this. Much will be made in the press and in the blogosphere in the coming weeks about Intel thumbing its nose at Microsoft by embracing Linux in this way. This may be true. WinCE succeeded in taking over market share from VxWorks and other embedded operating systems in the late 90s, which arguably propelled Wind River to redesign itself as an embedded Linux company. However, embedded Linux continues to sap market share from both WinCE and VxWorks and is slated to continue to do so on an accelerated scale, so the merger makes perfect sense for Intel. Those guys started out smart.

How does the merger benefit Wind River? That is a good question.

Wind River’s core business has always been real-time, with VxWorks and its ecosystem of tools. x86 is only a portion of that business, and though one might expect that it will become much more prominent now, it would be difficult for Intel to simply abandon a solid moneymaker, even one that centered around its competitors’ hardware. Realistically, the Atom is not the right tool for the job in many places where VxWorks shines, namely very hard real-time embedded—automotive, aerospace, and space systems in particular—noting especially that these are historically very conservative markets. I predict that, as Intel has suggested, they will continue to let Wind River operate in that environment as it always has, and will just take a paycheck, at least until those markets realize the possibilities that exist with Linux. (Automotive is already making strides in that direction.)

As for Linux, though, Wind River is known in the press for being an active purveyor of embedded Linux operating systems and tools, if not necessarily an innovator. This acquisition immediately distances Wind River Linux from non-Intel markets, namely ARM, Freescale, and Cavium. As Joerg Bertholdt (MontaVista’s VP Marketing) notes in a recent interview, current Wind River Linux customers who use non-Intel processors are already wondering what the future will hold.

However, Wind River started out smart as well. As their VxWorks business declines into hardcore niche markets and their Linux business—-well, “matures” rather than explodes as they might have hoped, they are intelligently seeking a solid rock to which they can anchor their core business values. I predict that VxWorks will continue to be available for a variety of architectures, though it may not continue to mature as it has. It seems easy to predict that Wind River Linux will mature in the direction of Intel hardware, though other hardware platforms may suffer, and that they will move much closer to Moblin and netbooks as a focus.

This is where things get interesting for MontaVista, who has always maintained a level playing field with regard to architectures. MontaVista Linux already supports dozens of architectures, Intel included, and will continue to do so under the new MontaVista Linux 6 Market-Specific Distribution paradigm. The MVL6 Integration Platform provides developers with an intense new method for creating, building, and maintaining their development environments, and DevRocket 6… (oops, shh). And Meld provides everyone a community to discuss it all.

In the end, the merger is fascinating and will be big news for both Wind River and Intel, and I will be very interested to see it play out, but I’m glad to be here on the sidelines. MontaVista is well-poised to continue to enable embedded Linux developers to succeed, no matter what their choice of hardware, and as a Developer Advocate that’s what I care about.

BitBake has often been compared to make, but if that were the end of the story, there would have been no reason for BitBake in the first place. make was groundbreaking in 1977 when Dr. Stuart Feldman[1] of Bell Labs invented it as part of the UNIX base system (and for which he was awarded the ACM Software System Award in 2003). Even then, though, Dr. Feldman was building on the work of others who had come before, as build scripts called “make” and “install” had been around for as long as people had been using scripts to automate program compilation, especially in the Bell Labs UNIX build system. BitBake, however, changes the metaphorical paradigm for build systems from a build list to a recipe. On the surface this seems superfluous, but at its core, this is a fundamental change that acknowledges modern software development as being truly a creation based on the work of many disparate, complex ingredients. Just like a meal is made up of individual recipes and each recipe is made up of vegetables, spices, sauces, cooking techniques, and sometimes even the products of other recipes, BitBake treats the software development cycle as a meal.

The BitBake metaphor is powerful in large part because of the prevalence of open-source projects and their inclusion into other projects. The BitBake paradigm has strong implications compared to ad-hoc embedded Linux build systems based on assembling collections of makefiles. Each individual open-source project is built in accordance with the wishes and comforts of its maintainers, as it should be, and BitBake accommodates all systems as an overarching build tool. Its most powerful feature is resolving package interdependencies. That speaks for itself.

OpenEmbedded takes this a step farther by providing metadata—sets of proven recipes—for building embedded Linux distributions. As Brad says, OE can be considered a family of related Linux distributions that share a common infrastructure, while developers differentiate their individual distributions by adding (and subtracting) packages and new code.

The magic of MontaVista Linux 6 is that it is completely compatible with the BitBake paradigm and OpenEmbedded metadata. You can mix and match as you wish, and MontaVista’s DevRocket IDE will help you do it. MontaVista provides a tested content repository properly integrated with those upstream as well as a set of eager engineers ready to provide technical support. It’s a win-win scenario. If I sound like an evangelist, it’s because I have personally struggled in dependency hell and watched customers do it, and I love tools that bring order out of chaos.

MVL6 is now in beta along with the Integration Platform, with general availability scheduled for July.

[1] Dr. Feldman, originally an astrophysicist, is a luminary in computer science, having authored both make and Fortran-77. He is now director of the IBM Institute for Advanced Commerce in Hawthorne, New York.

As previously mentioned the integration platform capability of MVL6 is a big new feature. My last post mentioned many of the benefits including more easily reproducible builds and clear traceability of all build inputs to the outputs. A simplified diagram of the system looks like this:

The entire process is controlled by recipes and there is full transparency and traceability between source and metadata inputs and the build products that are produced. What kind of build products are there? Quite a few, in fact.

• Prebuilt filesystems that can be deployed to targets
• Packages in a variety of formats that can be used for deployed device upgrades
• Various manifest files describing what was placed in the built images
• Original source archives and patches suitable for distribution to satisfy various licensing obligations

As an example, after doing a quick test build of the busybox and less software packages you can see the source code ready for distribution:

$ ls tmp/deploy/sources/*/tmp/deploy/sources/BSD/:

less-418.tar.gz  less-418.tar.gz.md5tmp/deploy/sources/GPL/:

busybox-1.13.2-depmod.patch      busybox-1.13.2-modprobe.patch

busybox-1.13.2-depmod.patch.md5  busybox-1.13.2-modprobe.patch.md5

busybox-1.13.2-init.patch        busybox-1.13.2.tar.gz

busybox-1.13.2-init.patch.md5    busybox-1.13.2.tar.gz.md5

busybox-1.13.2-mdev.patch        busybox-1.13.2-tar.patch

busybox-1.13.2-mdev.patch.md5    busybox-1.13.2-tar.patch.md5

Is that source tarball actually the real original unmodified source from the upstream project? Let’s check and see by verifying the cryptographic signatures:

$ cp tmp/deploy/sources/BSD/less-418.tar.gz ./
$ wget ftp://ftp.gnu.org/gnu/less/less-418.tar.gz.sig
$ gpg -v less-418.tar.gz.sig
gpg: assuming signed data in `less-418.tar.gz'
gpg: Signature made Tue 08 Jan 2008 05:18:56 PM EST using DSA key ID 33235259
gpg: requesting key 33235259 from hkp server subkeys.pgp.net
gpg: armor header: Version: SKS 1.0.9
gpg: pub  1024D/33235259 2004-12-04  Mark Nudelman <markn@greenwoodsoftware.com>
gpg: using classic trust model
gpg: key 33235259: public key "Mark Nudelman <markn@greenwoodsoftware.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: Good signature from "Mark Nudelman <markn@greenwoodsoftware.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: AE27 252B D684 6E7D 6EAE  1DD6 F153 A7C8 3323 5259
gpg: binary signature, digest algorithm SHA1

That looks good. How about busybox?

$ cp tmp/deploy/sources/GPL/busybox-1.13.2.tar.bz2 ./
$ wget http://www.busybox.net/downloads/busybox-1.13.2.tar.bz2.sign
$ gpg -v busybox-1.13.2.tar.bz2.sign
gpg: armor header: Hash: SHA1
gpg: armor header: Version: GnuPG v1.4.6 (GNU/Linux)
gpg: original file name=''
gpg: Signature made Tue 30 Dec 2008 10:37:37 PM EST using DSA key ID ACC9965B
gpg: requesting key ACC9965B from hkp server subkeys.pgp.net
gpg: armor header: Version: SKS 1.0.9
gpg: pub  1024D/ACC9965B 2006-12-12  Denis Vlasenko <vda.linux@googlemail.com>
gpg: using classic trust model
gpg: key ACC9965B: public key "Denis Vlasenko <vda.linux@googlemail.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: Good signature from "Denis Vlasenko <vda.linux@googlemail.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: C9E9 416F 76E6 10DB D09D  040F 47B7 0C55 ACC9 965B
gpg: textmode signature, digest algorithm SHA1

That checks out, too.

Now your developers and management can be assured that when it comes time satisfy any license obligations you have an easy and repeatable process for ensuring that the sources corresponding to distributed binaries is at hand.

OpenEmbedded (OE) is a widely used, and I would consider a defacto standard, for community engineered embedded Linux distributions. OE is has been around for 7+ years and has an active contributor base of both commercial, independent contractor, and enthusiast developers. OE is what I call a family of related Linux distributions that share some common infrastructure. Each development team then customizes their distribution to meet their requirements. Some examples.

BitBake is one of these common infrastructure tools. BitBake is analogous to “make”. BitBake analyzes a set of directives and then builds a task dependency tree to satisfy a user command. BitBake then executes the defined tasks to completion. When paired with the OE metadata BitBake can compile from source to create the host development tools, cross-development tools, target binaries, and system flash/disk images needed.

On a technical basis MVL6 is, because of our use of BitBake and compatibility with the BitBake recipe syntax and the OE metadata, a peer to other OpenEmbedded-style distributions as listed above. Just like these peer distributions MVL6 has unique requirements driven by our customers.

For the MVL6 development tools we’ve invested to create several compelling benefits for developers over every option on the market both commercial and non-commercial:

• Dirt simple and fast installation. MVL6 is the fastest and easiest embedded Linux distribution to install and get productive in. I’ve used a bunch of them… commercial and non-commercial. Trust me on this. We’ve got a small required core to install and everything past that can be done incrementally on demand.
• It just works. When I interviewed developers about their experiences using several prominent community embedded Linux distributions there was a clear and consistent message: They were hard to use and took a lot of help and tweaking to get going. It is infuriating to kick off a build only to see it fail 7 hours into an 8 hour process because you were missing some important host tool or a website with the source code went down. MVL6 gets you started fast with sensible defaults, prebuilt binaries, and a quick path to get your hardware booted.
• One file defines your design. Using the extensions we’ve added you can use a single configuration file to define your entire design. We’ve got helpful docs to explain how to customize your project while not making an un-maintainable mess.
• MVL6 can start small and build up incrementally. Sometimes developers have to squeeze their designs to fit into flash. MVL6 starts with a small image and lets developers add incrementally. They can even break the bounds of restrictive binary-only distributions and downsize within software packages by removing features or files.
• MVL6 doesn’t cut you off from the world. While we provide a complete Market Specific Distribution (MSD) for your design you can, if you wish, supplement our product with components from OpenEmbedded. We’ve retained compatibility to give you great options.
• MVL6 doesn’t lock you in. Most commercial embedded Linux build systems are either under an ambiguous proprietary license or are so esoteric to be classified as vendorscript. MVL6 won’t lock you in like that due to its open core and usage of a defacto standard recipe syntax.
• A logical update system. MontaVista periodically releases updated software components to fix bugs and offer enhancements. Getting these updates into your MVL6 project is simple and risk free. Lock your project down so version updates don’t happen without permission. Pull down the updates using a simple automated tool. Try them out by commenting the version lockdown line. If you don’t like it just uncomment the version lockdown and no harm done.
• Works great behind a network proxy or even offline. Often developers have to work on restricted lab networks. Rather than depending on a slew of public HTTP, CVS, git, and Subversion servers across the Internet there is a single source for every original source archive and patch that goes into your MVL6 powered product. You can access the MontaVista Zone (MVZ) Content Server from behind a proxy or quickly mirror it for your own offline operations.
• We don’t even lock you into MVZ. Let’s say its 2018 and after the Great Quake of California that flooded the Bay Area you want to update your MVL6 powered design with some additional software. You forgot to download the sources for the libfoo package and now MontaVista is at the bottom of Lake Santa Clara. Luckily the MVL6 Integration Platform is smart enough to go to the original upstream repository. You go on as a happy developer.
• Better build portability. Often our customers need to be able to reproduce their builds for 10+ years into the future. The problem is that as their development PC’s get replaced they have to upgrade to new host Linux distributions. We’ve made sure MVL6 depends only on the well defined Linux Standard Base (LSB) components of the host operating system. This assures developers that, to the extent that is feasible without a crystal ball, their builds will be reproducible on future Linux distributions that have not yet been created.
• Better build reproducibility. What builds today has to build in 10 years. We’ve got MVL6 dialed-in so you can easily configuration manage the system without having to check 100,000 files into your revision control system. That’s goodness.

So that’s a long little love letter for the product. There are lots more cool tricks to show. Mark you calendars for an upcoming webinar by my esteemed colleague Nick Pollitt on all manners of MVL6-foo.

MontaVista has created something groundbreaking in embedded Linux development (and I’m not just saying that because they pay me). This tool can honestly help take the pain out of creating embedded devices. Check it out for yourself.

Community managers, including those of us administering Meld, recognize the importance of education and free-flowing information, hence the very active discussion groups on Meld. Sometimes, though, you need more than just a friendly forum where you can ask questions. Sometimes you need to know what questions to ask—you need the benefit of the experience of other people. You need education. Your community is here to help.

For the past several months I have been collecting links to embedded Linux training materials that are freely available out there in the world, and it has proven to be one of the most popular pages I maintain. This post contains material that is most relevant to MontaVista’s offerings, and I will periodically post new information as it becomes available.

Take advantage of these offerings. It’s like going to college for free, or at least going to a conference for free (without the travel, free t-shirts, and shmoozing). And don’t forget to look for other free training materials, including documentation, white papers, and even events. This is one way communities can feed back into the public knowledge base, which benefits everyone involved.

If you find a link to educational material that isn’t mentioned here, please send me a note and I will gratefully update this list.

Webinars

Webinars, seminars held over the Internet, are a great way to attend a very directed class on a specific subject without leaving your desk. I love these things because they are rarely longer than an hour, and they are usually cached so you can go back and watch them anytime if you miss the original presentation, or if you want to catch something you missed. Some cost money, but all of those listed on this page are freely available.

• MontaVista’s Klaas van Gend gave an excellent presentation addressing the top 5 pains in Linux system build and design. The webinar is archived on MontaVista’s site, along with many other interesting presentations.
• TimeSys has produced a 4-part series on basic embedded Linux skills (thanks to LinuxDevices for the news).
• Some webinars are a little more commercial, though still informative, like Wind River’s Mike Deliman exploring RTOS design for space robotics from July 2008. I have a personal interest in this one, as I worked at Wind River in 1996 and 1997, when VxWorks became the first RTOS on a different planet—a heady time for humanity, and for embedded systems as well. RIP, Sojourner.

Conference Sessions

Conferences are fantastic places to learn about embedded Linux, often because the speakers are talking about the most timely information available. If you can’t make it to the show, though, often the important sessions are recorded.

• First, be sure to check the conference websites themselves, like MontaVista’s Vision 2008 or CELF’s Embedded Linux Conference. These sites usually catalog at least the slides from most or all sessions, if not video recordings of the actual presentations.
• The fantastic folks at Free Electrons are your best friends when it comes to free education in embedded Linux. They go to important embedded Linux conferences, record most or all of the sessions, and then post the videos on their website free of charge. Someone should issue you a Masters degree if you watch a percentage of what is there. I have met them at a few conferences and they are extremely good at what they do. See the next few items for more.
• Free Electrons has also posted videos from the 2008 CELF European Embedded Linux Conference.
• LinuxDevices reports that not only was the annual Free and Open Source Software Developers’ European Meeting (FOSDEM) a huge success, key presentations were recorded by Free Electrons and are now available for download.
• I found some older but very good papers on Real-Time and Embedded Linux hosted by our friends at LinuxDevices. These are from the Seventh Real-Time Linux Workshop held in Lille, France, November 3-4, 2005.

Corporate Sites

• Check out MontaVista’s extensive download library.
• LinuxDevices has posted a tutorial series from two engineers at Simtec. Looks like good stuff.
• Timesys’ Learning Center contains demos, podcasts, webinars, and some how-to papers as well as a set of reference libraries.

The answers in Stormy’s poll turned out overwhemlingly to be “people”—over 50% of respondents answered that the one single thing that drew them to conferences was meeting other attendees. This is perhaps unsurprising, particularly since the statistical sample was completely made up of open-source folks, who tend to be more outgoing and people-oriented than the average developer. Another answer high on the list was “meeting the speakers”, which I believe is indicative of the very level playing field in which we participate.

But I think the real answer is deeper than that. Other answers high on the list had to do with attending talks, hacking with friends, and learning more about interesting topics (this is based on the published survey responses). I tend to put these things in a blender and look at the whole picture together—people attend conferences to learn about interesting things with their friends, to make new friends at the same time.

So far as I can tell, this is the end goal of Community, with a capital C. Conferences are the physical manifestation of the activities we perform in all of the communities to which we belong. When we talk about being part of a community, whether it is the Linux community or the open-source community or the embedded or real-time, or BitBake or Git or Beagle Board communities, the whole point is that we are part of those communities—we participate, we learn interesting things, and we do it by hanging out with existing friends and making new ones. We contribute to the whole, which would not be complete without us. As Jono Bacon said in his presentation at Collab Summit, we are building a sense of belonging, because belonging to and being part of a larger group resonates deeply with our mental firmware. We are fulfilling our internal destinies as social animals.

I attended and presented at the 2009 Embedded Linux Conference and the 2009 Linux Collaboration Summit. The conferences were co-located at the Kabuki Hotel in San Francisco, CA. Both conferences were extremely useful individually, but the combination of the two was absolutely electric.

At ELC, I attended some fantastic sessions, beginning with Dirk Hohndel’s keynote on ubiquitous Linux—very appropriate for an embedded conference, as much of the ubiquity he described is manifested from the embedded systems space. Cell phones and the networks that drive them, all of the multiple layers of networking equipment around us, the search engines and bookstores and LOLcats we hit every day, all are driven by Linux, largely by embedded Linux. His theoretical challenge was to go for a certain amount of time in the modern world without touching Linux, which very shortly led to not being able to even cross the street in many large cities.

The rest of the conference was full of fascinating information. I attended a presentation on Maemo, a keynote by embedded maintainer David Woodhouse, a great talk by embedded luminary Jim Ready, a fascinating discussion by David Mandala from Ubuntu on how they got such a large distro to work well in an ARM environment, and an extremely interesting panel hosted by Tim Bird and featuring Matt Mackall, Jon Corbet, and David Woodhouse. Tuesday evening provided a showcase of demos, including my demo of Meld running in Firefox, on Montabello, on a Beagle Board.

Wednesday was a rough one, because it was the day the two conferences overlapped. It was quite odd to wake up to find the population in the hotel’s conference area quadrupled, quite literally, and the rooms were physically changed around to accommodate all of the new conferencegoers. I didn’t get a chance to see many of the remaining ELC technical talks because I was riveted by the Collaboration Summit keynotes, most of which addressed community either directly or indirectly. I also managed to meet several community leaders, including Karsten Wade, Joe Brockmeier, and Jono Bacon. As a newcomer to community management, I found all of them welcoming, open, and filled with advice about community-building. The advice itself was worth the price of the trip—they gave me a lot to think about, particularly Karsten, whose role with the Fedora community is probably most similar to mine in the embedded space.

I gave my ELC presentation Wednesday as well, and was pleased to see some participation despite being opposite a very compelling panel featuring representatives from Sun, Microsoft, and the Linux Foundation. Note that Free Electrons recorded all of the sessions at ELC, including mine, so I expect to see those online in the coming weeks. Well done again, guys, and great to meet you in person!

The Linux Collaboration Summit is normally an invitation-only affair. This year, however, they invited all ELC members to stay for the remaining two days and participate. Thursday and Friday were simply a blur of packed sessions, including one that Joerg Bertholdt, VP Mktg at MontaVista, and I gave during the Community Best Practices track on Friday morning. The attendees were mostly community managers and active members, and we had a lively discussion about community and its role in product development and commericalization as well as some details about Meld itself. Our slides are available for anyone who would like them.

I came home exhausted on Friday afternoon, very grateful for such events and eager for more (after a rest!).

Cloud computing isn’t just a server consideration. When you consider how ready the world is for pervasive clients — and how ready Linux is to accommodate — you’ll want to put your cloud plans on the front burner.

The article is at the top of the page here: http://www.ibm.com/developerworks/linux/
along with a lot of other excellent articles on Linux, though not necessarily embedded.

In case it has been bumped, here is a link directly to the article:
http://www.ibm.com/developerworks/linux/library/l-thin-client-cloud/index.html

http://stackoverflow.com/questions/184618?sort=votes

So, Hello world! I’m Jeff. I have been a blogger for a little while, though most of the writing I have done over the past 18 years has been technical documentation in a variety of spaces. I have written for and contributed to the GNU project, documented products ranging from enterprise server software to cluster operating systems to microprocessor hardware, and performed a variety of other work directly or indirectly related to open-source software and embedded operating environments. I spent three years working on mobile Linux software before joining MontaVista last fall.

All of this makes me very happy to be here at MontaVista writing to you now. I have long been impressed with the work MontaVista has done in legitimizing and contributing to Linux as a viable embedded and real-time operating system, and I am pleased to be a part of the engineering team as a technical writer. I am even happier to be an ambassador for Meld, our new embedded Linux community, where I am an administrator.

That said, I feel that my primary role, both as a writer and as a community administrator, is as an advocate for developers, hence the name of this blog. I believe that openness and transparency are key to the intense success of open-source development, even in competitive arenas. MontaVista has proved itself to be so open to the needs of developers, and I will continue to work from the inside to keep it that way.

I am pleased to have the opportunity to share my thoughts with you in this space. Feel free to contact me at any time. I also attend and speak at open-source conferences whenever possible, so please say hi if you see me there.

Meld is really about embedded Linux. Take a look at the Wordle below:

That was built off of the “recent discussions” page. Does that put it all into perspective?

Just join today to meld. Thanks for Montavista for hosting this forum. — from izjenie

Thanks for all the great responses guys. There was a lot of information gleamed in this thread. — from ngogineni

Meld is also covering a broad array of topics which I think is critical for those of us who are working with embedded systems. We can’t just specialize in one code base. Meld has hosted discussions on:

• drive to userspace communication
• Beagle board accessories
• booting linux in a multi-processor environment

You’ve also got another chance to learn about how community can help make your embedded Linux project easier at an upcoming webinar on Thursday March 26th. The two hosts for this webinar are Jonathan Corbet (founder of LWN.net… go subscribe now) and Troy Kitch of MV. Should be interesting to see how they discuss “Addressing the top 3 challenges of embedded Linux development with community“. Meld isn’t, of course, the only community out there and there is likely no better guide as to how to work with open source communities than Jonathan. You should read his other publications on this subject such as his “Guide to the Kernel Development Process“.

So, why do this?

I’ve been involved with embedded Linux for almost 10 years now. Everything I’ve ever learned I learned from the generous assistance of others. Some knew they were helping me… but most didn’t. The generosity that powers open source and Free software is apparent.  Despite all of this, however, the particular branch of developers building commercial products using embedded Linux is in many ways under-connected.

I’m not an open source project developer… but I can help others who, like me, need an assist here and there to get a job done. Meld is one way to do that. Would you consider joining in to help, too?

Just a few quick FAQish comments:

• Meld isn’t intended to be a replacement or a rival to open source project communities like LKML, kernel.org, or the hundreds of other related projects out there. Our engineers send their patches to the various upstream repos and mailing lists. You should continue to do so as well. If you need help knowing where to go or how to engage we’d love to help you find your way to the right repo… just ask on Meld.
• While MontaVista may be mentioned from time to time on Meld it shouldn’t leave you with the impression Meld is just for MontaVista Linux. That is not our intent. Because neither embedded Linux in general or MontaVista Linux in particular is a mutant fork of the broader world of Linux and open source what we discuss should be generally applicable to many types of Linux which you use to get your jobs done.

If you’ve got questions the comment lines are open.

Brad

“The initial condition is that we don’t want to burn cycles on engineering and development to build from a stock kernel up,” (Michael) Enescu (CTO of Open Source Initiatives at Cisco) said. “We start with a distribution and we have a very good relationship with Red Hat and MontaVista.”

What a nice thing to read on a Friday afternoon. Another quote from Michael inspired some commentary:

“We have both Red Hat and MontaVista as supplier to us. Occasionally there are pieces of a distro that we need to treat differently.”

What I find compelling about this statement is that it shows how what we call “roll-your-own” Linux is really a spectrum of behaviors. Most companies who embrace Linux and open source don’t do everything themselves or buy everything off the shelf. They are hybrids. Some custom, some stock.

It is how a vendor helps you to walk that gray area between stock and custom that can be the real differentiator. More on that later.

[kml_flashembed movie="http://www.youtube.com/v/2sVTRfsFQDE" width="425" height="350" wmode="transparent" /]

Maybe we’ll spring for a monopod for the flip camera

Addressing the Top 5 Pains of Linux System Build and Design: Our friend and colleague Klaas van Gend is running this webinar tomorrow. Run like a Forrest Gump and go register right now. Why? Because Klaas knows his stuff cold. He is one of those people who I learn from each and every time he speaks. What makes listening to Klaas fun is that he’s opinionated and has a lot of knowledge all up and down the software stack. He’ll be rambling on real-time one moment and the next he’s discussing cryptographic trust networks.

Got a Twitter account? If you do and you are in to it you are welcome to follow MontaVista’s tweets. We tweet on the obviously named mvista Twitter account.

Today’s hardware irritations: not being able to find my SATA power cable that I ordered and lost in this slovenly office of mine. Two hard drive crashes within 3 months of each other. HDMI CEC commands that cause my A/V receiver to flip to the wrong input.

Today’s software loves: Puppet! When my laptop drive went kaput I was in the middle of upgrading to Ubuntu 8.10. I decided that I would take no system administration actions without recording what was being done as part of my Puppet manifest. When my laptop hard drive died I reinstalled Ubuntu, installed puppet and git, cloned my git repo that had my Puppet manifest in it, and then ran Puppet. After about 15 minutes all of the system tweaks I think are essential were up and running. Very cool!

Claim: 48% developers not considering Linux for their next embedded project

This is based on an unreferenced CMP survey cited in a whitepaper by RTOS vendor Express Logic. I sure wish they had a URL to the study because the chart they cite gives me pause. The little footnote that states that they question that supports this claim was changed in 2007 to be more specific about time frame was intriguing. Perhaps they asked a more specific question and got more specific answers? One might feel more freedom to answer liberally about what you hope to do in the future if there is no time frame to it.

Claim: New or modified lines of code on Windows CE 47,000 (ave) compared with 193,000 industry average

The Krasner report which supports this claim is far more interesting. Lets dig in!

A bit about EMF and Jerry Krasner: Jerry’s had years of experience watching this embedded systems market in particular. He’s said both positive and negative statements about embedded Linux. Back in 2003 he was unfairly vilified by many for his report “Total Cost of Development: A comprehensive cost estimation framework for evaluating embedded development platforms” that dinged embedded Linux for a high TCO and propped up Windows CE .NET and Windows XP Embedded. Linux Devices has a good historical summary.

In a December 2007 study “Embedded Linux Total Cost of Development Analyzed” he revisited this topic… this time with his own data collection and apparently free of any vendor funding or direction.

Some quotes from the December 2007 study that I find compelling:

In summary, Linux not only continues to gain market share across the embedded spectrum, but the definitive EMF data set forth herein demonstrates that developers using Linux have the same design outcomes compared with traditional RTOSes.

Uh… sorry Mike. Looks like you’ve reversed the polarity on what the LOC metric means. You’ve got to look at both the lines of code written and the design outcome data in the Krasner study. Just because a project is big in terms of lines of code doesn’t mean the underlying platform is a failure. Krasner mentions that “out analysis showed that the in-house developers wrote fewer lines of code and fared poorly when it came to final design outcomes as compared with their pre-design expectations.” He is using lines of code as a metric of developer contribution to product design requirements, not as a measure of project burden.

Consider what we get when we mash-up both the RTOS and Linux Krasner studies that were published in 2007:

So it looks like if you want to get quicker time to market you’ve got a fairly obvious choice. I also like how this data supports something I’ve felt empirically for 10 years now: Working with a commercial Linux vendor will result in a better project outcome:

Final design results within 30% of pre-design expectation for features and schedule:
Commercial Linux = 70.2%
Other Linux = 59.0%

I’m not bashing Windows CE/XP Embedded, Microsoft, or Mike. I just think that if you are going to go cite a market research study that you’ve got to take into account the overall dataset. The data indicates, to me, that:

1. in-house RTOS or Linux projects are painful
2. not all RTOS or Linux commercial vendors will support the same project outcome