OLPC upgrades

[Tiago Marques]

On Wed, Feb 4, 2009 at 7:14 PM, Wade Brainerd <wadetb at gmail.com> wrote:

> On Wed, Feb 4, 2009 at 1:38 AM, Albert Cahalan <acahalan at gmail.com> wrote:
>
>> Bobby Powers writes:
>> > 2009/2/2 Tiago Marques <tiagomnm at gmail.com>:
>>
>> >> Python is killing the XO, what's being done in that regard?
>> >> The $100 laptop will always be hardware limited, how can
>> >> python be a benefit and not a *huge* burden? I for one can't
>> >> get my head around that.
>> >
>> > The idea is to give kids as much transparency into the software
>> > stack as possible, AND make it easy to hack on and easy to create
>> > new activities for.  Python is much more forgiving than C.
>>
>> Python is less forgiving if you want performance on the XO. :-)
>>
>> For teaching, remember that Knuth uses assembly. C is an awful
>> lot closer to that than Python, and isn't the XO about teaching?
>
>
> Ha, ahat age group is Knuth teaching assembly to??  What level of math and
> science skills are they expected to have?
>
>
>> > Its killing the XO?  A personal pygtk based project launches in a few
>> > seconds on my debXO install on an XO, but much much longer on 8.2.
>> > It is a completely loaded statement to say that Python is killing
>> > the XO, and didn't really deserve a response :)
>>
>> I'm assuming that "personal [...] project" means small.
>>
>> The fact that you consider "a few seconds" to be acceptable shows
>> just how much people have lost touch with the concept of performance.
>
>
> Python is not the problem. Just strace the activity startup process to see
> everything that goeson.
>
> A lot of it appears to be erelated to
> a) Rainbow
> b) Journal instance creation
>
> Also I agree that the huge animated loating icon is probably not helping on
> XO.  Could'nt it be replaced by a large non-animated icon in the center of
> the screen, and then smoe dots that appear around the icon in a circle,
> adding one dot per second, like a clock?  That would take no overhead and
> would even give an informal way to measure startup time by counting the
> dots.
>
That seems a good idea.
The use of SVGs seems unnecessary. Although an awsome functionality, which
probably saves a lot of work, would allow to scale the use of Sugar to
systems with bigger screens - were it probably will never be in use. I've
never seen SVGs being used extensively in a desktop system, let alone an
"embedded" one.


>
>
>
>> Current usage of Python can be mostly explained as follows:
>>
>> http://en.wikipedia.org/wiki/Sunk_cost_fallacy
>> http://en.wikipedia.org/wiki/Sunk_cost
>> http://en.wikipedia.org/wiki/Irrational_escalation
>> http://en.wikipedia.org/wiki/Cognitive_bias
>> http://en.wikipedia.org/wiki/Point_of_no_return
>> http://en.wikipedia.org/wiki/Psychology_of_previous_investment
>> http://en.wikipedia.org/wiki/Foot_in_the_door
>>
>> The remaining bit of the explanation is that the developer pool
>> is now full of Python people. Nearly all others have run away.
>> One can't expect to attract non-Python talent when Python gets
>> a non-negotiable privileged position.
>
>
> Please don't try to hijack a technical discussion into a political one. Use
> of the Python language is not the cause of the performance problems on the
> XO or in Sugar in general.  Every system must be optimized no matter what
> language it is written in.  It just takes a little effort.
>
> Wade
>
As I talked with some people that know more Python than me, they argued that
programmer productivity would be a major factor for it's use in some
situations. I haven't heard that argument here. I haven't read a good
argument that justifies the burden of using an interpreted language in a
desktop environment, so it really does seem stubbornness more than anything
else, even more and it's all already written in Python.

No matter what interpreted language you're using, it will always stink.
Either it's java, python, javascript, whatever. Sugar isn't a webapp, it
doesn't even need to be so portable that it can't be written in a language
that can be compiled.

Even in powerful machines, most programs I have used written in Java have a
huge amount of computing and memory overhead - and Java isn't the worst of
it, I read.

I can't stress this enough: unless the whole OLPC project is starting to
take aim at building a laptop that doesn't cost less than $170, I don't see
any reason at all not to properly optimize the software. You will always be
running some kind of over powered, embedded type system, with little RAM and
CPU power.

You have to go against a huge corporation with more powerful hardware, more
marketing money AND software that runs a lot faster - and it's not going
well, as far as I know.

Either software manages to hide the lack of horsepower, instead of
exhibiting it more, or there will still be problems to land major deals.

The whole project is taking the show source thing way too far, hurting you
too much, especially as that is still far from "the vision". You already
have Pippy, which should be enough for most kids. The really good kids won't
have a problem doing the work to go to the next step(building activities and
such) and you can always leave the door open for python activities, while
having the basis of Sugar in C, C++ or something. Isn't that what bindings
between languages are for?

Best regards,

                            Tiago Marques
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20090207/e8ca69b5/attachment.html>