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.

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 savy developer should be able to see how the system was created and be able to tune, change, or expand apon it.

+

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 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.

Line 9:

Line 9:

== Be the least you can be ==

== Be the least you can be ==

-

The Arago project is about meeting 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 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 without 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 are 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...

Revision as of 18:01, 19 October 2011

History

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 without 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 are 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...