Re: OLPC upgrades

2009-02-10 Thread Wade Brainerd
2009/2/7 Tiago Marques tiago...@gmail.com

 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.


Caching the SVGs as pixmaps can help this out a lot.  I remember IRIX from
the mid 90s using vector-based icons, and it didn't seem to have performance
issues.


 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.


It is wonderful to be able to modify a part of the Sugar shell or an
Activity directly on the XO, without the need for a compiler and a wide
variety of installed headers and libraries eating up space on your disk, not
to mention obscure build systems and megabytes of build artifacts.

It's also great that most activities are 100k downloads and are totally
cross platform and architecture independent.

 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.

Here's the difference:  In Sugar, Python fills the role of the *glue* code.
 It doesn't do any real work itself.

 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.

Do you need high performance for every program?  I use GMail all day and
have never had a performance issue with it.

 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.

I completely agree, I just want to make sure the optimization happens to the
right parts - the parts that do the heavy lifting.  And the algorithms that
control the parts that do the heavy lifting.

For example, I was recently involved in a discussion about the pulsing icon
that is shown when activities launch.  It turns out, the *entire screen* was
being redrawn at 10fps, not just the activity icon.  Not to mention that the
icon caching was not working, so the .svg file was being reparsed each frame
and going through a text filter like s/stroke_color;/#aabbcc/ to achieve
the pulsed color.  Fortunately Benjamin Berg corrected this today.

Another one, I have had to rewrite large chunks of THREE of my activities to
overcome performance issues in Cairo (which is an optimized library written
in C).  I have written several games and other realtime activities for the
XO and not yet seen Python become a bottleneck.

 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?

I'm telling you, I'm still looking for some solid performance numbers.
 Memory issues I am more inclined to believe but again, actually optimizing
the problem (controlling Python's garbage collector) is a much better
solution than throwing everything away and starting over!

I have spent the last 10 years optimizing software for a living, and can
tell you without a doubt that any system can be optimized without starting
from scratch.

It's just much harder to understand the performance characteristics of a
large, complex, existing system than it is to imagine an ideal performance
world in your head.

Best regards,
Wade

 Best regards,

 Tiago Marques

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-10 Thread Martin Langhoff
2009/2/11 Wade Brainerd wad...@gmail.com:
 I have spent the last 10 years optimizing software for a living, and can
 tell you without a doubt that any system can be optimized without starting
 from scratch.
 It's just much harder to understand the performance characteristics of a
 large, complex, existing system than it is to imagine an ideal performance
 world in your head.

+1 on both. Experience teaches that performance comes from
understading and optimising a complex system. If you build a
replacement system, it's initial performance _will suck_ until you
study it, understand it and optimise it.

We can skip the build a replacement step, and head for the goal faster.

(I've only seen one exception to the rule above -- and was the
building of git. But it's a rare case where you get a band of
battle-hardened kernel devs building a small and focused cli tool.)

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-10 Thread david
On Wed, 11 Feb 2009, Martin Langhoff wrote:

 2009/2/11 Wade Brainerd wad...@gmail.com:
 I have spent the last 10 years optimizing software for a living, and can
 tell you without a doubt that any system can be optimized without starting
 from scratch.
 It's just much harder to understand the performance characteristics of a
 large, complex, existing system than it is to imagine an ideal performance
 world in your head.

 +1 on both. Experience teaches that performance comes from
 understading and optimising a complex system. If you build a
 replacement system, it's initial performance _will suck_ until you
 study it, understand it and optimise it.

 We can skip the build a replacement step, and head for the goal faster.

the entire sugar infrastructure is a 'build a replacement' step. people 
are questioning if it was the right thing to do as opposed to using 
existing tools and infrstructure. (with the other part of the question 
being is it faster to go ahead and try to optimise Sugar or switch to more 
mature solutions)

David Lang

 (I've only seen one exception to the rule above -- and was the
 building of git. But it's a rare case where you get a band of
 battle-hardened kernel devs building a small and focused cli tool.)

 cheers,



 m

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-10 Thread Wade Brainerd
On Tue, Feb 10, 2009 at 5:44 PM, da...@lang.hm wrote:

 On Wed, 11 Feb 2009, Martin Langhoff wrote:

 We can skip the build a replacement step, and head for the goal faster.


 the entire sugar infrastructure is a 'build a replacement' step. people are
 questioning if it was the right thing to do as opposed to using existing
 tools and infrstructure. (with the other part of the question being is it
 faster to go ahead and try to optimise Sugar or switch to more mature
 solutions)


I don't think you can correlate 'mature' with 'fast'.  Gnome is quite mature
but also quite bloated.

The XO is a weak machine by today's performance standards, so trying to run
today's Linux is going to require heavy optimization no matter what you
start with.

People just have to stop arguing about it and start doing that optimization
work, like Benjamin did today :)

Cheers,

Wade
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-10 Thread david
On Tue, 10 Feb 2009, Wade Brainerd wrote:

 On Tue, Feb 10, 2009 at 5:44 PM, da...@lang.hm wrote:

 On Wed, 11 Feb 2009, Martin Langhoff wrote:

 We can skip the build a replacement step, and head for the goal faster.


 the entire sugar infrastructure is a 'build a replacement' step. people are
 questioning if it was the right thing to do as opposed to using existing
 tools and infrstructure. (with the other part of the question being is it
 faster to go ahead and try to optimise Sugar or switch to more mature
 solutions)


 I don't think you can correlate 'mature' with 'fast'.  Gnome is quite mature
 but also quite bloated.

 The XO is a weak machine by today's performance standards, so trying to run
 today's Linux is going to require heavy optimization no matter what you
 start with.

 People just have to stop arguing about it and start doing that optimization
 work, like Benjamin did today :)

or just run other distros (like many of us are doing)

however, even those of us who run other distros (and see the differences) 
would like to see the Sugar 'distro' improve.

David Lang
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-10 Thread Peter Robinson

 or just run other distros (like many of us are doing)

 however, even those of us who run other distros (and see the differences)
 would like to see the Sugar 'distro' improve.

The sugar distro is basically Fedora, with a few modifications for
things like the security that OLPC uses. Sugar is actually the GUI
that sits on top of the distro.

Peter
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-10 Thread david
On Tue, 10 Feb 2009, Peter Robinson wrote:

 or just run other distros (like many of us are doing)

 however, even those of us who run other distros (and see the differences)
 would like to see the Sugar 'distro' improve.

 The sugar distro is basically Fedora, with a few modifications for
 things like the security that OLPC uses. Sugar is actually the GUI
 that sits on top of the distro.

yes, but those modifications are significant. I know that Sugar is the 
name of the GUI, but there are still things that don't work in any other 
environment (not as many as there used to be, and they are being 
addressed), and I don't know of a better name to use for the whole set.

David Lang
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-10 Thread Peter Robinson
 The sugar distro is basically Fedora, with a few modifications for
 things like the security that OLPC uses. Sugar is actually the GUI
 that sits on top of the distro.

 yes, but those modifications are significant. I know that Sugar is the name
 of the GUI, but there are still things that don't work in any other
 environment (not as many as there used to be, and they are being addressed),
 and I don't know of a better name to use for the whole set.

The major changes AFAIA are rainbow for security. Most of the rest of
the changes to fedora are to reduce dependencies now and a few other
minor bits that are actively being upstreamed. So what sort of things
don't work in any other environment?

Peter
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-10 Thread Martin Langhoff
On Wed, Feb 11, 2009 at 1:41 PM,  da...@lang.hm wrote:
 as I said, it's a ever shrinking list, but last I heard the security
 changes cascaded to other issues, and there were journal related issues.

It shrinks because people pick one, and help us working on it :-)

Action  speculation. Hop on board! :-D



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: optimized Geode code (was Re: OLPC upgrades)

2009-02-08 Thread Peter Robinson
Hi All,

 Tiago Marques wrote:

 That software is still not compiled for the Geode LX, which further

 slows it down.

 As you say, everything uses CPU on the Geode. Things like

 decompressing can be made, probably, a lot faster just by using compiler
 optimizations. Has this been considered in any way for future releases?

 From my professional experience, compiler optimizations can account

 for 10-30% (or more) free performance.

 It seems the binaries in the OLPC OS image are just generic 386 arch
 binaries.  (Is there a way to definitively tell?  A build log like
 http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/latest/devel_jffs2/build.log
 is unclear.)

 file doesn't say much, everything I have compiled with -march=i686 still
 shows up as i386 binary. I don't know of anything that might tell us that.

Actually while the binary rpm is labelled i386 its compiled using some
other config which I believe is something around i586 or maybe i486 +
some other options which are specified through rpm. Geode is
essentially i586 + cmov (which on intel cpus is i686). There's been a
discussion on fedora-devel [1] about this exact stuff at the moment
due to the introduction of gcc-4.4 in rawhide and some planned uplift
of compiler options, some which is interesting and alot as usual is
opinion. I did bring up the OLPC Geode case to ensure we we're not
forgotten.

 well we use standard Fedora repositories, so I think everything is
 i386.  It would be interesting to see if it actually made a
 difference, if there were real performance increases perhaps Geode can
 be added as a supported arch in Koji.

Koji can support geode, the problem with going that route is that we
become a secondary architecture which means we have to provide the
build servers for it and the space to host essentially a build
infrastructure to be able to rebuild all of Fedora for geode (the way
koji works).

Basically I think what comes out will be fairly close to optimal for
geode. The difference between what mainline Fedora goes with and if we
did a geode option would probably from my reading something less than
1% difference. They're also looking at the -O options, I think Fedora
uses -O2 atm but is considering -O3 or -Os which would help us as
well. There's also alot of code out there that can hot plug the best
cpu options at run time where it matters (see liboil) for multimedia
etc and cairo, gstreamer and the like already use these fairly
extensively.

I would be personally be wary about secondary arch as it would add
alot of extra work and prob cost with likely sub 1% gains. Also
there's alot of RH Fedora people that are involved from the periphery
with OLPC so I don't think we'll lose out in that regard.

Peter

[1]https://www.redhat.com/archives/fedora-devel-list/2009-February/msg00200.html
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: optimized Geode code (was Re: OLPC upgrades)

2009-02-08 Thread Martin Langhoff
On Sun, Feb 8, 2009 at 9:38 PM, Peter Robinson pbrobin...@gmail.com wrote:
 Koji can support geode, the problem with going that route is that we
 become a secondary architecture which means we have to provide the

Exactly.

 Basically I think what comes out will be fairly close to optimal for
 geode. The difference between what mainline Fedora goes with and if we
 did a geode option would probably from my reading something less than
 1% difference.

Ditto. And if people are interested, there has been plenty of
experimentation, reported on this list, about the effect of various -O
and -mtune parameters. Google is your friend.

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-08 Thread Martin Langhoff
2009/2/8 Tiago Marques tiago...@gmail.com:
 On Tue, Feb 3, 2009 at 10:46 PM, Benjamin M. Schwartz
 bmsch...@fas.harvard.edu wrote:

 da...@lang.hm wrote:
  the fact that KDE and GNOME (both desktops that are considered pigs on
  normal machines) make a XO laptop seem snappy by comparison to Sugar (as
  of December) means that there is a significant problem with Sugar.

 I'm not happy to simply take this as fact.  It's either a measurement or
 an opinion.

 It's a fact. I have installed xfce in NAND together with Sugar and I'm
 running Opera with four tabs(one with the heavy gmail) and terminal - using
 136MiB and no swap. Opera seems to leak memory though, it was only of 120MiB

Tiago,

go slower, read Ben's email - he is talking about snappyness and you
are talking about memory.

Memory usage _is_ important, but Ben was talking about... speed.

 Blaming Python for our user-experience speed problems is not scientific,
 and it's not helpful.  Have you found some critical piece of code that you
 can rewrite in C for speed?  We'd love that.

 Would that be welcome?

Yes. And you don't need to write things from scratch - reusing or
adapting existing window managers for example would be a win. We want
to retain the Sugar experience though.

The last 3 months have seen quite a bit of discussion on this list. Do
pay a visit to the archives...

cheers,


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-08 Thread Tiago Marques
On Sun, Feb 8, 2009 at 9:00 AM, Martin Langhoff
martin.langh...@gmail.comwrote:

 2009/2/8 Tiago Marques tiago...@gmail.com:
  On Tue, Feb 3, 2009 at 10:46 PM, Benjamin M. Schwartz
  bmsch...@fas.harvard.edu wrote:
 
  da...@lang.hm wrote:
   the fact that KDE and GNOME (both desktops that are considered pigs on
   normal machines) make a XO laptop seem snappy by comparison to Sugar
 (as
   of December) means that there is a significant problem with Sugar.
 
  I'm not happy to simply take this as fact.  It's either a measurement
 or
  an opinion.
 
  It's a fact. I have installed xfce in NAND together with Sugar and I'm
  running Opera with four tabs(one with the heavy gmail) and terminal -
 using
  136MiB and no swap. Opera seems to leak memory though, it was only of
 120MiB

 Tiago,

 go slower, read Ben's email - he is talking about snappyness and you
 are talking about memory.

 Memory usage _is_ important, but Ben was talking about... speed.

I know Ben was talking about speed, I wanted to give some figures of memory
consumption compared to other desktop environments, since it's probably a
worse problem than speed. IMHO, it is.




  Blaming Python for our user-experience speed problems is not scientific,
  and it's not helpful.  Have you found some critical piece of code that
 you
  can rewrite in C for speed?  We'd love that.
 
  Would that be welcome?

 Yes. And you don't need to write things from scratch - reusing or
 adapting existing window managers for example would be a win. We want
 to retain the Sugar experience though.

Ok. Of course, it must be retained.




 The last 3 months have seen quite a bit of discussion on this list. Do
 pay a visit to the archives...

Ok. Will do.
Best regards,
  Tiago Marques




 cheers,


 m
 --
  martin.langh...@gmail.com
  mar...@laptop.org -- School Server Architect
  - ask interesting questions
  - don't get distracted with shiny stuff  - working code first
  - http://wiki.laptop.org/go/User:Martinlanghoff

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-07 Thread Tiago Marques
On Tue, Feb 3, 2009 at 11:34 PM, Martin Langhoff
martin.langh...@gmail.comwrote:

 On Wed, Feb 4, 2009 at 1:03 PM,  da...@lang.hm wrote:
  Ok, what tools can I use to satisfy you of this 'opinion' that
  applications start faster on either KDE or GNOME than on Sugar on the
 same
  hardware.
 
  by the way, you are the first person I have heard dispute this.

 Erik has done a few things lately that made me change perspective.
 Most comparisons have been made against stuff running off the SD-card,
 and made our Sugar/Fedora look very slow in comparison. Everyone
 jumped on Python/Sugar.

 However, our NAND is *slow*, it busy-waits, JFFS2 is slow, and Linux
 under a bit of mem pressure (and having no swap) starts discarding
 pages, assuming that disk reads are reasonably fast and
 non-cpu-blocking. But reading pages from the NAND turns out to be slow
 and most importantly it pegs the CPU hard.

 Get the debxo or the vanilla fedoras running on the NAND. The
 performance delta is not what we thought it would be.

That's not exactly true. Most software that can be installed using yum(on
the NAND) runs fast. XFCE, for instance, takes some time to load the basic
desktop but then everything is mostly snappy enough and not memory starved.
That software is still not compiled for the Geode LX, which further slows it
down.
As you say, everything uses CPU on the Geode. Things like decompressing can
be made, probably, a lot faster just by using compiler optimizations. Has
this been considered in any way for future releases?
From my professional experience, compiler optimizations can account for
10-30% (or more) free performance.
Best regards,
 Tiago Marques




 cheers,


 m
 --
  martin.langh...@gmail.com
  mar...@laptop.org -- School Server Architect
  - ask interesting questions
  - don't get distracted with shiny stuff  - working code first
  - http://wiki.laptop.org/go/User:Martinlanghoff
 ___
 Devel mailing list
 Devel@lists.laptop.org
 http://lists.laptop.org/listinfo/devel

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-07 Thread Tiago Marques
On Wed, Feb 4, 2009 at 7:14 PM, Wade Brainerd wad...@gmail.com wrote:

 On Wed, Feb 4, 2009 at 1:38 AM, Albert Cahalan acaha...@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

optimized Geode code (was Re: OLPC upgrades)

2009-02-07 Thread S Page
Tiago Marques wrote:
 That software is still not compiled for the Geode LX, which further
slows it down.
 As you say, everything uses CPU on the Geode. Things like
decompressing can be made, probably, a lot faster just by using compiler
optimizations. Has this been considered in any way for future releases?
 From my professional experience, compiler optimizations can account
for 10-30% (or more) free performance.

It seems the binaries in the OLPC OS image are just generic 386 arch 
binaries.  (Is there a way to definitively tell?  A build log like 
http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/latest/devel_jffs2/build.log
 
is unclear.)

This is the case even in the jffs2 OS images that will never be used on 
anything but the stable XO hardware (or in emulation, which AIUI already 
requires AMD CPU emulation because of the tuned kernel).

So every OLPC and activity binary should be compiled with -mtune=geode 
(optimized for Geode, but still runs on any i386), and in jffs2 images 
they should be compiled with -march=geode (only runs on Geode). 
(Should as in I'd like a pink pony too ;-) .)

I assume this is what GentooXO does, http://www.gentooxo.org/features.shtml

https://dev.laptop.org/ticket/118 is the tracking ticket, 
http://wiki.laptop.org/go/Geode_optimization_effort the page.

Thanks for all you do,
--
=S Page
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


optimized Geode code (was Re: OLPC upgrades)

2009-02-07 Thread Tiago Marques
On Sun, Feb 8, 2009 at 12:40 AM, S Page i...@skierpage.com wrote:

 Tiago Marques wrote:

 That software is still not compiled for the Geode LX, which further

 slows it down.

 As you say, everything uses CPU on the Geode. Things like

 decompressing can be made, probably, a lot faster just by using compiler
 optimizations. Has this been considered in any way for future releases?

 From my professional experience, compiler optimizations can account

 for 10-30% (or more) free performance.

 It seems the binaries in the OLPC OS image are just generic 386 arch
 binaries.  (Is there a way to definitively tell?  A build log like 
 http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/latest/devel_jffs2/build.log
 is unclear.)

file doesn't say much, everything I have compiled with -march=i686 still
shows up as i386 binary. I don't know of anything that might tell us that.




 This is the case even in the jffs2 OS images that will never be used on
 anything but the stable XO hardware (or in emulation, which AIUI already
 requires AMD CPU emulation because of the tuned kernel).

 So every OLPC and activity binary should be compiled with -mtune=geode
 (optimized for Geode, but still runs on any i386), and in jffs2 images they
 should be compiled with -march=geode (only runs on Geode). (Should as in
 I'd like a pink pony too ;-) .)

I've read some reports that indicate that using -mtune should be good enough
for added performance, although I mostly compile with -march for my systems.
I never bothered to check but I'll run some tests on the XO to see if it's
significant and worth the extra effort(if feasible, as you say).




 I assume this is what GentooXO does,
 http://www.gentooxo.org/features.shtml

 https://dev.laptop.org/ticket/118 is the tracking ticket,
 http://wiki.laptop.org/go/Geode_optimization_effort the page.

Thanks!
Best regards,
Tiago Marques




 Thanks for all you do,
 --
 =S Page

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: optimized Geode code (was Re: OLPC upgrades)

2009-02-07 Thread Bobby Powers
2009/2/7 Tiago Marques tiago...@gmail.com:
 On Sun, Feb 8, 2009 at 12:40 AM, S Page i...@skierpage.com wrote:

 Tiago Marques wrote:

 That software is still not compiled for the Geode LX, which further

 slows it down.

 As you say, everything uses CPU on the Geode. Things like

 decompressing can be made, probably, a lot faster just by using compiler
 optimizations. Has this been considered in any way for future releases?

 From my professional experience, compiler optimizations can account

 for 10-30% (or more) free performance.

 It seems the binaries in the OLPC OS image are just generic 386 arch
 binaries.  (Is there a way to definitively tell?  A build log like
 http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/latest/devel_jffs2/build.log
 is unclear.)

 file doesn't say much, everything I have compiled with -march=i686 still
 shows up as i386 binary. I don't know of anything that might tell us that.

well we use standard Fedora repositories, so I think everything is
i386.  It would be interesting to see if it actually made a
difference, if there were real performance increases perhaps Geode can
be added as a supported arch in Koji.

bobby


 This is the case even in the jffs2 OS images that will never be used on
 anything but the stable XO hardware (or in emulation, which AIUI already
 requires AMD CPU emulation because of the tuned kernel).

 So every OLPC and activity binary should be compiled with -mtune=geode
 (optimized for Geode, but still runs on any i386), and in jffs2 images they
 should be compiled with -march=geode (only runs on Geode). (Should as in
 I'd like a pink pony too ;-) .)

 I've read some reports that indicate that using -mtune should be good enough
 for added performance, although I mostly compile with -march for my systems.
 I never bothered to check but I'll run some tests on the XO to see if it's
 significant and worth the extra effort(if feasible, as you say).


 I assume this is what GentooXO does,
 http://www.gentooxo.org/features.shtml

 https://dev.laptop.org/ticket/118 is the tracking ticket,
 http://wiki.laptop.org/go/Geode_optimization_effort the page.

 Thanks!
 Best regards,
 Tiago Marques


 Thanks for all you do,
 --
 =S Page



 ___
 Devel mailing list
 Devel@lists.laptop.org
 http://lists.laptop.org/listinfo/devel


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-04 Thread Albert Cahalan
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?

 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.

IIRC, that's about how long it took my old Pentium 200 MMX with 64 MB
of RAM (a quarter of what the XO has) to launch Netscape.

Today on an XO, I can write code that pops up a window far faster than
it needs to. Xlib can do the job in what looks like a few tenths of a
second or better -- it's really too fast for me to tell.

Even with a feature-rich monster like Tux Paint, I can at least pop up
a window much much faster than a Python activity ever does. The stupid
generic splash screen causes a very noticeable slowdown for any activity
that wasn't horrifically slow by itself.

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.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-04 Thread Wade Brainerd
Regarding Gentoo, don't miss http://www.gentooxo.org/.  That project
combined with the Sugar overlay might be a good start for a tiny XO Sugar
distribution.

Wade

On Tue, Feb 3, 2009 at 1:08 PM, Nirbheek Chauhan nirbheek.chau...@gmail.com
 wrote:

 On Wed, Feb 4, 2009 at 2:12 AM, S Page i...@skierpage.com wrote:
  Nirbheek Chauhan wrote:
 
  Since you're looking at making a gentoo-based sugar distro, you might
  find http://gitorious.org/projects/sugar-gentoo useful :)
 
  Please update http://sugarlabs.org/go/Community/Distributions/Gentoo ,
 which
  lists a similar overlay project
  http://git.overlays.gentoo.org/gitweb/?p=proj/sugar.git by Aleksey
 Lim.
   Maybe you could mention differences or work together.
 

 I've talked with Aleksey, and _some_ code sharing is doable. However,
 the approach of the two overlays is completely perpendicular
 (automagic ebuilds using jhconvert vs manual ebuilds), and so one
 cannot replace the other.

 Also, my overlay currently consists of only live git ebuilds (ie, they
 fetch and install from git instead of releases), and release ebuilds
 are blocking on a number of things including
 http://dev.sugarlabs.org/ticket/120 . Once these problems are handled,
 I'll update the aforementioned page.

  --
  Sent from my mobile device
 
  ... with its patented top-post and include the entire message thread
 with
  no changes so every reader must scroll through it to see if you made
 other
  comments UI  8-/

 Yeah, it sucks. gmail for mobile doesn't show the rest of the thread,
 and top-posts without mercy _

 --
 ~Nirbheek Chauhan
 ___
 Devel mailing list
 Devel@lists.laptop.org
 http://lists.laptop.org/listinfo/devel

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-04 Thread Wade Brainerd
On Wed, Feb 4, 2009 at 1:38 AM, Albert Cahalan acaha...@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.


 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
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-04 Thread Francisco Castro
On Wednesday 04 February 2009 17:58:24 Albert Cahalan wrote:
 Assembly has a reputation for being hard, but this is
 far from the truth. It is large assembly projects that are
 hard to understand. For tiny things, assembly is even
 easier than C. What you see is what you get, exactly.
 Python has lots of magic. With assembly, everything
 is there for you to see.

Using assembly is the worst idea for a non hardware related open source 
project, besides the fact that the x86 architecture is awful, programming in 
assembly will lock the software to that architecture, meaning that you would 
have to forget about porting to ARM or MIPS.

Also, in these days C compilers are very good, they can even sometimes 
generate better code than some experienced assemly programmers, thus 
performance reasons are no longer valid.

Rewriting everything done to assembly would take ages, and you'd need to 
rewrite everything again if you change the architecture. If you understand 
me, you should propose C instead.

PS: Sorry for my english.

Regards,

-- 
Francisco Castro


signature.asc
Description: This is a digitally signed message part.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-04 Thread John Watlington

On Feb 4, 2009, at 12:47 AM, Bobby Powers wrote:

 On Tue, Feb 3, 2009 at 7:55 PM,  da...@lang.hm wrote:
 On Wed, 4 Feb 2009, Martin Langhoff wrote:

 On Wed, Feb 4, 2009 at 1:03 PM,  da...@lang.hm wrote:
 Ok, what tools can I use to satisfy you of this 'opinion' that
 applications start faster on either KDE or GNOME than on Sugar  
 on the same
 hardware.

 by the way, you are the first person I have heard dispute this.

 Erik has done a few things lately that made me change perspective.
 Most comparisons have been made against stuff running off the SD- 
 card,
 and made our Sugar/Fedora look very slow in comparison. Everyone
 jumped on Python/Sugar.

 However, our NAND is *slow*, it busy-waits, JFFS2 is slow, and Linux
 under a bit of mem pressure (and having no swap) starts discarding
 pages, assuming that disk reads are reasonably fast and
 non-cpu-blocking. But reading pages from the NAND turns out to be  
 slow
 and most importantly it pegs the CPU hard.

 Get the debxo or the vanilla fedoras running on the NAND. The
 performance delta is not what we thought it would be.

 I know that debxo will install on the NAND. I haven't done so on my
 systems yet as I wanted to leave the NAND intact to test the official
 builds. I'll go ahead and do this on one of my boxes.

 most of my testing has been via USB, do you have any idea how it  
 compares
 performance wise to the NAND and SD card?
SD  USB  NAND

 is there any ability to not use JFFS2 on the NAND?

 I believe UBIFS is the up and coming JFFS2 killer:
 http://www.linux-mtd.infradead.org/doc/ubifs_whitepaper.pdf
 I don't know the status of it tho, I believe there was some testing at
 1CC recently with mixed results.

Testing of UBIFS at 1CC ran into a bug which was patched and
has now been running for months without problems.

See: http://wiki.laptop.org/go/UBIFS_on_XO

Cheers,
wad
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-03 Thread Bobby Powers
2009/2/2 Tiago Marques tiago...@gmail.com:
 On Thu, Jan 29, 2009 at 4:03 AM, Mitch Bradley w...@laptop.org wrote:

 Guess what? The people at OLPC, who aren't stupid, already considered
 every point in the message cited below, a long time ago. So why aren't
 we doing them? ...* *On Wed, Jan 28, 2009 at 9:57 PM, Carlos Nazareno
 object...@gmail.comwrote:

 Nobody's saying anyone is stupid. It is perfectly natural for people to
 complain about things they don't understand. I also wish I could, from time
 to time, to ask this or that, to understand many things I don't comprehend,
 to know what I can do to help. This without getting into any kind of fight

As you note in this email (which reads more like a rant than
constructive criticism, I must say), there is a lot to help with!
What are you areas of interest and expertise?

 with the people involved with the project, who are the only ones who can
 answer those questions.
 As with any critical comment I may issue in this mailing list, please take
 it as something constructive, to help (if it does, in any way) and not to
 criticize the people who are hard at work. That, I think, is what Carlos was
 trying to do.
 I got my XO three weeks ago and there's a lot I was surprised to learn that
 some of the more important features are WIP or simply don't work, especially
 given the news that I've read, already detailing prototypes of a second
 version, when there's still a lot to do with the first one.
 Sugar is a fantastic window manager/desktop/user interface/learning
 tool/whatever. I don't understand how can any government give 6 year olds
 anything that's not Sugar - it is wonderful, it integrates very well with
 the XO and I would like to be able to use it more but it doesn't really
 blend well with the rest of the Linux software ecosystem.

We need a lot of help in this area, interested?

 This, among other things, may be the cause that the G1G1 program wasn't
 successful this year. There are too many better options, for a regular user,
 currently available, and cheaper. Most people don't care for a reflective
 screen if they can't have Youtube. They already can have 5 hours of battery
 life(or more) in some netbooks, a lot more flash memory/HDD, better *color*
 screen. Even then some people claim the performance of netbooks isn't good
 enough - imagine what they would say about an XO.
 I'm surprised how much stuff still doesn't work in the XO. I can't, for as
 much as I think about it, how can you be shipping these things without space
 for swap memory. I can open a PDF and a browser without the XO being
 apparently crashed and this is the most basic stuff. I know why the system
 crashes but you can't expect a politician to understand why Intel's
 offering doesn't crash and yours does all the time, it just makes it look
 like crap, which it certainly isn't. Doing SWAP in the embedded flash is a
 bad ideia but there's an SD card slot and having the XO crashing all the
 time is a worst case scenario - it may be a compromise in Africa but not in

I use debXO and haven't had a single crash.  if activities are
crashing, please please please look up or create tickets for the
crashes, with as much info and logs as possible!  (take this as
constructive criticism, on how to make your constructive criticism
reach the right people faster and more constructively :) )

 the least developed country.
 There's no stylus support yet, there's no view source working(AFAIK) and the

The current dual mode touchpad hardware is being discontinued and new
machines are either currently, or will be in short order, being
produced with a 'standard' capacitive touchpad.  IN FACT, the stylus
mode had been implemented and enabled in the driver in previous builds
(joyride, up to the beginning or middle of summer 08), but was
disabled and removed from the driver because having the device in dual
input mode made things worse for a large number of laptops.  The dual
mode hardware is pretty flakey.

I believe view source is implemented to some extent in Sugar 0.83 (the
current development branch).

 wireless range isn't as awsome as announced. My mother has an Acer One
 which, apparently, has a significantly better wireless signal, at least from
 small experiences, I haven't messed with it much, it's an initial impression
 - which for most people is the one that matters.
 Worse is the battery life, I can't get more than 3 hours out of my XO and
 all seems fine with the battery. If I was to heavily depend on the 24 hours
 touted(when not even 24 in suspend), I would be very disappointed, let alone
 6 hours which I also don't get. Experimental results isn't something that
 the project should be shouting about all the time - that's just vaporware.
 Worse, it makes the OLPC Foundation loose credibility as a whole. No company
 can be constantly over promising and underdelivering, let alone a non-profit
 foundation.

Have any experience with the kernel or suspend/resume issues?  I'm
sure CJB would 

Re: OLPC upgrades

2009-02-03 Thread Wade Brainerd
A patch isn't really appropriate but generally speaking I:

- Followed Mitch Bradley's instructions for tar-ing /dev.
- Replaced the initrd with a 3 liner using busybox that just mounts  
NAND and calls switch_root.  This involved undoing all the version  
stuff in the filesystem.
- Replaced rc.sysinit with a 30 line script that starts the services I  
want and mounts the required points.
- Removed the entire SYSV runlevel system.

I was learning about all this stuff as I did it, but it still didn't  
take that long.  And I have a lot of plans to make it even faster.

A few things don't work right, like I'm still trying to figure out why  
there are no network interfaces...But If anyone would like to see the  
scripts I'd be happy to share them.

Wade

On Feb 2, 2009, at 9:41 PM, C. Scott Ananian csc...@laptop.org  
wrote:

 2009/2/2 Wade Brainerd wad...@gmail.com:
 take better advantage of the excellent hardware that is the XO-1.   
 I'd
 really like to see someone try to build a tiny LFS based XO  
 specific distro
 which runs Sugar, and boots in 30sec :)  I've got my personal XO  
 booting in
 around 45sec just by hacking around in the initscripts, and I'm  
 sure a lot
 better could be done.

 Patches?
 --scott

 -- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-03 Thread S Page
Nirbheek Chauhan wrote:
 Since you're looking at making a gentoo-based sugar distro, you might
 find http://gitorious.org/projects/sugar-gentoo useful :)

Please update http://sugarlabs.org/go/Community/Distributions/Gentoo , 
which lists a similar overlay project 
http://git.overlays.gentoo.org/gitweb/?p=proj/sugar.git by Aleksey 
Lim.  Maybe you could mention differences or work together.

 -- 
 Sent from my mobile device
... with its patented top-post and include the entire message thread 
with no changes so every reader must scroll through it to see if you 
made other comments UI  8-/

Cheers,
--
=S Page
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-03 Thread Nirbheek Chauhan
On Wed, Feb 4, 2009 at 2:12 AM, S Page i...@skierpage.com wrote:
 Nirbheek Chauhan wrote:

 Since you're looking at making a gentoo-based sugar distro, you might
 find http://gitorious.org/projects/sugar-gentoo useful :)

 Please update http://sugarlabs.org/go/Community/Distributions/Gentoo , which
 lists a similar overlay project
 http://git.overlays.gentoo.org/gitweb/?p=proj/sugar.git by Aleksey Lim.
  Maybe you could mention differences or work together.


I've talked with Aleksey, and _some_ code sharing is doable. However,
the approach of the two overlays is completely perpendicular
(automagic ebuilds using jhconvert vs manual ebuilds), and so one
cannot replace the other.

Also, my overlay currently consists of only live git ebuilds (ie, they
fetch and install from git instead of releases), and release ebuilds
are blocking on a number of things including
http://dev.sugarlabs.org/ticket/120 . Once these problems are handled,
I'll update the aforementioned page.

 --
 Sent from my mobile device

 ... with its patented top-post and include the entire message thread with
 no changes so every reader must scroll through it to see if you made other
 comments UI  8-/

Yeah, it sucks. gmail for mobile doesn't show the rest of the thread,
and top-posts without mercy _

-- 
~Nirbheek Chauhan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-03 Thread Martin Langhoff
On Wed, Feb 4, 2009 at 1:03 PM,  da...@lang.hm wrote:
 Ok, what tools can I use to satisfy you of this 'opinion' that
 applications start faster on either KDE or GNOME than on Sugar on the same
 hardware.

 by the way, you are the first person I have heard dispute this.

Erik has done a few things lately that made me change perspective.
Most comparisons have been made against stuff running off the SD-card,
and made our Sugar/Fedora look very slow in comparison. Everyone
jumped on Python/Sugar.

However, our NAND is *slow*, it busy-waits, JFFS2 is slow, and Linux
under a bit of mem pressure (and having no swap) starts discarding
pages, assuming that disk reads are reasonably fast and
non-cpu-blocking. But reading pages from the NAND turns out to be slow
and most importantly it pegs the CPU hard.

Get the debxo or the vanilla fedoras running on the NAND. The
performance delta is not what we thought it would be.

cheers,


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-03 Thread david
On Wed, 4 Feb 2009, Martin Langhoff wrote:

 On Wed, Feb 4, 2009 at 1:03 PM,  da...@lang.hm wrote:
 Ok, what tools can I use to satisfy you of this 'opinion' that
 applications start faster on either KDE or GNOME than on Sugar on the same
 hardware.

 by the way, you are the first person I have heard dispute this.

 Erik has done a few things lately that made me change perspective.
 Most comparisons have been made against stuff running off the SD-card,
 and made our Sugar/Fedora look very slow in comparison. Everyone
 jumped on Python/Sugar.

 However, our NAND is *slow*, it busy-waits, JFFS2 is slow, and Linux
 under a bit of mem pressure (and having no swap) starts discarding
 pages, assuming that disk reads are reasonably fast and
 non-cpu-blocking. But reading pages from the NAND turns out to be slow
 and most importantly it pegs the CPU hard.

 Get the debxo or the vanilla fedoras running on the NAND. The
 performance delta is not what we thought it would be.

I know that debxo will install on the NAND. I haven't done so on my 
systems yet as I wanted to leave the NAND intact to test the official 
builds. I'll go ahead and do this on one of my boxes.

most of my testing has been via USB, do you have any idea how it compares 
performance wise to the NAND and SD card?

is there any ability to not use JFFS2 on the NAND?

David Lang
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-03 Thread david
On Tue, 3 Feb 2009, Benjamin M. Schwartz wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 da...@lang.hm wrote:
 the fact that KDE and GNOME (both desktops that are considered pigs on
 normal machines) make a XO laptop seem snappy by comparison to Sugar (as
 of December) means that there is a significant problem with Sugar.

 I'm not happy to simply take this as fact.  It's either a measurement or
 an opinion.

Ok, what tools can I use to satisfy you of this 'opinion' that 
applications start faster on either KDE or GNOME than on Sugar on the same 
hardware.

by the way, you are the first person I have heard dispute this.

 when
 people ask about how to fix things, the answers that keep coming back
 all appear to be python related.

 The whole system is in Python!  Everything is going to be python-related!

no, it's only python related if implementations that don't use python 
are significantly faster. and they are.

 so it's not FUD to say that the
 dependance on Python is hurting performance.

 It's not FUD, but it's not exactly substantiated.  We have some
 understanding of where we are spending our cycles, and it's not as simple
 as in the python interpreter.  For example, measurements of activity
 startup time indicate that we're spending a lot of time in SVG rendering
 and Cairo.  This isn't too surprising, since Sugar uses SVGs much more
 intensively than most desktop environments, and often renders many
 different versions of the same icon for the purposes of recolorization or
 animation.

 There are certainly many improvements we could make to perceived speed.
 Some, like fixing upstream modules (e.g. dbus-python) not to do any
 computation at import time, are python-related, though they have little
 to do with the language itself.  Some, like switching to a better
 filesystem or testing LZO support in JFFS2, are entirely separate.  Many,
 like rewriting the Journal GUI to minimize redrawing of widgets and enable
 smarter scrolling, are large projects.

 Blaming Python for our user-experience speed problems is not scientific,
 and it's not helpful.  Have you found some critical piece of code that you
 can rewrite in C for speed?  We'd love that.

let's start with the application startup time. the last I heard the reason 
why it take a noticable amount of time to startup a trivial app like the 
terminal window is due to all the python module initialization.

unless this has changed in something newer than 8.2, it's still several 
seconds to start the terminal window compared to significantly sub-second 
to starup xterm (to give a trivial enough example to be easily measured)

similar differences show up with more complex apps like browsers.

it doesn't matter if it's 'python related' by your definition, or only 
becouse using python is forcing you to use the associated python libraries 
that do stupid things at startup time. either way it's the python 
implementation that is the problem.

David Lang
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-03 Thread Benjamin M. Schwartz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

da...@lang.hm wrote:
 the fact that KDE and GNOME (both desktops that are considered pigs on
 normal machines) make a XO laptop seem snappy by comparison to Sugar (as
 of December) means that there is a significant problem with Sugar.

I'm not happy to simply take this as fact.  It's either a measurement or
an opinion.

 when
 people ask about how to fix things, the answers that keep coming back
 all appear to be python related.

The whole system is in Python!  Everything is going to be python-related!

 so it's not FUD to say that the
 dependance on Python is hurting performance.

It's not FUD, but it's not exactly substantiated.  We have some
understanding of where we are spending our cycles, and it's not as simple
as in the python interpreter.  For example, measurements of activity
startup time indicate that we're spending a lot of time in SVG rendering
and Cairo.  This isn't too surprising, since Sugar uses SVGs much more
intensively than most desktop environments, and often renders many
different versions of the same icon for the purposes of recolorization or
animation.

There are certainly many improvements we could make to perceived speed.
Some, like fixing upstream modules (e.g. dbus-python) not to do any
computation at import time, are python-related, though they have little
to do with the language itself.  Some, like switching to a better
filesystem or testing LZO support in JFFS2, are entirely separate.  Many,
like rewriting the Journal GUI to minimize redrawing of widgets and enable
smarter scrolling, are large projects.

Blaming Python for our user-experience speed problems is not scientific,
and it's not helpful.  Have you found some critical piece of code that you
can rewrite in C for speed?  We'd love that.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmIyVUACgkQUJT6e6HFtqSgFgCfdmmKz5qoy7AdDw7XVq1lh0/t
NmMAnij1vpH7oGOa/9h2z/fvrlP745gs
=VpmM
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-03 Thread Tiago Marques
On Tue, Feb 3, 2009 at 8:38 AM, Bobby Powers bobbypow...@gmail.com wrote:

 2009/2/2 Tiago Marques tiago...@gmail.com:
  On Thu, Jan 29, 2009 at 4:03 AM, Mitch Bradley w...@laptop.org wrote:
 
  Guess what? The people at OLPC, who aren't stupid, already considered
  every point in the message cited below, a long time ago. So why aren't
  we doing them? ...* *On Wed, Jan 28, 2009 at 9:57 PM, Carlos Nazareno
  object...@gmail.comwrote:
 
  Nobody's saying anyone is stupid. It is perfectly natural for people to
  complain about things they don't understand. I also wish I could, from
 time
  to time, to ask this or that, to understand many things I don't
 comprehend,
  to know what I can do to help. This without getting into any kind of
 fight

 As you note in this email (which reads more like a rant than
 constructive criticism, I must say), there is a lot to help with!
 What are you areas of interest and expertise?

Sorry... It was not my intention, I try to avoid ranting, but can't help it
sometimes.
I like to do optimization, I usually do compiler optimization tests and
benchmarking on some stuff at work, although I'm also interested in doing
code optimization if needed.
The XO has several areas I'd like to see improved but I think I'll start by
this one. I've seen a bit of ongoing effort on the wiki, I'm thinking of
talking to the people involved when I get some results from my Gentoo tests.
I also saw the Browse needs tabs ticket and I thought I might try a shot
at that also.




  with the people involved with the project, who are the only ones who can
  answer those questions.
  As with any critical comment I may issue in this mailing list, please
 take
  it as something constructive, to help (if it does, in any way) and not to
  criticize the people who are hard at work. That, I think, is what Carlos
 was
  trying to do.
  I got my XO three weeks ago and there's a lot I was surprised to learn
 that
  some of the more important features are WIP or simply don't work,
 especially
  given the news that I've read, already detailing prototypes of a second
  version, when there's still a lot to do with the first one.
  Sugar is a fantastic window manager/desktop/user interface/learning
  tool/whatever. I don't understand how can any government give 6 year olds
  anything that's not Sugar - it is wonderful, it integrates very well with
  the XO and I would like to be able to use it more but it doesn't really
  blend well with the rest of the Linux software ecosystem.

 We need a lot of help in this area, interested?

Definitely. Anything particular in mind?




  This, among other things, may be the cause that the G1G1 program wasn't
  successful this year. There are too many better options, for a regular
 user,
  currently available, and cheaper. Most people don't care for a reflective
  screen if they can't have Youtube. They already can have 5 hours of
 battery
  life(or more) in some netbooks, a lot more flash memory/HDD, better
 *color*
  screen. Even then some people claim the performance of netbooks isn't
 good
  enough - imagine what they would say about an XO.
  I'm surprised how much stuff still doesn't work in the XO. I can't, for
 as
  much as I think about it, how can you be shipping these things without
 space
  for swap memory. I can open a PDF and a browser without the XO being
  apparently crashed and this is the most basic stuff. I know why the
 system
  crashes but you can't expect a politician to understand why Intel's
  offering doesn't crash and yours does all the time, it just makes it look
  like crap, which it certainly isn't. Doing SWAP in the embedded flash is
 a
  bad ideia but there's an SD card slot and having the XO crashing all the
  time is a worst case scenario - it may be a compromise in Africa but not
 in

 I use debXO and haven't had a single crash.  if activities are
 crashing, please please please look up or create tickets for the
 crashes, with as much info and logs as possible!  (take this as
 constructive criticism, on how to make your constructive criticism
 reach the right people faster and more constructively :) )

I thought of submitting a bug that said XO needs SWAP badly or something
like that, which I abstained of doing until I could understand the
motivation behind not using swap at all in the XO, when a 2GB SD card costs
3eur at retail here - seems a good compromise given what is achieved from
the small extra cost. My XO was constantly crashing, now it's just a bit
slow moving from app to app.
From what I read since I subscribed the ML, it seems to relate to battery
life dropping with SD cards but that's the only thing that I've read until
now. Having the XO constantly crashing will probably kill the battery life
more than having the SD card there.
This review by a 12-year old (
http://www.freedom-to-tinker.com/blog/sg/one-laptop-child-reviewed-12-year-old-
special attention to the fourth paragraph, if it was a 12 year old who
wrote that) pretty much sums 

Re: OLPC upgrades

2009-02-03 Thread david

On Tue, 3 Feb 2009, Tiago Marques wrote:


On Tue, Feb 3, 2009 at 8:38 AM, Bobby Powers bobbypow...@gmail.com wrote:


2009/2/2 Tiago Marques tiago...@gmail.com:

On Thu, Jan 29, 2009 at 4:03 AM, Mitch Bradley w...@laptop.org wrote:


The current dual mode touchpad hardware is being discontinued and new
machines are either currently, or will be in short order, being
produced with a 'standard' capacitive touchpad.  IN FACT, the stylus
mode had been implemented and enabled in the driver in previous builds
(joyride, up to the beginning or middle of summer 08), but was
disabled and removed from the driver because having the device in dual
input mode made things worse for a large number of laptops.  The dual
mode hardware is pretty flakey.

I believe view source is implemented to some extent in Sugar 0.83 (the
current development branch).


Hmm ok. Is it possible/easy to use the whole touchpad as pointing
device, instead of just the middle. Since the middle has no bump that
could give some feeling of where it ends, enabling all would make it more
usable. At least I, frequently, need to look at it to understand if it's
going bonkers on me, or if I'm just trying to use it out of the it's limit.
I don't see a practical use for all that wideness but it would just to be
less error prone.


only the center section is a touchpad, the sides are the stylus-only 
areas. the new systems are not going to have the 'wide pad', only the 
center section.



Have any experience with the kernel or suspend/resume issues?  I'm
sure CJB would love some help here.


Not really, I just hacked a driver once to add AGP and IDE DMA support for a
VIA chipset, just added the hardware IDs.


as I understand it, the biggest problem right now is that the power 
savings stuff is all done in a Sugar specific way. I've used Sugar with 
full power savings enabled (backlight off) for light-duty tasks (e-book 
functions) and had it last an 8-hour day with half the battery remaining. 
I've also had it last 2-3 hours with power savings off and the backlight 
running.


non-Sugar distros currently can't do any power management, so they are 
stuck with the short battery life. As this gets fixed and the power 
capabilities get standardized this should improve.



they should, and that leaves the XO in a competitively bad position. And
that's what you should also talk about, nowadays everyone knows they're
ripped off in their laptops, iPhone, PSP, whatever battery, that's part

of a

good image that the project can benefit from, if retail availability ever
comes.
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.  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 :)


That's my view on it, although I don't have any experience in Python
programming. Launch time doesn't really bother me, memory consumption on a
device with no swap and 256MB of RAM does. Is it just Sugar/Fedora/XO distro
specific?
Please elaborate on what you mean by 8.2 taking much longer to launch. That
would be something I would be interested in looking at, although I don't
think I have what it takes to fix Pyhton itself, if that's what's needed.


the fact that KDE and GNOME (both desktops that are considered pigs on 
normal machines) make a XO laptop seem snappy by comparison to Sugar (as 
of December) means that there is a significant problem with Sugar. when 
people ask about how to fix things, the answers that keep coming back all 
appear to be python related. so it's not FUD to say that the dependance on 
Python is hurting performance.


David Lang___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-03 Thread Bobby Powers
On Tue, Feb 3, 2009 at 7:55 PM,  da...@lang.hm wrote:
 On Wed, 4 Feb 2009, Martin Langhoff wrote:

 On Wed, Feb 4, 2009 at 1:03 PM,  da...@lang.hm wrote:
 Ok, what tools can I use to satisfy you of this 'opinion' that
 applications start faster on either KDE or GNOME than on Sugar on the same
 hardware.

 by the way, you are the first person I have heard dispute this.

 Erik has done a few things lately that made me change perspective.
 Most comparisons have been made against stuff running off the SD-card,
 and made our Sugar/Fedora look very slow in comparison. Everyone
 jumped on Python/Sugar.

 However, our NAND is *slow*, it busy-waits, JFFS2 is slow, and Linux
 under a bit of mem pressure (and having no swap) starts discarding
 pages, assuming that disk reads are reasonably fast and
 non-cpu-blocking. But reading pages from the NAND turns out to be slow
 and most importantly it pegs the CPU hard.

 Get the debxo or the vanilla fedoras running on the NAND. The
 performance delta is not what we thought it would be.

 I know that debxo will install on the NAND. I haven't done so on my
 systems yet as I wanted to leave the NAND intact to test the official
 builds. I'll go ahead and do this on one of my boxes.

 most of my testing has been via USB, do you have any idea how it compares
 performance wise to the NAND and SD card?

 is there any ability to not use JFFS2 on the NAND?

I believe UBIFS is the up and coming JFFS2 killer:
http://www.linux-mtd.infradead.org/doc/ubifs_whitepaper.pdf
I don't know the status of it tho, I believe there was some testing at
1CC recently with mixed results.

bobby

 David Lang
 ___
 Devel mailing list
 Devel@lists.laptop.org
 http://lists.laptop.org/listinfo/devel

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-02 Thread Tiago Marques
On Fri, Jan 30, 2009 at 2:18 PM, Frank Ch. Eigler f...@redhat.com wrote:

 Mitch Bradley w...@laptop.org writes:

  [...]  It's also worth pointing out that the new low-power x86
  processors, Atom being the poster child, are still stuck with
  power-hungry support chips - memory and display controllers.  That
  might change soon, but for now it's still the case.  [...]

 According to the ACPI battery gauges under Fedora 10, my Fujitsu U820
 UMPC (Atom Z530, Poulsbo GMA500 MCH/graphics) takes around 6W *total*

 during light webby operations.

 This is probably correct:

(copy paste from other thread)The Atom draws very little power. I already
referred that there is an Atom that has a 0.65W TDP, not 3.whatever like in
the Geode LX. These are the Z series and they draw very little power, top of
2.4W for the 1866MHz model. The other low-end chip(also $20), the Z510, has
a TDP of 2W - any one of these can run without an heatsink, mostly a small
metal plate that allows the silicon core to dissipate heat, since it's a
fliped-chip design. The Z500 is obviously very very good for embedded
applications.
The Z series use a lower power CMOS bus, instead of the power hungry GTL+,
which when paired with Poulsbo it should make for a remarkable package. The
next iteration will also have the graphics core and some other stuff
embedded, for further savings.



 - FChE
 ___
 Devel mailing list
 Devel@lists.laptop.org
 http://lists.laptop.org/listinfo/devel

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-02 Thread Tiago Marques
On Thu, Jan 29, 2009 at 4:03 AM, Mitch Bradley w...@laptop.org wrote:

 Guess what? The people at OLPC, who aren't stupid, already considered
 every point in the message cited below, a long time ago. So why aren't
 we doing them? ...* *On Wed, Jan 28, 2009 at 9:57 PM, Carlos Nazareno
 object...@gmail.comwrote:

Nobody's saying anyone is stupid. It is perfectly natural for people to
complain about things they don't understand. I also wish I could, from time
to time, to ask this or that, to understand many things I don't comprehend,
to know what I can do to help. This without getting into any kind of fight
with the people involved with the project, who are the only ones who can
answer those questions.
As with any critical comment I may issue in this mailing list,* please take
it as something constructive*, to help (if it does, in any way) and not to
criticize the people who are hard at work. That, I think, is what Carlos was
trying to do.
I got my XO three weeks ago and there's a lot I was surprised to learn that
some of the more important features are WIP or simply don't work, especially
given the news that I've read, already detailing prototypes of a second
version, when there's still a lot to do with the first one.
Sugar is a fantastic window manager/desktop/user interface/learning
tool/whatever. I don't understand how can *any* government give 6 year olds
anything that's not Sugar - it is wonderful, it integrates very well with
the XO and I would like to be able to use it more but it doesn't really
blend well with the rest of the Linux software ecosystem.
This, among other things, may be the cause that the G1G1 program wasn't
successful this year. There are too many better options, for a regular user,
currently available, and cheaper. Most people don't care for a reflective
screen if they can't have Youtube. They already can have 5 hours of battery
life(or more) in some netbooks, a lot more flash memory/HDD, better *color*
screen. Even then some people claim the performance of netbooks isn't good
enough - imagine what they would say about an XO.
I'm surprised how much stuff still doesn't work in the XO. I can't, for as
much as I think about it, how can you be shipping these things without space
for swap memory. I can open a PDF and a browser without the XO being
apparently crashed and this is the most basic stuff. I know why the system
crashes but you can't expect a politician to understand why Intel's
offering doesn't crash and yours does all the time, *it just makes it look
like crap*, which it certainly isn't. Doing SWAP in the embedded flash is a
bad ideia but there's an SD card slot and having the XO crashing all the
time is a worst case scenario - it may be a compromise in Africa but not in
the least developed country.
There's no stylus support yet, there's no view source working(AFAIK) and the
wireless range isn't as awsome as announced. My mother has an Acer One
which, apparently, has a significantly better wireless signal, at least from
small experiences, I haven't messed with it much, it's an initial impression
- which for most people is the one that matters.
Worse is the battery life, I can't get more than 3 hours out of my XO and
all seems fine with the battery. If I was to heavily depend on the 24 hours
touted(when not even 24 in suspend), I would be very disappointed, let alone
6 hours which I also don't get. Experimental results isn't something that
the project should be shouting about all the time - that's just vaporware.
Worse, it makes the OLPC Foundation loose credibility as a whole. No company
can be constantly over promising and underdelivering, let alone a non-profit
foundation.
Currently, aside from the screen and mesh networking, you're loosing by big
points in all the rest. The advantages the XO still has are things that
don't matter for most potential buying governments, the ones who have the
big bucks.
I don't know where the foundation got the numbers in the first time, but 50
million laptops was far from anything that can be achieved. Especially
without retail availability of a $170 laptop. IMHO, or the XO-1 has retail
availability soon, that can(finally) bring that number to the desired
target, or you eventually loose out to Intel (with dire consequences). After
all, retail availability has been bringing production costs down for them.
Either you make it unprofitable for them or they make it unfeasible for you
to follow the vision.
You can't expect most people to pay $399 for a laptop (spectacular for third
world countries) of no (or limited) usefulness for a regular person. Not
with faster netbooks available at $199 (have you seen an acer one
booting???) - not everyone is so good at their heart to give one away, when
they can save $199 for themselves. Not everyone knows that your battery
lasts four times more, that it costs only $25 to replace, that all parts are
cheap, if they ever break! That doesn't matter for most people, even though
they should, and that leaves the XO 

Re: OLPC upgrades

2009-02-02 Thread Wade Brainerd
2009/2/2 Tiago Marques tiago...@gmail.com

 On Thu, Jan 29, 2009 at 4:03 AM, Mitch Bradley w...@laptop.org wrote:

 Guess what? The people at OLPC, who aren't stupid, already considered
 every point in the message cited below, a long time ago. So why aren't
 we doing them? ...* *On Wed, Jan 28, 2009 at 9:57 PM, Carlos Nazareno
 object...@gmail.comwrote:

 Nobody's saying anyone is stupid. It is perfectly natural for people to
 complain about things they don't understand. I also wish I could, from time
 to time, to ask this or that, to understand many things I don't comprehend,
 to know what I can do to help. This without getting into any kind of fight
 with the people involved with the project, who are the only ones who can
 answer those questions.
 As with any critical comment I may issue in this mailing list,* please
 take it as something constructive*, to help (if it does, in any way) and
 not to criticize the people who are hard at work. That, I think, is what
 Carlos was trying to do.
 I got my XO three weeks ago and there's a lot I was surprised to learn that
 some of the more important features are WIP or simply don't work, especially
 given the news that I've read, already detailing prototypes of a second
 version, when there's still a lot to do with the first one.


Hey Tiago,

I've been following the project for about 2 years now and the software
problems you cite (OOM crashing, flaky wireless,  battery life, sluggish UI)
are pretty much the same ones that existed back when I got involved!  The
lack of momentum on the software front has been pretty amazing given how
much the project started with.

That said, things seem to be picking up speed as more control over the
software is handed to the community.  I finally feel like there's maybe a
chance to see some of this stuff get resolved.

Here's hoping SL's XOOS or SoaS, or else some deployment's distribution will
take better advantage of the excellent hardware that is the XO-1.  I'd
really like to see someone try to build a tiny LFS based XO specific distro
which runs Sugar, and boots in 30sec :)  I've got my personal XO booting in
around 45sec just by hacking around in the initscripts, and I'm sure a lot
better could be done.

Best,
-Wade
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-02 Thread Tiago Marques
On Mon, Feb 2, 2009 at 11:18 PM, Wade Brainerd wad...@gmail.com wrote:

 2009/2/2 Tiago Marques tiago...@gmail.com

 On Thu, Jan 29, 2009 at 4:03 AM, Mitch Bradley w...@laptop.org wrote:

 Guess what? The people at OLPC, who aren't stupid, already considered
 every point in the message cited below, a long time ago. So why aren't
 we doing them? ...* *On Wed, Jan 28, 2009 at 9:57 PM, Carlos Nazareno
 object...@gmail.comwrote:

 Nobody's saying anyone is stupid. It is perfectly natural for people to
 complain about things they don't understand. I also wish I could, from time
 to time, to ask this or that, to understand many things I don't comprehend,
 to know what I can do to help. This without getting into any kind of fight
 with the people involved with the project, who are the only ones who can
 answer those questions.
 As with any critical comment I may issue in this mailing list,* please
 take it as something constructive*, to help (if it does, in any way) and
 not to criticize the people who are hard at work. That, I think, is what
 Carlos was trying to do.
 I got my XO three weeks ago and there's a lot I was surprised to learn
 that some of the more important features are WIP or simply don't work,
 especially given the news that I've read, already detailing prototypes of a
 second version, when there's still a lot to do with the first one.


 Hey Tiago,

 I've been following the project for about 2 years now and the software
 problems you cite (OOM crashing, flaky wireless,  battery life, sluggish UI)
 are pretty much the same ones that existed back when I got involved!  The
 lack of momentum on the software front has been pretty amazing given how
 much the project started with.

 That said, things seem to be picking up speed as more control over the
 software is handed to the community.  I finally feel like there's maybe a
 chance to see some of this stuff get resolved.

 Here's hoping SL's XOOS or SoaS, or else some deployment's distribution
 will take better advantage of the excellent hardware that is the XO-1.  I'd
 really like to see someone try to build a tiny LFS based XO specific distro
 which runs Sugar, and boots in 30sec :)  I've got my personal XO booting in
 around 45sec just by hacking around in the initscripts, and I'm sure a lot
 better could be done.

Hi Wade,
I use Gentoo for professional and personal use in almost all of my machines
and will probably install Gentoo in some binary way to dual boot the XO with
Sugar(it fits the XO too well, in some ways, to simply delete it). This will
be the most optimized code I can have the compiler generate, which should
yield some nice improvements, compiled with the smallest feature set needed.
I have a machine running KDE 3.5 in 80MB with two or three KDE apps loaded,
but that is still overkill for the XO. XFCE/Fluxbox would be something to
experiment with.
I have a server here in college to do a package server, with which other
users may use, but I still need some free time to finish the basic gentoo
based distro, which will hardly come with an installer, other than a stage
package compiled for the Geode.
I would like to see python less resource bound but I unfortunately have
neither the time nor the skill to go hacking it.
Best regards,
  Tiago Marques


 Best,
 -Wade

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-02 Thread Nirbheek Chauhan
Since you're looking at making a gentoo-based sugar distro, you might
find http://gitorious.org/projects/sugar-gentoo useful :)

On 2/3/09, Tiago Marques tiago...@gmail.com wrote:
 On Mon, Feb 2, 2009 at 11:18 PM, Wade Brainerd wad...@gmail.com wrote:

 2009/2/2 Tiago Marques tiago...@gmail.com

 On Thu, Jan 29, 2009 at 4:03 AM, Mitch Bradley w...@laptop.org wrote:

 Guess what? The people at OLPC, who aren't stupid, already considered
 every point in the message cited below, a long time ago. So why aren't
 we doing them? ...* *On Wed, Jan 28, 2009 at 9:57 PM, Carlos Nazareno
 object...@gmail.comwrote:

 Nobody's saying anyone is stupid. It is perfectly natural for people to
 complain about things they don't understand. I also wish I could, from
 time
 to time, to ask this or that, to understand many things I don't
 comprehend,
 to know what I can do to help. This without getting into any kind of
 fight
 with the people involved with the project, who are the only ones who can
 answer those questions.
 As with any critical comment I may issue in this mailing list,* please
 take it as something constructive*, to help (if it does, in any way) and
 not to criticize the people who are hard at work. That, I think, is what
 Carlos was trying to do.
 I got my XO three weeks ago and there's a lot I was surprised to learn
 that some of the more important features are WIP or simply don't work,
 especially given the news that I've read, already detailing prototypes of
 a
 second version, when there's still a lot to do with the first one.


 Hey Tiago,

 I've been following the project for about 2 years now and the software
 problems you cite (OOM crashing, flaky wireless,  battery life, sluggish
 UI)
 are pretty much the same ones that existed back when I got involved!  The
 lack of momentum on the software front has been pretty amazing given how
 much the project started with.

 That said, things seem to be picking up speed as more control over the
 software is handed to the community.  I finally feel like there's maybe a
 chance to see some of this stuff get resolved.

 Here's hoping SL's XOOS or SoaS, or else some deployment's distribution
 will take better advantage of the excellent hardware that is the XO-1.
 I'd
 really like to see someone try to build a tiny LFS based XO specific
 distro
 which runs Sugar, and boots in 30sec :)  I've got my personal XO booting
 in
 around 45sec just by hacking around in the initscripts, and I'm sure a lot
 better could be done.

 Hi Wade,
 I use Gentoo for professional and personal use in almost all of my machines
 and will probably install Gentoo in some binary way to dual boot the XO with
 Sugar(it fits the XO too well, in some ways, to simply delete it). This will
 be the most optimized code I can have the compiler generate, which should
 yield some nice improvements, compiled with the smallest feature set needed.
 I have a machine running KDE 3.5 in 80MB with two or three KDE apps loaded,
 but that is still overkill for the XO. XFCE/Fluxbox would be something to
 experiment with.
 I have a server here in college to do a package server, with which other
 users may use, but I still need some free time to finish the basic gentoo
 based distro, which will hardly come with an installer, other than a stage
 package compiled for the Geode.
 I would like to see python less resource bound but I unfortunately have
 neither the time nor the skill to go hacking it.
 Best regards,
   Tiago Marques


 Best,
 -Wade



-- 
Sent from my mobile device

~Nirbheek Chauhan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-02 Thread Tiago Marques
Thanks, much appreciated :)

Best regards

On Mon, Feb 2, 2009 at 11:59 PM, Nirbheek Chauhan 
nirbheek.chau...@gmail.com wrote:

 Since you're looking at making a gentoo-based sugar distro, you might
 find http://gitorious.org/projects/sugar-gentoo useful :)

 On 2/3/09, Tiago Marques tiago...@gmail.com wrote:
  On Mon, Feb 2, 2009 at 11:18 PM, Wade Brainerd wad...@gmail.com wrote:
 
  2009/2/2 Tiago Marques tiago...@gmail.com
 
  On Thu, Jan 29, 2009 at 4:03 AM, Mitch Bradley w...@laptop.org wrote:
 
  Guess what? The people at OLPC, who aren't stupid, already considered
  every point in the message cited below, a long time ago. So why aren't
  we doing them? ...* *On Wed, Jan 28, 2009 at 9:57 PM, Carlos Nazareno
  object...@gmail.comwrote:
 
  Nobody's saying anyone is stupid. It is perfectly natural for people to
  complain about things they don't understand. I also wish I could, from
  time
  to time, to ask this or that, to understand many things I don't
  comprehend,
  to know what I can do to help. This without getting into any kind of
  fight
  with the people involved with the project, who are the only ones who
 can
  answer those questions.
  As with any critical comment I may issue in this mailing list,* please
  take it as something constructive*, to help (if it does, in any way)
 and
  not to criticize the people who are hard at work. That, I think, is
 what
  Carlos was trying to do.
  I got my XO three weeks ago and there's a lot I was surprised to learn
  that some of the more important features are WIP or simply don't work,
  especially given the news that I've read, already detailing prototypes
 of
  a
  second version, when there's still a lot to do with the first one.
 
 
  Hey Tiago,
 
  I've been following the project for about 2 years now and the software
  problems you cite (OOM crashing, flaky wireless,  battery life, sluggish
  UI)
  are pretty much the same ones that existed back when I got involved!
  The
  lack of momentum on the software front has been pretty amazing given how
  much the project started with.
 
  That said, things seem to be picking up speed as more control over the
  software is handed to the community.  I finally feel like there's maybe
 a
  chance to see some of this stuff get resolved.
 
  Here's hoping SL's XOOS or SoaS, or else some deployment's distribution
  will take better advantage of the excellent hardware that is the XO-1.
  I'd
  really like to see someone try to build a tiny LFS based XO specific
  distro
  which runs Sugar, and boots in 30sec :)  I've got my personal XO
 booting
  in
  around 45sec just by hacking around in the initscripts, and I'm sure a
 lot
  better could be done.
 
  Hi Wade,
  I use Gentoo for professional and personal use in almost all of my
 machines
  and will probably install Gentoo in some binary way to dual boot the XO
 with
  Sugar(it fits the XO too well, in some ways, to simply delete it). This
 will
  be the most optimized code I can have the compiler generate, which should
  yield some nice improvements, compiled with the smallest feature set
 needed.
  I have a machine running KDE 3.5 in 80MB with two or three KDE apps
 loaded,
  but that is still overkill for the XO. XFCE/Fluxbox would be something to
  experiment with.
  I have a server here in college to do a package server, with which other
  users may use, but I still need some free time to finish the basic gentoo
  based distro, which will hardly come with an installer, other than a
 stage
  package compiled for the Geode.
  I would like to see python less resource bound but I unfortunately have
  neither the time nor the skill to go hacking it.
  Best regards,
Tiago Marques
 
 
  Best,
  -Wade
 
 

 --
 Sent from my mobile device

 ~Nirbheek Chauhan

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-02 Thread C. Scott Ananian
2009/2/2 Wade Brainerd wad...@gmail.com:
 take better advantage of the excellent hardware that is the XO-1.  I'd
 really like to see someone try to build a tiny LFS based XO specific distro
 which runs Sugar, and boots in 30sec :)  I've got my personal XO booting in
 around 45sec just by hacking around in the initscripts, and I'm sure a lot
 better could be done.

Patches?
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-01-30 Thread Frank Ch. Eigler
Mitch Bradley w...@laptop.org writes:

 [...]  It's also worth pointing out that the new low-power x86
 processors, Atom being the poster child, are still stuck with
 power-hungry support chips - memory and display controllers.  That
 might change soon, but for now it's still the case.  [...]

According to the ACPI battery gauges under Fedora 10, my Fujitsu U820
UMPC (Atom Z530, Poulsbo GMA500 MCH/graphics) takes around 6W *total*
during light webby operations.

- FChE
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-01-30 Thread Samuel Klein
On Fri, Jan 30, 2009 at 9:18 AM, Frank Ch. Eigler f...@redhat.com wrote:
 Mitch Bradley w...@laptop.org writes:

 [...]  It's also worth pointing out that the new low-power x86
 processors, Atom being the poster child, are still stuck with
 power-hungry support chips - memory and display controllers.  That
 might change soon, but for now it's still the case.  [...]

 According to the ACPI battery gauges under Fedora 10, my Fujitsu U820
 UMPC (Atom Z530, Poulsbo GMA500 MCH/graphics) takes around 6W *total*
 during light webby operations.

What do those same gauges tell you about an XO under F10?

SJ
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-01-30 Thread pgf
samuel wrote:
  On Fri, Jan 30, 2009 at 9:18 AM, Frank Ch. Eigler f...@redhat.com wrote:
   Mitch Bradley w...@laptop.org writes:
  
   [...]  It's also worth pointing out that the new low-power x86
   processors, Atom being the poster child, are still stuck with
   power-hungry support chips - memory and display controllers.  That
   might change soon, but for now it's still the case.  [...]
  
   According to the ACPI battery gauges under Fedora 10, my Fujitsu U820
   UMPC (Atom Z530, Poulsbo GMA500 MCH/graphics) takes around 6W *total*
   during light webby operations.
  
  What do those same gauges tell you about an XO under F10?

unless things have changed, those same gauges won't exist on
the XO -- we don't do acpi.

paul
=-
 paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-01-30 Thread rihowa...@gmail.com
Those software gauges tell you what ever 'version of the truth' the  
author wants to tell you and make you feel happy about your device.
To perform power measurements reliably you need to instrument with a  
good quality physical voltmeter and ammeter.




On Jan 30, 2009, at 8:31 AM, p...@laptop.org wrote:

 samuel wrote:
 On Fri, Jan 30, 2009 at 9:18 AM, Frank Ch. Eigler  
 f...@redhat.com wrote:
 Mitch Bradley w...@laptop.org writes:

 [...]  It's also worth pointing out that the new low-power x86
 processors, Atom being the poster child, are still stuck with
 power-hungry support chips - memory and display controllers.  That
 might change soon, but for now it's still the case.  [...]

 According to the ACPI battery gauges under Fedora 10, my Fujitsu  
 U820
 UMPC (Atom Z530, Poulsbo GMA500 MCH/graphics) takes around 6W  
 *total*
 during light webby operations.

 What do those same gauges tell you about an XO under F10?

 unless things have changed, those same gauges won't exist on
 the XO -- we don't do acpi.

 paul
 =-
  paul fox, p...@laptop.org
 ___
 Devel mailing list
 Devel@lists.laptop.org
 http://lists.laptop.org/listinfo/devel

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-01-30 Thread Martin Langhoff
On Sat, Jan 31, 2009 at 3:18 AM, Frank Ch. Eigler f...@redhat.com wrote:
 Mitch Bradley w...@laptop.org writes:

 [...]  It's also worth pointing out that the new low-power x86
 processors, Atom being the poster child, are still stuck with
 power-hungry support chips - memory and display controllers.  That
 might change soon, but for now it's still the case.  [...]

 According to the ACPI battery gauges under Fedora 10, my Fujitsu U820
 UMPC (Atom Z530, Poulsbo GMA500 MCH/graphics) takes around 6W *total*
 during light webby operations.

Those aren't super accurate. However, what Mitch is talking about is
the fact that Intel has paired the low-power Atom with a chipset that
could only be described as powerhungry. AFAIK it draws roughly the
same as the Atom CPU at full blast but has no way to scale down or
sleep.

So when you're idling the cpu will go down into deep sleep modes and
save power, but the northbridge/southbridge have no concept of sleep.
That sucks [battery].

cheers,




m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel