Using XO 1.0 battery to feed external circuit board
cjlhomeaddress at gmail.com
Mon Oct 10 01:55:44 EDT 2011
On Mon, Oct 10, 2011 at 1:30 AM, Chris Leonard <cjlhomeaddress at gmail.com>wrote:
> On Mon, Oct 10, 2011 at 1:04 AM, Yannis Kaskamanidis <kiolalis at gmail.com>wrote:
>> How can we include Greek language in every new release. Can someone help
>> me by describing the process of integration? We use XO's in my classroom,
>> but without Greek.
> Dear Yannis,
> Per Daniel Drake's e-mail of Feb 4 2011
> There is a list of languages included in OLPC builds by default. (German
> was added to that list by request).
> That e-mail also points out that other langs can be added by request
> (although Daniel would have to make that call).
> How big is the Greek deployment? That might help influence the decision.
> In any event, builds supporting additional languages can always be
> generated via the OS Builder toolkit chain and even signed by OLPC for
> deployment on locked XOs as a "point release" if there is sufficient
> justification to do so.
> I am personally supportive of the inclusion of Greek by default, if only
> because the Greek L10n team has always demonstrated exemplary diligence in
> keeping up with their strings.
> However, it is worth remembering that it is essential to make tradeoffs
> between the set of included languages in "stock" builds (generally those
> with larger deployments) and the image sizes of the builds. It is a
> testament to the success of the L10n effort that OLPC builds can no longer
> afford to include all of the L10n strings that are available.
> I believe that the advances made in developing the OS Builder tool chain
> makes it far less important whether or not a given language is included in a
> "stock" build, as custom "point release" builds are much easier to generate,
> and often will be far preferable for a given deployment as tehy can be made
> to include specific content as well.
I guess the point I really want to make is that inclusion in the "stock"
image has been made far less important because OLPC (via the OS Builder tool
chain) has made a significant technological transition from a
"one-size-fits-all" build philosophy (be in the "stock" build or lose out)
to a "mass customization" approach, where language-specific builds (which
will not include all of those languages you do not need, leaving more free
space) are much simpler to generate.
In some sense the purpose of the "stock" builds is to give large deployments
a technology baseline to test and consider for adoption, but the actually
deployed build is much more likely to be a somewhat customized OS
Builder-generated "point release" that is more specifically targeted to a
given deployment's requirements. The Greek deployment should seek to take
advantage of this relatively newly introduced flexibility rather than being
too concerned about being included in the "stock" build.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel