[sugar] ejabberd now easier to install: debian ubuntu ship our patches
Just when I was going to build custom ejabberd packages, Jonas Smedegaard pointed out that Debian ships the required patches for enabling the shared roster, and they are therefore also in Ubuntu Intrepid (due to release in 6 days). I've written up the much simpler process of getting ejabberd up and running at http://wiki.laptop.org/go/Installing_ejabberd/deb. This will make it much easier to set up a school or community ejabberd server for collaboration, for those not using the XS images. Regards Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] 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 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Control Facility Improvements
While I dislike to add clutter, such buttons would make things more evident, a.k.a. intuitive / usable Now, genesee has a point, some of the activities are huge - how can the user make an informed decision? maybe adding the information on the size? (more clutter) Oh my, wouldn't it be nice the system intelligently assessed potential download time, and instead of announcing the size of the activity (a meningless number to our audience that supposedly is not mostly made up of geeks) it indicated the _time_ it would take to complete the operation, i.e., by each button, so I know that if I want to download all the updates, it might take me 15 minutes... , if I just want to update Chat, 30 seconds. That assessment could happen when the system is checking what updates are available. I _like_ that the journal now tells me how much memory I have available. Kudos to the implementor!!! Yama Maybe adding buttons for select all/deselect all and select installed would be better, to make managing the selection easier and more exposed, could work. Or, perhaps better, we could offer a smart activity pack in the list for Installed activities which then presents a list of all installed activities (checked by default, just like the other activity packs). - Eben On Thu, Oct 23, 2008 at 9:09 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Thu, Oct 23, 2008 at 9:07 PM, genesee [EMAIL PROTECTED] wrote One more? Software Updates defaults all available Activities pre-selected. Their boxes checked, in other words. I would rather choose the updates I want than de-select the ones I don't. Some of the Activity Groups are huge. It's a hassle clicking on the many not wanted to download a few. Right-click, unselect all. Voila! If only all our 9.1 features were already implemented. ;-) --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 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 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Greetings from New Hampsire
On Thu, Oct 23, 2008 at 3:25 PM, Brendan R. Powers [EMAIL PROTECTED]wrote: Greetings, Hey Brendan, Welcome to the list! Our company and developers are interested in getting involved with the development community for Sugar. We deploy Linux desktop solutions in schools in the United States via thin client and fat client methods. We believe that Sugar's collaboration tools, journal, and other features could be very appealing to younger grade (elementary and middle school) students and teachers. Several of our schools are interested in using Sugar in the classrooms already on their thin client desktops. Very cool, we are interested in making Sugar available to a wider audience! We have the Ubuntu packages running fine, but it is evident that there are changes that should be made to Sugar when its not being used on the OLPC. Some of the challenges for deploying Sugar on desktops in a school environment are different than using it on standalone OLPCs, which need to be overcome for Sugar to take a major foothold independent of the OLPC. Below we have listed some of the issues we think need to be addressed based on our experience with working in schools. What would be your preferred work flow? One thought would be set up a client/server git tree for client/server development. Then, the work you, and others do, can be pulled into the main tree. In the near future, SugarLabs will be hosting a git server. Either we can host a C/S tree or you can host it yourself. Do you use LTSP as the basis for your client server technology? The technical challenges we see are mostly problems integrating sugar into a thin client architecture, and into the networks of schools. One of the most immediate changes we will need to make are customizations to the interface. For example, thin clients may not need the shutdown and reboot options, and need a logout option. There are other customizations that we may need to make, such as adding or removing items from the control panel. These sorts of changes are small, and once done will allow people to deploy sugar in a small classroom environment. On larger installations, schools will want sugar to integrate with there existing file and print servers, as well as some centralized administration of the sugar interface. Ideally, the journal and datastore would be stored on the file server in such a way as to allow teachers to access the saved activities from a normal Windows or Linux computer. It would be interesting to see if we could launch sugar activities without running the entire sugar interface. Also, local media attached to thin client may pose a challenge, as the normal ways to search for and mount media are not available. Another important aspect of larger sugar deployments would be the ability of admins to customize the user interface. For example they may not want users to have access to the control panel, or may want to set up the list of activities per grade, and prevent users from installing there own activities. One of the most interesting aspects of sugar is its collaboration features, but this too poses some difficulties. In multi classroom environments its not clear how the collaboration would work. Ideally there would be one jabber server for the entire network. This would mean that every student on the network could see every other student on the network, when the desired behavior may be to only see the students in the current class. Using the Jabber server in a non-xs environment is a issue on which we are only just now starting to focus. We have a lot of work to do. These are some of the issues were thinking about. We could solve most of these problem by creating our own custom build of sugar with the patches needed to integrate with our current software. However, we would rather work with the community to create solutions to the problems. For example, one of the things we would like to do is to extend the profile class to allow for multiple back ends, as well as the ability to store generic settings. This would allow us to integrate some of the important profile settings, such as the jabber server, into our management software, while at the same time keeping a consistent API and keeping our code separate from the sugar tree. Thanks for you willingness to work with us! By Monday, Marco our lead developer will be able to answer you questions in more detail. thanks david We are very excited about the possibilities that sugar provides. We look forward to contributing to this project, and we are interested in your thoughts about these issues. --- Brendan Powers Resara LLC 1.888.357.9195 www.resara.com ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Some Engadget press
Some Engadget press: http://www.engadget.com/2008/10/24/confirmed-kids-like-sugar-better-than-xp/ --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
