Re: OLPC upgrades
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/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
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
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
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
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
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
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
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)
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)
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/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
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
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
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)
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)
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/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
Fwd: OLPC upgrades
-- Forwarded message -- From: Tiago Marques tiago...@gmail.com Date: Sat, Feb 7, 2009 at 1:46 AM Subject: Re: OLPC upgrades To: da...@lang.hm 2009/2/3 da...@lang.hm 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. Ok. Guess I'll have to glue something in mine, so I have some sort of feedback. 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 I have some problems with automatic power management, which I've reported in tracker. Your measurements seem encouraging, I must say. Have toy with this some more then. 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 Best regards, Tiago Marques ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC upgrades
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
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
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
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
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/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
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
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
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
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
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
-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
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
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
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
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
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/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
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
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
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/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
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
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
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
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
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
OLPC upgrades
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: where entire servers would melt down because of the sheer number of geeks a link to the front page of slashdot.org would bring. foru simple words can save the entirety of OLPC and the AMD, and in fact make both filthy rich, rich enough to execute our insane kumbaya vision. military grade hacker toy I've been in the computer industry for over 25 years and I have seen very, very few hacker-oriented products succeed at any significant scale. The problem with selling to hackers is that they all want something different, and they want shiny and new, so you can't get enough volume of one product to get to economy of scale. And with a hacker product, you *never* get a large single order or a predictable continuing business stream, so planning future production is virtually impossible. See below about the importance of that. say those four magic words, sell the XO via geek online stores, and 1CC will be so slashdotted to high heck with orders that the waiting list will take years to fill out. ... which is pretty much the classic way to go out of business. If you can't fulfill orders in a timely fashion, the customers will get mad and cancel the orders and badmouth you to death. To fill orders in a timely fashion, you have to build up stock in advance, which means that you have to buy parts in advance (lead times can be months), which means you either have to pay in advance or convince the suppliers to bet on you, which is very hard because the suppliers that are still in business have learned the hard way that extending credit to unproven companies is a very good way to stop being in business. If you guess high and order too much, you can lose money even if you have sold a lot of product. If you guess low, you get into the unfilled orders / unhappy customers problem, so you have to do something heroic to get the production up quickly, which usually means you end up paying more for parts and services. In many cases, there can be a 9 month delay between when you have to commit the money for the parts and the time you actually get paid. Multiply that times a lot of units, and you are looking at a lot of money at risk for a very uncertain future return. At similar price points, the XO-1 puts the Nintendo DS, Tapwave Zodiac, GP2X, Sony PSP, Chumby and iPods + iPhones to shame. Huh? Nintendo and PSP are game machines backed by long lists of titles, with well-established companies that have put lots of effort into creating products that appeal to a specific market, and a long history of many other companies that got it wrong and died. iPods are, or were, a fashion statement. You're not likely to see anybody jogging with an XO dangling from their neck or strapped to their arm. iPhone is the current fashion statement, and it is associated with a valuable service called a telephone network. You can't whip an XO out of your pocket and call Billy Bob. Comparing XO to these products is meaningless, except insofar as the iPhone / PDA products are starting to become capable enough to subsume a lot of computer functions. The XO-1 isn't a credible substitute for a phone at all. Support? real men don't need no steeenkin manuals or directions! just ship em in a plain cardboard box with a power adaptor and all will be good to go! You might be surprised at the amount of time I have spent answering questions from hackers. In the sort of open development and communications environment that we have, hackers know how to contact you. In some cases, the interaction with them has been quite valuable, but the don't need no support notion is just not what happens. Start selling current batches of 1GB Nand 256MB RAM. These are collector's items and will increase in value. Move out all existing stocks, and then fix fab to ship next version with 512MB RAM + 4-8GB NAND. Moore's law and Windows Vista have brought down the price of memory to dirt-cheap levels. As Tiago pointed out, the Geode is designed for DDR1 memory, which is not only off the leading price / technology curve, but is in the realm of you have to make special arrangements to secure a reliable supply. There may be ways to adapt Geode to use DDR2 memory, but it's not a slam dunk. You can't just do a simple board relayout and be good to go. At the very least you would have to design and debug and production-qualify some sort of outboard interface chip, and redo all the memory integrity tests. Do you have any idea how critical memory interface signal integrity is these days? On the NAND front, the new generation of high-capacity NAND has moved to MLC (multi-level cell) designs, which have much smaller noise
