About the Arago Project
The Arago project was created by a few engineers from Texas Instruments and Ridge Run after mutually reviewing each other's Linux SDK products and exchanging visions for the future. We found that much of the two existing products was really duplicate work with different but not differentiating value. At the same time we saw that we shared many elements for our future direction.
All participants wanted to create a "product" that would be approachable by an experienced embedded developer that is new to the Linux eco-system. At the same time the Linux savvy developer should be able to see how the system was created and be able to tune, change, or expand upon it.
We wanted all elements of the SDK and the assembly process to be publicly visible. An individual developer should be able to use the system from pre-canned binary images, build up a system from packages, or rebuild all source from 1st principals.
We desired to find a balance between the very latest and sometimes unstable work of each component and the rigorously tested but sometimes stale work of an official product. We believed that knowledge of what works, what "looks OK", and what is untested is key to finding this balance.
Be the least you can be
The Arago project is about being "just enough" to meet the goals and vision of the project. It is not about trying to create a differentiated value statement. If the goals can be achieved via upstream projects so much the better. The value statement of the Arago project may change over time as upstream projects evolve and as we prototype new activities.
Contributors to the Arago project should remember that at the base of "differentiated" is plain old "different".
What is the main difference between the Arago project and building the requested MACHINE in Angstrom?
First of all, the use of toolchain - Arago uses pre-built binary CodeSourcery Lite (2007q3 and now 2009q1), while Angstrom builds own toolchain from the sources - gcc, glibc, etc.
Second, we are integrating Arago with the TI product build, automated test and regression, as well as release cycles. As an outcome, it would allow core packages to be tested more thoroughly than they are currently in Angstrom.
Providing an SDK (allows building apps for the target w/o learning OE/bitbake) is important to us. Angstrom is mostly a build framework and a binary distribution, hence not much emphasis on SDK.
Layered structure (still in development) would allow better control over what versions of individual packages get built (build-of-material) and easier customization for the end user.
Another important area is more user-friendlier interface - while Angstrom and OE in general target more experienced users/developers, the target audience for Arago is wider and include less-experienced users, like DSP codec developers, who's not very familiar with Linux. Simplifying setup and bitbake interaction for them is part of the plans for Arago.
Also, many of the new TI platforms and machines now first get supported in Arago and then added back to OE...