debxo 0.2 release
Hi, I've prepared a new release of DebXO. This has a number of new features and desktops. NEW FEATURES: - The JFFS2 images now have partition support. While this shaves a number of seconds off of the boot time, we can take better advantage of it in the future (doing things like using UBIFS). JFFS2 is well past its prime; moving away from it will help performance a lot. - EXT3 images have been added. This allows for booting off of USB and/or SD. Note that the image size I chose is 2GB, so you'll need a USB stick or SD card of at least that size. - The kernel is now almost completely modular, and includes every module under the sun. For those of you with random USB hardware that wanted to use it with DebXO.. if it's in 2.6.25, it should work with DebXO. - New desktops! DebXO 0.1 only had a Gnome desktop; this release includes KDE, LXDE, Sugar, Awesome and Gnome desktops. I personally run (and work on) the Gnome desktop. Holger Levsen is to thank for the Sugar and Awesome desktops. James Cameron did the work for the KDE and LXDE desktops. A huge thanks to both of them! As far as bootup times, nand is still pretty absymal (due to jffs2); however, SD booting takes 75 seconds from OFW to fully usable X. INSTALLATION ONTO NAND FLASH: The release can be found here (note that the URL has changed): http://lunge.mit.edu/~dilinger/debxo-0.2/images/ To install onto the XO's flash, download the debxo-$DESKTOP.jffs2.dat and debxo-$DESKTOP.jffs2.img to a USB or SD stick (where $DESKTOP is one of the various desktops - gnome, kde, lxde, sugar, or awesome). Boot into OFW (make sure your XO is unlocked!), and run update-nand disk:\debxo-$DESKTOP.jffs2.img or update-nand sd:\debxo-$DESKTOP.jffs2.img (depending upon whether you downloaded to an SD or USB disk). If your SD or USB device is using a windows filesystem, you can figure out the name of the image by running dir disk:\ If update-nand spits out any errors, make sure you're running an appropriately up-to-date version of OFW. The q2d* series do not support update-nand, and versions q2e18 and q2e19 are known to be buggy with partitions. Firmware and instructions for upgrading can be found here: http://wiki.laptop.org/go/Firmware INSTALLATION ONTO SD/USB: To install onto an SD or USB device, download the debxo-$DESKTOP.ext3.img.gz file, and run zcat debxo-$DESKTOP.ext3.img.gz > /dev/mmcblk0 or zcat debxo-$DESKTOP.ext3.img.gz > /dev/sdX (depending upon whether you're writing to an SD or USB disk). Note that this will overwrite any data that is on the SD or USB disk. USAGE: By default, a user 'olpc' is created (with no password, and sudo access). Some desktops automatically start a display manager and log you in; some do not. The root password is disabled by default. This is a stock Debian Lenny system with only a few modifications, so it can obviously be tailored. HACKING: xodist is the name of the collection of scripts that are used to produce DebXO. The git repository can be downloaded via: git clone git://lunge.mit.edu/git/xodist There's also a web interface to that: http://lunge.mit.edu/cgi-bin/gitweb.cgi?p=xodist;a=summary There's a TODO file in the repository, but really... just scratch whatever itch you happen to have. Patches are much appreciated. Additional desktops (XFCE, for example?), better handling of the default user/password, boot/runtime optimizations, suggestions for missing packages, etc.. CREDITS: Thanks to James Cameron and Holger Levsen for various patches/tweaks/fixes, and to the various people who tested and provided feedback. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Community-news] Software developers needed for OLPC Afghanistan
On Fri, Oct 24, 2008 at 5:16 PM, Don <[EMAIL PROTECTED]> wrote: > > On Fri, 24 Oct 2008 16:09:21 -0700, "Edward Cherlin" > <[EMAIL PROTECTED]> said: >> On Mon, Oct 20, 2008 at 4:45 PM, Don <[EMAIL PROTECTED]> wrote: >> > I am interested Svetla. >> > I have lots of skills and I do also possess a bit of charm. >> > I am not religious but that does not mean that I am against religion. >> > Sadly my knowledge of >> > computers thus far are only windows based. I am a G1G1 and to be >> > frank, not a lover of microsoft. My trade is in construction... on >> > both the very high >> > ends and the very low. If you think there is a place there for one >> > such as me so as to perhaps >> > strengthen your credibility in that culture, please let me know. > >> Actually, it is not a matter of credibility. Decades of war destroyed >> much of the building stock and infrastructure and almost all industry, >> and the Taliban drove everybody competent from the country, down to >> the level of telephone installers. Although people have been >> returning, and there is a considerable amount of investment, >> Afghanistan needs people who can teach the skills for building, >> including math, engineering, design, skilled trades, finance, and >> sustainability. And the skills for teaching. > I am a a licenced builder in the state of michigan...USA, with decades > of experience in construction...and also being friendly to everyone > along the path of creativity. I have trained many young ones with my > knowledge over the years. I would like to help. > Who are you? > Don I am a volunteer with OLPC and Sugar Labs, and I run Earth Treasury. You can see a video I made about where the XO program can take us on my Wiki page (URL below). To see my names, you need to turn on Unicode support or use a Unicode-capable mailer, and install Chinese, Sanskrit Devanagari, and Arabic/Urdu fonts. I am working towards a microfinance project in Afghanistan, to supply looms and other art and craft tools and to supply Internet connectivity so that people can sell their works on eBay, Shopping.com, Overstock.com, and so on. My first work on OLPC Sugar software was in language support--keyboards, writing systems, fonts, and so on. I helped recruit translators for the less well supported languages of target countries. Now I watch for other things that need to be done, and go recruit people to do them. Village electricity and broadband Internet; microfinance; various kinds of software; educational content; redesign of textbooks to take advantage of the powerful collaborative software in Sugar; and more. -- Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://wiki.sugarlabs.org/go/User:Mokurai ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Power.
On Sat, 25 Oct 2008, Gary C Martin wrote: > Not sure if this helps the original feedback (that the sudden screen > dimming is annoying when trying to read), but the effect is at least > more pleasing than a sudden sharp drop in brightness. what I would really like to see is a reading mode, where the CPU goes to sleep fairly quickly (the faster the wake-up when a button is pressed the more quickly it can go to sleep), but the screen doesn't change. only if the system is idle for a long time (tens of min) should the cpu wake up and decide to dim/blank the screen. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Power.
On 24 Oct 2008, at 23:40, Richard A. Smith wrote: > Nate Ridderman wrote: > >> Do we have the ability to pulse width modulate the backlight LEDs? >> What >> is the resolution on the PWM? It's hard to know if this is feasible >> without a hardware schematic and specs on the backlight driver. The >> CL1 >> spec mentions a PWM signal, but maybe it only has four bits of >> resolution? > > The DCON drives a 200Hz PWM to the feeback loop of the DC/DC converter > that produces the LED's supply voltage. The lo-side driver > transistors > for each of the 3 LED chains (12 LEDS, 3 chains of 4) are not > connected > to anything you can PWM. > >>> I could be talking nonsense, and perhaps this would consume more >>power >>> than it saves, but if you were able to slowly dim the backlight over >>> the course of a minute or so, instead of waiting a minute and then >>> dropping it suddenly, we could prevent the sudden change which >>> causes >>> a break in concentration. (As long as the screen is bright enough >>> to >>> be usable when dim, of course.) > > It not possible to save power by doing this unless you ramped the > backlight down during the period when the CPU whould have normally > been > awake. The current scheme is already at its lowest it can be. Jump > to > the lowest setting and then put the cpu to sleep. Any deviation from > that will use more juice. If you wake up the CPU to do something you > have taken a large step backwards. I just tried some simple shell scripts stepping through the LED brightness to simulate a 15 to 7 drop, a pause and back again, also 15 to 1 cycle (think .1sec step seemed fair place to start). The effect seems to add a good touch of polish to a potential screen dimming cycle, if it's not too complicated to implement reliably for real. The steps between brightness values are certainly not linear to my eye (1-2 is a much larger step than 14-15), but used as a fade transition effect it didn't seem an issue. I also tried some rough PWM between 7 & 8, via the shell, but couldn't get anything that didn't make me feel nauseous after a few moments use. Not sure if this helps the original feedback (that the sudden screen dimming is annoying when trying to read), but the effect is at least more pleasing than a sudden sharp drop in brightness. --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Community-news] Software developers needed for OLPC Afghanistan
On Mon, Oct 20, 2008 at 4:45 PM, Don <[EMAIL PROTECTED]> wrote: > I am interested Svetla. > I have lots of skills and I do also possess a bit of charm. > I am not religious but that does not mean that I am against religion. > Sadly my knowledge of > computers thus far are only windows based. I am a G1G1 and to be > frank, not a lover of microsoft. My trade is in construction... on > both the very high > ends and the very low. If you think there is a place there for one > such as me so as to perhaps > strengthen your credibility in that culture, please let me know. Actually, it is not a matter of credibility. Decades of war destroyed much of the building stock and infrastructure and almost all industry, and the Taliban drove everybody competent from the country, down to the level of telephone installers. Although people have been returning, and there is a considerable amount of investment, Afghanistan needs people who can teach the skills for building, including math, engineering, design, skilled trades, finance, and sustainability. And the skills for teaching. > Don Czapski -- Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://wiki.sugarlabs.org/go/User:Mokurai ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
On 25/10/08 00:48 +0200, NoiseEHC wrote: > Could you be a bit more specific, please? What did you mean when you > talked about that moving a little bit more of the driver to kernel level > would not help? (This was the mentioned thread I had with Bernie.) I'm not exactly which part you want more specifics for. The code is available - it would be easier if you perused it and asked more direct questions. Jordan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
Could you be a bit more specific, please? What did you mean when you talked about that moving a little bit more of the driver to kernel level would not help? (This was the mentioned thread I had with Bernie.) Also could somebody enlighten me why we does not use DirectFB? Is it because of there are not enough developers or because it is not technically sound? Jordan Crouse wrote: > On 25/10/08 00:00 +0200, NoiseEHC wrote: > >> The Geode X drive copyes every bit of data to the command ring buffer by >> using the CPU so that is sure that those "almost no CPU cycles" thing is >> at least a bit stretch... :) According to Jordan Crouse it will not be >> better but he was not too concrete so in the end I am not sure what he >> was really talking about, see: >> http://lists.laptop.org/pipermail/devel/2008-May/014797.html >> > > Indeed - many CPU cycles are used during compositing. There is a lot of > math that happens to generate the masks and other collateral to render > the alpha icon on the screen. The performance savings in the composite > code comes from not having to read video memory to get the src pixel > for the alpha operation(s). That performance savings is already available > in the X driver today. > > Jordan > > >> Benjamin M. Schwartz wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> Erik Garrison wrote: >>> >>> What about changing the kind of visual feedback we give. Instead of pulsing icons what about icons with a string of dots beneath, a progress bar, flashing, or another kind of overlay feedback which requires fewer visual changes (frames) and/or could be overlaid on top of existing icons without calculating a new animation for every icon? >>> We have GPU-accelerated alpha compositing on the XO, so we could do the >>> current animation using almost no CPU cycles. It's just a question of >>> figuring out how to access that compositing. As far as I'm aware, no >>> effort in this direction has been made. I don't know if "composite" here >>> requires the use of "Composite" in the window manager or not; my knowledge >>> of X is minimal. >>> >>> - --Ben >>> -BEGIN PGP SIGNATURE- >>> Version: GnuPG v2.0.9 (GNU/Linux) >>> >>> iEYEARECAAYFAkkCPQAACgkQUJT6e6HFtqSlSwCfVrZfVFFUqbwgBuLJCckGmHDc >>> S40An2vtXMot6/rz9YmceB38geDaQhH4 >>> =aOse >>> -END PGP SIGNATURE- >>> ___ >>> 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 >> >> > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Power.
Nate Ridderman wrote: > Do we have the ability to pulse width modulate the backlight LEDs? What > is the resolution on the PWM? It's hard to know if this is feasible > without a hardware schematic and specs on the backlight driver. The CL1 > spec mentions a PWM signal, but maybe it only has four bits of resolution? The DCON drives a 200Hz PWM to the feeback loop of the DC/DC converter that produces the LED's supply voltage. The lo-side driver transistors for each of the 3 LED chains (12 LEDS, 3 chains of 4) are not connected to anything you can PWM. > > I could be talking nonsense, and perhaps this would consume more > power > > than it saves, but if you were able to slowly dim the backlight over > > the course of a minute or so, instead of waiting a minute and then > > dropping it suddenly, we could prevent the sudden change which causes > > a break in concentration. (As long as the screen is bright enough to > > be usable when dim, of course.) It not possible to save power by doing this unless you ramped the backlight down during the period when the CPU whould have normally been awake. The current scheme is already at its lowest it can be. Jump to the lowest setting and then put the cpu to sleep. Any deviation from that will use more juice. If you wake up the CPU to do something you have taken a large step backwards. -- Richard Smith <[EMAIL PROTECTED]> One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
On 25/10/08 00:00 +0200, NoiseEHC wrote: > The Geode X drive copyes every bit of data to the command ring buffer by > using the CPU so that is sure that those "almost no CPU cycles" thing is > at least a bit stretch... :) According to Jordan Crouse it will not be > better but he was not too concrete so in the end I am not sure what he > was really talking about, see: > http://lists.laptop.org/pipermail/devel/2008-May/014797.html Indeed - many CPU cycles are used during compositing. There is a lot of math that happens to generate the masks and other collateral to render the alpha icon on the screen. The performance savings in the composite code comes from not having to read video memory to get the src pixel for the alpha operation(s). That performance savings is already available in the X driver today. Jordan > Benjamin M. Schwartz wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Erik Garrison wrote: > > > >> What about changing the kind of visual feedback we give. Instead of > >> pulsing icons what about icons with a string of dots beneath, a progress > >> bar, flashing, or another kind of overlay feedback which requires fewer > >> visual changes (frames) and/or could be overlaid on top of existing > >> icons without calculating a new animation for every icon? > >> > > > > We have GPU-accelerated alpha compositing on the XO, so we could do the > > current animation using almost no CPU cycles. It's just a question of > > figuring out how to access that compositing. As far as I'm aware, no > > effort in this direction has been made. I don't know if "composite" here > > requires the use of "Composite" in the window manager or not; my knowledge > > of X is minimal. > > > > - --Ben > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v2.0.9 (GNU/Linux) > > > > iEYEARECAAYFAkkCPQAACgkQUJT6e6HFtqSlSwCfVrZfVFFUqbwgBuLJCckGmHDc > > S40An2vtXMot6/rz9YmceB38geDaQhH4 > > =aOse > > -END PGP SIGNATURE- > > ___ > > 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 > -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cannot edit Trac tickets
Appears to be fixed now. - Bert - Am 24.10.2008 um 21:42 schrieb Eben Eliason: > Attached. > > - Eben > > > On Fri, Oct 24, 2008 at 3:36 PM, Noah Kantrowitz > <[EMAIL PROTECTED]> wrote: >> Can someone send me a copy of dev.laptop.org/condfields/new.js from a >> machine that is grumpy? >> >> --Noah >> >>> -Original Message- >>> From: Chris Ball [mailto:[EMAIL PROTECTED] >>> Sent: Friday, October 24, 2008 12:11 PM >>> To: Noah Kantrowitz >>> Cc: Bert Freudenberg; OLPC Devel >>> Subject: Re: Cannot edit Trac tickets >>> >>> Hi Noah, >>> Can't reproduce on 3.1.2/Leopard. Please make sure to clear your >>> web cache if you have one, the JS file that does the monkeying might >>> have been cached while it was still b0rked yesterday. >>> >>> Hm, we just saw this on Firefox at the office -- clearing web cache >>> and restarting Firefox doesn't help, and milestone/version fields >>> are >>> duplicated on http://dev.laptop.org/newticket . Still can't >>> reproduce >>> on my own machine for some reason.. >>> >>> Thanks, >>> >>> - Chris. >>> -- >>> Chris Ball <[EMAIL PROTECTED]> >> >> ___ >> 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
The Geode X drive copyes every bit of data to the command ring buffer by using the CPU so that is sure that those "almost no CPU cycles" thing is at least a bit stretch... :) According to Jordan Crouse it will not be better but he was not too concrete so in the end I am not sure what he was really talking about, see: http://lists.laptop.org/pipermail/devel/2008-May/014797.html Benjamin M. Schwartz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Erik Garrison wrote: > >> What about changing the kind of visual feedback we give. Instead of >> pulsing icons what about icons with a string of dots beneath, a progress >> bar, flashing, or another kind of overlay feedback which requires fewer >> visual changes (frames) and/or could be overlaid on top of existing >> icons without calculating a new animation for every icon? >> > > We have GPU-accelerated alpha compositing on the XO, so we could do the > current animation using almost no CPU cycles. It's just a question of > figuring out how to access that compositing. As far as I'm aware, no > effort in this direction has been made. I don't know if "composite" here > requires the use of "Composite" in the window manager or not; my knowledge > of X is minimal. > > - --Ben > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.9 (GNU/Linux) > > iEYEARECAAYFAkkCPQAACgkQUJT6e6HFtqSlSwCfVrZfVFFUqbwgBuLJCckGmHDc > S40An2vtXMot6/rz9YmceB38geDaQhH4 > =aOse > -END PGP SIGNATURE- > ___ > 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: 9.1 Proposal: Top five performance problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Garrison wrote: > What about changing the kind of visual feedback we give. Instead of > pulsing icons what about icons with a string of dots beneath, a progress > bar, flashing, or another kind of overlay feedback which requires fewer > visual changes (frames) and/or could be overlaid on top of existing > icons without calculating a new animation for every icon? We have GPU-accelerated alpha compositing on the XO, so we could do the current animation using almost no CPU cycles. It's just a question of figuring out how to access that compositing. As far as I'm aware, no effort in this direction has been made. I don't know if "composite" here requires the use of "Composite" in the window manager or not; my knowledge of X is minimal. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkCPQAACgkQUJT6e6HFtqSlSwCfVrZfVFFUqbwgBuLJCckGmHDc S40An2vtXMot6/rz9YmceB38geDaQhH4 =aOse -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
Michael Stone wrote: > I did some basic profiling of my new rainbow code last night and > discovered that, in the best case with the current codebase on XO, it > costs about 0.5s/"1 exec(python)". Approximately 80% of the 0.5s was > spent importing modules. > > I hope to dig deeper in the near future, but I am concerned at my lack > of inspiration about how to deal with this problem. (Other than by > rewriting into a different language.) I still do not consider the > mod_python approach used in the 767-era rainbow to be a viable long-term > solution. > Well, there is a tedious solution that would probably be effective. Go through the list of modules with a fine-toothed comb and find out what is actually used from each module. I'll bet that there are quite a few modules from which only a few simple functions are used. Collecting those functions into one lightweight (no unnecessary stuff) module might collapse the dependency graph. As I said, this can be tedious, but it's the sort of think I've done many times during my career, and it has usually paid off. If nothing else, you end up learning a lot about how things work, which tends to make you eventually become fearless. Hah! I know how that works, and it's not nearly as complicated as you think! A lot of complexity ends up being solutions to low-value problems that don't apply in your case. As a case in point, a long time ago I needed to incorporate a stripped-down stdio package in some app that needed to be tiny. The basic character I/O ended up pulling in a train load of networking libraries. It turned out that "isatty()" was the culprit - it had to check whether the file descriptor matched every conceivable kind of I/O object. I just made a stub version of isatty() and all the spurious dependencies disappeared. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
On Fri, Oct 24, 2008 at 01:56:47AM +0200, Marco Pesenti Gritti wrote: > Problems and ideas in no particular order. > > * Sugar shell startup is too slow. > > Reduce dependencies, single process shell, modularize and delay > initialization of components which are not immediately necessary, > measure constantly to avoid regressions and monitor progress. > > * Icons rendering is slow and uses too much memory. > > Cache svg icon on disk pre-rendered and mmap them, render colored > icons using a mask per color, user server side pixmaps to speed up > rendering of some of the icons. > What about changing the kind of visual feedback we give. Instead of pulsing icons what about icons with a string of dots beneath, a progress bar, flashing, or another kind of overlay feedback which requires fewer visual changes (frames) and/or could be overlaid on top of existing icons without calculating a new animation for every icon? Just thoughts. > * The frame is too slow to appear and disappear. > > Experiment with pixmap caching. Is an empty frame fast enough? > Composite the active window and the frame. What about just turning on X Composite for everything? From the user's perspective this wholly resolves a lot of issues associated with rendering performance. From a programmer-resources perspective it's also quite straightforward. The problem is that we have fallout in terms of memory allocation, at a cost of about 2mb per activity window. That said, switching between activities is *instantaneous*. More problematically I see no clever algorithm to figure out where a user is going to go in the activity stack next, which might help us choose which windows to unmap. Could we discuss this during the talk? Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cannot edit Trac tickets
Attached. - Eben On Fri, Oct 24, 2008 at 3:36 PM, Noah Kantrowitz <[EMAIL PROTECTED]> wrote: > Can someone send me a copy of dev.laptop.org/condfields/new.js from a > machine that is grumpy? > > --Noah > >> -Original Message- >> From: Chris Ball [mailto:[EMAIL PROTECTED] >> Sent: Friday, October 24, 2008 12:11 PM >> To: Noah Kantrowitz >> Cc: Bert Freudenberg; OLPC Devel >> Subject: Re: Cannot edit Trac tickets >> >> Hi Noah, >> >>> Can't reproduce on 3.1.2/Leopard. Please make sure to clear your >> web >>> cache if you have one, the JS file that does the monkeying might >> have >>> been cached while it was still b0rked yesterday. >> >> Hm, we just saw this on Firefox at the office -- clearing web cache >> and restarting Firefox doesn't help, and milestone/version fields are >> duplicated on http://dev.laptop.org/newticket . Still can't reproduce >> on my own machine for some reason.. >> >> Thanks, >> >> - Chris. >> -- >> Chris Ball <[EMAIL PROTECTED]> > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > new.js Description: JavaScript source ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: Cannot edit Trac tickets
Can someone send me a copy of dev.laptop.org/condfields/new.js from a machine that is grumpy? --Noah > -Original Message- > From: Chris Ball [mailto:[EMAIL PROTECTED] > Sent: Friday, October 24, 2008 12:11 PM > To: Noah Kantrowitz > Cc: Bert Freudenberg; OLPC Devel > Subject: Re: Cannot edit Trac tickets > > Hi Noah, > >> Can't reproduce on 3.1.2/Leopard. Please make sure to clear your > web >> cache if you have one, the JS file that does the monkeying might > have >> been cached while it was still b0rked yesterday. > > Hm, we just saw this on Firefox at the office -- clearing web cache > and restarting Firefox doesn't help, and milestone/version fields are > duplicated on http://dev.laptop.org/newticket . Still can't reproduce > on my own machine for some reason.. > > Thanks, > > - Chris. > -- > Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cannot edit Trac tickets
I, too, am seeing this on 10.5.5 Leopard with both 3.1.2 Safari and 3.0.1 Firefox. - Eben On Fri, Oct 24, 2008 at 3:11 PM, Chris Ball <[EMAIL PROTECTED]> wrote: > Hi Noah, > > > Can't reproduce on 3.1.2/Leopard. Please make sure to clear your web > > cache if you have one, the JS file that does the monkeying might have > > been cached while it was still b0rked yesterday. > > Hm, we just saw this on Firefox at the office -- clearing web cache > and restarting Firefox doesn't help, and milestone/version fields are > duplicated on http://dev.laptop.org/newticket . Still can't reproduce > on my own machine for some reason.. > > Thanks, > > - Chris. > -- > Chris Ball <[EMAIL PROTECTED]> > ___ > 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: Cannot edit Trac tickets
Hi Noah, > Can't reproduce on 3.1.2/Leopard. Please make sure to clear your web > cache if you have one, the JS file that does the monkeying might have > been cached while it was still b0rked yesterday. Hm, we just saw this on Firefox at the office -- clearing web cache and restarting Firefox doesn't help, and milestone/version fields are duplicated on http://dev.laptop.org/newticket . Still can't reproduce on my own machine for some reason.. Thanks, - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] DanGuardian and XS Plans
I haven't been keeping up with this list as well as I should have, but I just noticed some discussion regarding internet filtering in Birmingham. At our XS testbed school, Glen Iris, when I set up the 0.4 box, I edited /etc/named.conf and /etc/named.conf.in to use the OpenDNS IPs. SInce the DSL connection there has a static IP, it was really easy to set up on the OpenDNS site. It is CIPA compliant and a lot of other schools and libraries use it, we figure we're safe as far as internet filtering goes. Per the administrators' request, I set the filter on "high" which means it blocks "timewasters" - pretty much everything fun like myspace and even gmail. I haven't gotten any requests to whitelist anything yet. As far as when the XOs are away from the school, I installed the Foxfilter plugin for FF3, which is the best I could think of. It's certainly not perfect, but it's better than nothing. Part of the parent's "contract" is to monitor their children's internet usage, anyway. So, unless there's a better option, we're going to plan on using OpenDNS on the XS's here. Anna Schoolfield Birmingham ___ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] xs-otp: one time passwords for the XS
On Fri, Oct 24, 2008 at 07:02:23PM +1300, Douglas Bagnall wrote: >2. If you want to disable root login via the system password, touch > /etc/xs-otp/disable-root-password. This file will eventually exist > by default, but for now this option should be used with care. It > *could* leave you with no way of logging into the server. Do the XS installation instructions offer any guidance on prohibiting booting with init=/bin/bash, booting from external media, or simply removing the XS hard drive and manipulating it from a separate machine? >By default xs-otp generates 520 8-character passwords containing a >mixture of letters, numbers and some punctuation. The passwords are >saved in an ordered list, like this: How many bits of entropy per password? (All the examples you showed were printable ASCII so I assume that there are less than 64 bits of entropy per password.) Regards, Michael P.S. - Interesting work; congrats on getting this far. ___ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] pam-sotp rpm package
Douglas Bagnall wrote: > hi Rahul, server-devel, > > I've made a new pam_sotp RPM, which differs only in that it is > compiled with CFLAGS="-fno-stack-protector". I made this change > because the original was causing errors like this: > > PAM unable to dlopen(/lib/security/pam_sotp.so): \ > /lib/security/pam_sotp.so: undefined symbol: __stack_chk_fail_local > > It makes me nervous to be turning off stack smashing checks on pam > modules, notwithstanding that this error seems to be caused by gcc > incompatibilities (-fstack-protector is newish) rather than any actual > deficiency. > > Does anyone have a better patch or understanding of the cause? In > similar looking cases Google suggests linking using gcc rather than > ld, but my rpm-fu is too weak to cause that. I suggest posting to fedora-devel list and asking for help. Turning off security features makes you worry and quite rightfully so and it is not allowed by the Fedora packaging guidelines anyway. I offered to be a package monkey only to help OLPC and have no particular insight into the code to help you further. Rahul ___ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-devel
Re: 9.1 Proposal: Top five performance problems
On Fri, Oct 24, 2008 at 7:04 PM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote: > On Fri, Oct 24, 2008 at 10:10 PM, Michael Stone <[EMAIL PROTECTED]> wrote: >> Marco, >> >> I did some basic profiling of my new rainbow code last night and >> discovered that, in the best case with the current codebase on XO, it >> costs about 0.5s/"1 exec(python)". Approximately 80% of the 0.5s was >> spent importing modules. >> >> I hope to dig deeper in the near future, but I am concerned at my lack >> of inspiration about how to deal with this problem. (Other than by >> rewriting into a different language.) I still do not consider the >> mod_python approach used in the 767-era rainbow to be a viable long-term >> solution. >> > > FWIW, I had done some experiments with Federico's profiling scripts in > the early stages of the 8.2 cycle, and had got similar results: > http://dev.laptop.org/~sayamindu/not_so_prettygraph.png > It's not much meaningful, but if it helps in any way.. :-) > -sdg- Hmm, just did some measurements on a recent joyride image running a recent snapshot of sugar's HEAD and got this numbers: 1224870285 Roughly when ck-xinit-session would be called 1224870288.762430 DEBUG root: STARTUP: Starting the shell 1224870297.765248 DEBUG root: STARTUP: Loading the desktop window 1224870297.777485 DEBUG root: STARTUP: Loading the home view 1224870297.780084 DEBUG root: STARTUP: Loading the favorites view 1224870297.793263 DEBUG root: STARTUP: Loading the activities list 1224870298.559094 DEBUG root: STARTUP: Loading the group view 1224870298.631829 DEBUG root: STARTUP: Loading the mesh view 1224870299.444656 DEBUG root: STARTUP: Loading the bundle registry 1224870301.935619 DEBUG root: STARTUP: --- uisetup_completed_cb --- 1224870301.979451 DEBUG root: STARTUP: --- uisetup_delayed_cb --- 1224870303.197090 DEBUG root: STARTUP: Loading the frame 1224870305.001450 DEBUG root: STARTUP: Loading the journal So that's 20 seconds that can (quite roughly) be compared to the 72 seconds you got. I don't think we really got a 52 seconds improvement, but I'm pretty sure that Sugar already got quite leaner (measured 15MB of mem less after booting) and faster and there's still plenty of room for improvement. Cannot wait to have F10 joyride images to compare 8.2 to something closer to what will ship in 9.1 ;) Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
On Fri, 24 Oct 2008, Michael Stone wrote: > Marco, > > I did some basic profiling of my new rainbow code last night and > discovered that, in the best case with the current codebase on XO, it > costs about 0.5s/"1 exec(python)". Approximately 80% of the 0.5s was > spent importing modules. a silly thought, on C++ systems I've seen programs have high overhead in starting when they used too many shared libraries, and greatly reducing the penalty by combining many libraries into one. does python have the same situation? would it make any sense at all to combine the common, required libraries togeather into one? David Lang > I hope to dig deeper in the near future, but I am concerned at my lack > of inspiration about how to deal with this problem. (Other than by > rewriting into a different language.) I still do not consider the > mod_python approach used in the 767-era rainbow to be a viable long-term > solution. > > Michael > > P.S. - Your talk outline looks great! > ___ > 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: 9.1 Proposal: Top five performance problems
On Fri, Oct 24, 2008 at 10:10 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > Marco, > > I did some basic profiling of my new rainbow code last night and > discovered that, in the best case with the current codebase on XO, it > costs about 0.5s/"1 exec(python)". Approximately 80% of the 0.5s was > spent importing modules. > > I hope to dig deeper in the near future, but I am concerned at my lack > of inspiration about how to deal with this problem. (Other than by > rewriting into a different language.) I still do not consider the > mod_python approach used in the 767-era rainbow to be a viable long-term > solution. > FWIW, I had done some experiments with Federico's profiling scripts in the early stages of the 8.2 cycle, and had got similar results: http://dev.laptop.org/~sayamindu/not_so_prettygraph.png It's not much meaningful, but if it helps in any way.. :-) -sdg- -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cannot edit Trac tickets
On Oct 24, 2008, at 8:25 AM, Bert Freudenberg wrote: > > Am 24.10.2008 um 17:06 schrieb Chris Ball: > >> Hi Bert, >> >>> ... because it displays Milestone, Component, Version, and Keywords >>> entry fields twice: >> >>> and then reports a Trac Error: "Multi-values fields not supported >>> yet" >> >> Which browser are you using, and do you have Javascript turned on? > > Safari, and yes. Can't reproduce on 3.1.2/Leopard. Please make sure to clear your web cache if you have one, the JS file that does the monkeying might have been cached while it was still b0rked yesterday. --Noah ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
Marco, I did some basic profiling of my new rainbow code last night and discovered that, in the best case with the current codebase on XO, it costs about 0.5s/"1 exec(python)". Approximately 80% of the 0.5s was spent importing modules. I hope to dig deeper in the near future, but I am concerned at my lack of inspiration about how to deal with this problem. (Other than by rewriting into a different language.) I still do not consider the mod_python approach used in the 767-era rainbow to be a viable long-term solution. Michael P.S. - Your talk outline looks great! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Firefox/Xulrunner memory related crashes
Hello, I spent some time looking into the various tickets about oom and BadAlloc crashes in trac today. Here is a summary of the problems. A) There is a bug in cairo which causes BadAlloc on very big images. Fixes are in 1.8 and should be possible to backport to 1.6.4. B) Xulrunner renders images in a cache, normally on the server side, but there is an environment variable to cache them on the client side, for 15 seconds. In the case of pages like http://wiki.laptop.org/go/Measure, the uncompressed images can take up to 150mb, which quickly kill the XO. There are two possibilities to alleviate the problem: 1) Reduce the cache life, most likely based on images size. Very easy to patch xulrunner to change the timer, but it's probably not going to completely fix the problem. Memory will fill up anyway in some cases, we just decrease the likeliness that it will happen. http://mxr.mozilla.org/mozilla-central/source/modules/libpr0n/src/imgContainer.cpp#1209 2) nsThebesImage has recently gained low memory detection. It will refuse to create the image if memory is low. Unfortunately it's implemented only on some platforms, not including linux. Can a kernel hacker land me hand there and suggest an implementation for it? NS_OSSO (meamo) uses /sys/kernel/high_watermark, but I suspect that's a maemo kernel patch? http://mxr.mozilla.org/mozilla-central/source/xpcom/base/nsMemoryImpl.cpp#187 --- Fixing any of these problems would require system changes and hence 8.2.1. A) will get fixed for free when we upgrade to Fedora 10. For B), if I get some help by kernel developers, I'd like to get a fix in joyride and see how much it helps, then we can decide about including it in 8.2.1 or not. >From a user point of view I think B is happening much more often then A, hence I think it's worth to get do a 8.2.1 for this only if we manage to solve B. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cannot edit Trac tickets
On Fri, Oct 24, 2008 at 05:25:03PM +0200, Bert Freudenberg wrote: > > Am 24.10.2008 um 17:06 schrieb Chris Ball: > > I can't reproduce this here, but we did make a change yesterday > > that's probably responsible. > > Someone else on IRC reported seeing it, too. That's me... ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cannot edit Trac tickets
Am 24.10.2008 um 17:06 schrieb Chris Ball: > Hi Bert, > >> ... because it displays Milestone, Component, Version, and Keywords >> entry fields twice: > >> and then reports a Trac Error: "Multi-values fields not supported >> yet" > > Which browser are you using, and do you have Javascript turned on? Safari, and yes. > (And, do you see the same problem if you use a different browser?) Same in Firefox and Opera (on latest Mac OS X) > I can't reproduce this here, but we did make a change yesterday > that's probably responsible. Someone else on IRC reported seeing it, too. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cannot edit Trac tickets
Hi Bert, > ... because it displays Milestone, Component, Version, and Keywords > entry fields twice: > and then reports a Trac Error: "Multi-values fields not supported > yet" Which browser are you using, and do you have Javascript turned on? (And, do you see the same problem if you use a different browser?) I can't reproduce this here, but we did make a change yesterday that's probably responsible. - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Server-devel] ejabberd shared roster config
I've been playing around with setting up ejabberd seeing that Debian and Intrepid ship with the shared roster patches: http://wiki.laptop.org/go/Installing_ejabberd/deb I managed to hack up the shared roster with a minimum of things that could go wrong, by using: sudo ejabberdctl srg-create Online your.host.name Online "Online users" Online sudo ejabberdctl srg-user-add @online "" Online your.host.name This doesn't work immediately as it creates "@online" @ nothing instead of "@online@" - but it does populate @online@ into the web interface, so you just need to log in and submit the form with no changes under shared roster groups. Then it correctly sets @[EMAIL PROTECTED] Anyone have a simpler way to do this? Regards Morgan ___ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-devel
Anyone set up a client/server application using stream tubes?
Hi All, I'm trying to document some more stuff related to Stream Tubes for the sugar almanac (http://wiki.laptop.org/go/Sugar_Almanac) and wanted to set up some examples related to the different types of client/server arrangments that can be supported by the sugar.network package. However, I've been having some trouble getting a client/server application up an running on a stream tube through threading. Has anyone else tried this and could you point me to some example code? One example of what I would like to be able to do: create a continuously running http server on one XO that can send files to requests from a client XO. I have created a server that can do this once, but when I try to get it to repeatedly listen for client requests, I am not able to get things working. Any help would be greatly appreciated! Faisal ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
On Fri, Oct 24, 2008 at 2:05 AM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > On Fri, Oct 24, 2008 at 1:56 AM, Marco Pesenti Gritti > <[EMAIL PROTECTED]> wrote: >> * Activity startup is ridiculously slow. >> >> Design an API incompatible Activity class. Start from a very basic >> window and add functionalities on the top of it, trying to not regress >> startup time. Make sure that launcher feedback does not slow down >> startup. > > A discussion about preloading and lazy loading approaches to the slow > module imports problems would also be interesting. pylauncher VS > gobject-introspection? both? Well, gobject-introspection will reduce the amount of work done in pygobject-derived bindings, but those aren't the biggest issue. Also, preloading in pylauncher helps us share memory between processes that otherwise would be duplicated in each python activity. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
