Hi Casimiro,
    perhaps this isn't the place for such a political discussion but forgive
me for butting in.  I'm basing my comments in part on the recent article in
CACM One Laptop Per Child: Vision vs.
Reality<http://pcic.merage.uci.edu/papers/2009/OneLaptop.pdf>
 [1].

On Thu, Jul 16, 2009 at 10:57 AM, Casimiro de Almeida Barreto <
casimiro.barreto at gmail.com> wrote:

> Em 16-07-2009 08:40, Bert Freudenberg escreveu:
>
>> On 14.07.2009, at 03:01, osp at aloha.com wrote:
>>
>>  Maybe it is just me, but "a fast bytecode package loader, without the
>>> need
>>> to compile Smalltalk code" combined with "such feature could make life
>>> easier to third party Etoys developer and eventually attract more of them
>>> to Etoys" sounds like an endorsement of closed-source commercial EToys.
>>>
>>
>> No, that's is a severe misunderstanding you construct here.
>>
>>  If
>>> commercial success is not the attraction, what is? Faster initial load
>>> time? Reduced file transfer size? Perhaps I assumed too much.
>>>
>>
>>
>> Yes, both of these. The scenario we care most about is the one million
>> kids using XO laptops. These machines are under-powered compared to recent
>> PCs, and have rather little main memory. It's infeasible to have one image
>> with all the extensions to Etoys, because the whole image is loaded into
>> RAM. It would be very nice if these add-ons could be delivered as separate
>> packages and loaded on demand.
>>
>
> But to have millions of kids using XO laptops it is necessary to supply a
> product that has commercial appeal. Moreover in 3rd world countries where
> the political discourse behind money employed in buying and distributing
> these PCs is based on the fact that children will be enabled to gain
> technical skills that will allow them to leave the "prison of poverty".


There is also more at stake than gaining technical skills, as evidenced by
the Waveplace curriculum. There is also access to literature and art, a
context for communication, community and play, and a context for
self-expression.  Technical skills only provide a route out of povertyif
those skills are in demand, and demand for software engineers is limited.
 There are, and must be other ways to escape the prison of poverty.  If we
look at the failed models of international aid and development in the last
century that are finally being seen as failures in this century a
fundamental principle has to be the enablement of communities to enrich
themselves culturally as well as economically, not something western
corporate efforts have been behind at all.

As described in [1] there is clearly a struggle between those who would like
to see OLPC available at as low-cost as possible, the originators of the
OLPC project, and commercial interests who want to provide alternatives to
OLPC.  The motives of the originators are clear, but one also has to examine
the motives of those commercial interests.

In this line of real life context, other participants like
> IBM/Unisys/Dell/HP/Sun/Microsoft/Borland/etc argue that they have better
> stuff than the "under powered" OLPC (for instance) and that nothing
> interesting will result from teaching smalltalk and it would be better to
> "train children" to use "more significant technologies" (sic) like
> Java/.NET/MVC/MVB/Delphi/etc...


These commercial interests, all either Wintel-centric or Wintel itself, see
OLPC as a threat and have moved swiftly first to co-opt it and then, when
their attempts had stalled, to undermine it.  Why?  It seems to me that they
want to lock in potential consumers and view OLPC as providing a route out
of the Wintel dominance of the desktop market.  If I'm right then why help
the Wintel nexus to extend its reach?  Does it really provide anything of
vaue?  I'd argue strongly that it offers limited value, and at best shoddy
quality (cf Apple).

I find it interesting, but too time-consuming, to determine if this is a
short-sighted approach or a sound business approach, albeit predatory.
 After all if OLPC provides millions of new potential computer users then
surely the Wintel nexus can provide professional products for them to use.
 Perhaps it is afraid that OLPC provides a richer experience than available
on its platforms and that consequently it fears people who have grown up
with OLPC will dismiss its offerings in later life.  I certainly hope so.

Many countries, like Brazil, have laws that make computer donations to
> public schools almost (if not absolutely) impossible. For the interested
> ones, just take a look at Federal Law 8666 (
> http://www.planalto.gov.br/ccivil/Leis/L8666cons.htm). Thus, unless a big
> boss patronizes embedding squeak inside the product they'll be selling to
> government through public bid... children will learn something else.


So is this to be taken as reason to
kowtow<http://en.wikipedia.org/wiki/Kowtow>to Wintel or as a signal to
try and change the law?

I am aware that other 3rd world countries have the same legal problems. And
> even in countries that doesn't have specific laws (moreover the ones with
> big population) the donation of XO laptops may be non viable due to costs
> involved, so a sales scheme is to  be devised.
>
> On the other hand, why would a government invest in something that has no
> commercial appeal? Governments are elected (usually by people) so they care
> for immediate results of their policies. Consider the reality of 3rd world
> countries where day to day survival is a really concrete concern of
> population. Government actions are aimed to discourses like: "now your
> children is entitled to run for better jobs". No commercial relevance, no
> better jobs, no action by governments.


"Commercial appeal" is in part the product of marketing and in part the
product of commercial relevance, and relevance is different if you're an
established business looking to limit innovation and find cheap labour with
an existing well-specified set of vocational skills, or you're a new
business looking to innovate and looking for people with new skills and new
ideas.  This conflict is played out in many arenas.  I well remember the
arguments in my computer science department in the UK in the 80's and 90' as
people debated whether to teach using C++, because "thats what industry
wants" or to continue using a range of languages embodying key concepts such
as Pascal, assembler, ML, Miranda, Prolog and Smalltalk, because once a
student grasps a concept they can apply it in many different contexts.

I think that this is at the crux of this discussion.  Supporting OLPC
against commercial interests is at root supporting the emancipation of
peoples and supporting established commercial involvement is supporting the
status quo.  There is presumably a middle ground where new commercial
interests who are not defending established markets [and not trying to wring
the last drops of milk from a rotting fetid software base, ed] an contribute
in a win-win way.  But I don't see that supporting commercial involvement in
OLPC is de-facto a good thing.



>
>
>> That's what the current Dr Geo II package is doing. But it is slow,
>> because all the code is compiled to byte code when loading the package. The
>> Squeak byte code compiler has not exactly been optimized for speed, because
>> in usual development you only compile a method at a time. In any case, the
>> *result* of loading a package that includes both source code and byte code
>> would be exactly the same as compiling the source code, but way faster.
>>
>> This could also be used to speed up package loading in general. In fact,
>> this would make the concept of "libraries" feasible in Squeak - packages
>> loaded on demand. Think about pre-compiled lisp modules, or the .pyc files
>> generated from .py Python files for speed. Note I'm not advocating this for
>> Squeak but it would make it technically feasible.
>>
>> It's just not exactly trivial to do in a robust way. At the very least,
>> all global references in the compiled methods will have to be updated. This
>> includes classes which have to be referenced, Symbols need to get interned
>> and unified. The source could be appended to the changes file and source
>> pointers incremented, or the source could remain in separate files but we'd
>> need a new source code scheme for that.
>>
>> I think this all would be immensely useful in the long run, but truth is
>> we have been getting by without for so long that there just does not seem to
>> be anybody both motivated and skilled enough to do it.
>>
>> - Bert -
>>
>>
>>
>>
>>  CdAB
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090716/189ed62f/attachment.htm