New XO-LiveCD Release 080607
A new release 080607 of the Livebackup XO-LiveCD is available at: http://dev.laptop.org/pub/livebackupcd/build-708+joyride-2024 and mirrored in Germany at ftp://rohrmoser-engineering.de/pub/XO-LiveCD/ Main features and changes since version 080321: * Dual boot option for update.1 and joyride builds, You can try out the new SUGAR design by booting a recent OLPC joyride version. * Improved CD customization. Additional activities and RPM packages can be installed by putting them into CD top-level directories. * A new script to prepare USB boot devices out of the Live-ISO image. * Tested on a wide range of PC and laptop hardware and proved to work with all common virtual machines on Windows, MacOS and Linux. * Additional Xorg graphic drivers and improved X11 auto-configuration tools. * Bug fixes, updates and new activities. * Linux kernel 2.6.24.7, using the aufs-filesystem. This Live-CD project targets the main goals: * Give children, students, teachers and parents the opportunity to participate and use the educational software on a common PC. * Demonstration of OLPC/Sugar software to non-developers, you can also start the sugar desktop on Windows, Linux or MacOS using a Virtual Machine. * For developers the CD provides an easy maintainable Live-System, which could be used to develop and test activities on the sugar desktop. Further information is available in the PDF document: ftp://rohrmoser-engineering.de/pub/XO-LiveCD/XO-LiveCD_080607.pdf For discussion we invite you to join the mailing list: http://lists.laptop.org/listinfo/livebackup-xo-cd Regards Wolfgang Rohrmoser ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Flash is too full
I have an XO-1 that has stopped booting correctly after I tried to install some large activities from a flash drive. I cannot make a clean install because it has firmware security enabled and I am unable to interrupt the boot without the developer key, which I don't have. I can't create one because it doesn't boot. On boot, the normal screen is an XO symbol, which then spins 360 degrees tracing out a circle of dots. On this one, it slows and crawls to a stop before completing the circle. If I leave it running it gets to a state where a white screen flashes up (as if Sugar is beginning to start) then flashes off and the command lines etc are seeneventually it says it is disabling for minutes due to "respawning too fast" and I have a window when I can log onto the back end / shell as root and type commands. But not sure what to do! David Leeming ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Downloading large updates and builds in PNG
Hello, Is there a better way of making new builds and updates available? I am starting a deployment of XOs in Papua New Guinea this week and have just heard of the new G1G1 update (build 703). I may not use that immediately but need to appraise what is involved in updating by trying it out. However, downloading a 300MB file in a place like this is very difficult. It's the same in the Solomons. If you are relying on the monopoly ISP your connection will be variable and unreliable and even where wireless broad band is now being made available, it costs about USD 50c per MB in the hotel I am staying at. A quarter of the way into the download I loose my connection and the download is lost (with the money). Is it available on an FTP server which I think is more reliable? Can it be made available in smaller chunks? David Leeming ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Downloading large updates and builds in PNG
No, FTP is not more reliable, if you have a problem with HTTP downloads of the image you will have the same problems with FTP. Yes, it can be made available in smaller chunks, but it is best to download it with a restartable downloader, which recovers from interruptions. wget on Linux can do this, as can rsync. There are restartable downloaders available for other operating systems. Ability to restart at last known point after an interruption is inherent in the HTTP, FTP and rsync protocols. But many HTTP clients do not use the feature. Yes, there is a better way of making new builds and updates available, and that is the olpc-update mechanism. It restarts from where it was disconnected as well, since it uses rsync. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
Le dimanche 08 juin 2008 à 12:11 -0400, Michail Bletsas a écrit : > > b) collabora did some work to abstract out avahi, in theory the > > groundwork is present for a cerebro backend. > That's more like wishful thinking at this point. We need to push more > on that end. > Latest Salut release has a new Avahi abstraction layer (see #6658). It's still unclear if Cerebro should be integrated as an Salut backend or in its own connection manager though. G. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Fwd: Re: #7116 NORM Never A: Possible European G1G1 program needs appropriate keyboards]
> We have to forecast the parts many months ahead of when they can be built and shipped; and our manufacturer cannot build small quantities of anything Do you have an idea of the minimum quantity required so the manufacturer could build laptops with localized keyboards? Thanks Sebastien 2008/6/9 Kim Quirk <[EMAIL PROTECTED]>: > Hi Holger, > We are hoping that the company we partner with for the G1G1 program will > bring some knowledge to us about what is needed for each country where we > want to ship. We will start with that information and then figure out the > things that aren't understood. For instance, for products shipping from the > US to Germany, I'm sure there are some mandatory certifications required > (the equivalent of UL or CE). Perhaps the certifications are for all of the > EU countries. Also, some countries may require a minimum warranty or returns > policy. There might be different rules for a non-profit company. > > As for keyboards, we will only be able to ship one keyboard - > US/International. We have to forecast the parts many months ahead of when > they can be built and shipped; and our manufacturer cannot build small > quantities of anything. So we will have all the keyboards go out > US/International; and the choice of power adapter will probably have to be > limited as well to US or EU. > > Thanks, > Kim > > > > On Sat, Jun 7, 2008 at 5:35 AM, Holger Levsen <[EMAIL PROTECTED]> > wrote: > >> Hi Kim, >> >> On Tuesday 03 June 2008 21:48, Kim Quirk wrote: >> > Agreed, Ed. The legalities of each country need to be determined and >> > met before we can include that country in a Give One Get One program. >> > >> > Some of the things we need to understand are: Certifications, >> > language/keyboard requirements, messaging, non-profit status, >> > shipping, customs, support and warranties. I believe these issues (and >> > perhaps more) will be different for almost every country. >> >> What can we, as OLPC Germany association, do to help you to understand the >> legal situation (and anything else) in Germany? >> >> Also, what can we do, to make a german keyboard reality? We have keyboard >> layouts available on >> http://wiki.olpc-deutschland.de/organisation/beirat/hardware >> >> >> regards, >> Holger >> > > > ___ > 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: [Fwd: Re: #7116 NORM Never A: Possible European G1G1 program needs appropriate keyboards]
On Mon, Jun 09, 2008 at 11:28:34AM +0200, Sebastien Adgnot wrote: > Do you have an idea of the minimum quantity required so the > manufacturer could build laptops with localized keyboards? I'm sure they would. It wouldn't be a minimum quantity per se, it would be a set of quantities and how much they would cost in tooling, production, separate shipping, and integration. Then OLPC would have to choose which is economically sensible, including how long it would take. Kim's statement was simplifying the realities of production costing, and advising that it is already judged too expensive for a G1G1. I take it that the incremental cost of localised keyboard would increase the cost per unit to the point where it would not generate sufficient units sold by the G1G1, or the delay would be so considerable as to make the plan void. If a review of the decision is needed, better to focus instead on new information that can be integrated into the review ... such as whether a non-localised keyboard would be usable, and what quantity you think you will need. Maybe you already mentioned that though. I'm focusing on one reply out of many. p.s. I'm a volunteer, not an employee. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Fwd: Re: #7116 NORM Never A: Possible European G1G1 program needs appropriate keyboards]
Hi Kim! "Kim Quirk" <[EMAIL PROTECTED]> schrieb am 09.06.2008 06:12:48: > We are hoping that the company we partner with for the G1G1 program > will bring some knowledge to us about what is needed for each > country where we want to ship. We will start with that information > and then figure out the things that aren't understood. For instance, > for products shipping from the US to Germany, I'm sure there are > some mandatory certifications required (the equivalent of UL or CE). > Perhaps the certifications are for all of the EU countries. Also, > some countries may require a minimum warranty or returns policy. > There might be different rules for a non-profit company. I'm far off from understanding European warrenty laws, but the magic google word to look for seems to be "Consumer Sales Directive 1999/44/EC". The Consumer Sales Directive introduced a common European warrenty law and if you search for it you will find very informative sites like: http://ec.europa.eu/consumers > As for keyboards, we will only be able to ship one keyboard - > US/International. We have to forecast the parts many months ahead of > when they can be built and shipped; and our manufacturer cannot > build small quantities of anything. So we will have all the > keyboards go out US/International; and the choice of power adapter > will probably have to be limited as well to US or EU. Is there a way to produce seperate keyboards? It's annoying, but not overall difficult to replace the XO keyboards. So it probably could make sense to ship the XOs with international keybords and replace them with localized version later on. cu andreas___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Downloading large updates and builds in PNG
Here is what I did when I was fighting battles with an unreliable connection a few months ago. (It doesn't solve the cost of downloading, but it does solve the lost connection problem). Use wget -c url-of-the-wanted-file This command line program will allow you to resume the download again and again when the inevitable happens and the connection is lost. If you find that it downloads more reliably if you limit the bandwidth, there is another option to set a rate limit, namely: wget --limit-rate=20k -c url-of-the-wanted-file (the rate is given in bytes per second, so the above example is 20,000 bytes per second). Living at the far end of the DSL reaches, wget is my favorite program! Regards, Carol Lerche On Mon, Jun 9, 2008 at 12:29 AM, James Cameron <[EMAIL PROTECTED]> wrote: > No, FTP is not more reliable, if you have a problem with HTTP downloads > of the image you will have the same problems with FTP. > > Yes, it can be made available in smaller chunks, but it is best to > download it with a restartable downloader, which recovers from > interruptions. wget on Linux can do this, as can rsync. There are > restartable downloaders available for other operating systems. Ability > to restart at last known point after an interruption is inherent in the > HTTP, FTP and rsync protocols. But many HTTP clients do not use the > feature. > > Yes, there is a better way of making new builds and updates available, > and that is the olpc-update mechanism. It restarts from where it was > disconnected as well, since it uses rsync. > > -- > James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- "Always do right," said Mark Twain. "This will gratify some people and astonish the rest." ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
Hi Kim, Kim Quirk wrote: > > Poly - What I can't tell from your progress reports is exactly what is > needed for us to get to the next level. On the surface it sounds like > you had to rebuild chat to make it work with cerebro. If so, does that > mean all activities would have to be modified to a new API? No. I refactored Chat to the Xavier activity (http://dev.laptop.org/git?p=users/ypod/xavier-activity;a=summary) as a proof of concept that collaboration could be solely based on Cerebro. > What else is needed? Create a connection manager for Cerebro. This would also be a great chance for OLPC to become more intimate with the internals of telepathy, which is why maybe someone from OLPC should take on this task? I think we should aim to have that implemented and tested by August. Some work has been done on this by Michael Stone already. > How does the cerebro solution fit into the rest of the stack and the > other technologies we are working on for 8.2.0 (August) and future > releases? Cerebro should totally replace salut - the former is a superset, in terms of functionality, of the latter (eg. cerebro additionally offers network layout, distance information, more efficient file transfer etc), while it scales about an order of magnitude better than salut. Furthermore, cerebro would never "black-out" with broadcast storms, so if there is a jabber server present, it will always be discoverable. > > If the cerebro solution is still in research and there are a lot of > issues that still need to be worked out before we can release it, then > we need someone to help track all the issues and help resolve them > through the stack in order to get something to release stage. It depends on how you define "still in research". If that means not having been used by thousands of children around the world already, then yes it's still in research, but so is most of the XO's software. Realistically speaking, cerebro has been tested more extensively than the rest of the collaboration stack, not only on tens of XOs, but other platforms also. > Let's work with Michail on this as he probably needs to take the lead. > > As a first step, I will order 10 laptops for Poly to find permanent > homes for throughout the MIT campus. thank you. > > Kim p. -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
How to create the build summary ?
Hello, I'm new to this community. What I hope to do is generating an build summary, similar to the one at http://learn.laptop.org, by testing olpc softwares (especially, the ones installed by sugar-jhbuild) on heterogeneously configured environments. To do that, I need to know how you generate the build summary found at http://learn.laptop.org Does the sugar-jhbuild have the feature to generate such output? Thanks. + Jerome Yoon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Read Etexts now supports Text To Speech
I know there are several people interested in having Text to Speech with Karaoke highlighting be a built in part of the Sugar environment. Also, when I originally requested a Git repository for the Read Etexts activity Ed asked if text to speech with highlighting would be supported. I was reluctant to commit to that at the time, thinking it would be too difficult. It turned out to be both easier and more difficult than I thought it would be, but I have released version 4 of the activity which now supports TTS with the words highlighted as they are spoken. The code could be improved, no doubt. I am fairly new to Python programming. But I think trying out this Activity could give you some idea of what to expect if you attempt to incorporate TTS as part of the Sugar interface. 1). Speech-dispatcher needs to run in a separate thread from the GTK event loop, otherwise the callbacks needed to highlight words won't be received. 2). To get the callbacks as each word is spoken you need to format the text to be spoken as an XML document with tags *before* each word. My code assumes that words are separated by whitespace, which works for many languages but not all of them. I know Sanskrit doesn't work that way, for instance. 3). Espeak does not allways do a callback for each word, and there is no obvious reason why any given word would be skipped. I understand that Festival works better, but I haven't tried it. At the suggestion of Hynek Hanke of the speech-dispatcher project I made the tag ids for each tag correspond to the word number in the document. In this way I can get the tag id in the callback and always highlight the correct word even if occasionally words are skipped over by espeak. 4). Pausing and resuming speech doesn't work. No idea why. 5). The instructions for setting up speech-dispatcher on the wiki are obsolete. You cannot use espeak-generic module with speech-dispatcher and get callbacks. You need to use the normal espeak module. When you try to use the normal espeak module with the current RPMs speech-dispatcher complains of a missing library. So if you want to try my Activity you'll need to use sugar-jhbuild with speech-dispatcher installed and configured to use espeak. Hemant Goyal is working on creating RPMs for speech-dispatcher and will be updating the instructions on the wiki. The Activity page is: http://wiki.laptop.org/go/Read_Etexts James Simmons ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
python imports and performance (was Re: #5549 ...)
Hi, moving to the list as has little to do with the ticket in question. http://dev.laptop.org/ticket/5549 > Comment(by mstone): > > This seems like a terrible argument to me because of the categorical > imperative: if everyone blindly followed style guidelines without making a > conscious assessment of the costs imposed by those guidelines then we'd > wind up... where we are today, with Python activities that import 10 > seconds worth of code before becoming interactive. > > Thus, while you're correct that we should place a high value on following > conventions, I happen to think that the 'imports at the top' guideline has > been so badly discredited by its effect activity startup time as to be > untenable in the presence of python modules which perform arbitrary > computation at import time. (We could also decide to refuse to use python > modules which perform noticeable computation on import, but that seems > more painful to me. What do you think?) I don't think that you are on crack, but I think that should explain better where you want to go ;) Someone submitted a patch with a violation of the style guidelines. The submitter commented that this violation was made because of performance considerations. I explained why there was no performance hit that would justify that deviance from what is expected the sugar code to look like. What argument are you calling terrible? What has Kant to do with all this? Who is blindly following anything? If activities take X seconds to startup because of module-level code, it has little to do with the imports being at the top or being inline. The modules are loaded because they are imported before the activity window is brought up, and that happens because they are actually needed to perform all the initializations that we want (perhaps mistakenly) to do during activity startup. Now I'm a bit angry at Michael and Chris, because they have managed to drag me again into this old discussion when a little experimentation would have convinced them instead. Just try to move the imports from the top to just before being used, and see if there's any advantage in startup time. Do you really think that I'm so stupid as to have invested so much work on the prefork hack just to avoid shuffling some imports around? In fact, I moved one import to inline when I measured that it actually made a difference (1 second out of 7): http://dev.laptop.org/git?p=sugar-base;a=commitdiff;h=cc7bbec111d691c198ef6c9ca761c8f576882d0a If you can find other modules that are not needed during startup but are actually slowing activity startup, please send patches. I don't expect you to have any problem in having them accepted if you show some evidence of improvements. And for the record, the right fix from my POV is to only register names at the module scope, moving all expensive initializations to be done lazily when things are actually called. Don't know what's the opinion in the python community about this, though. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: python imports and performance (was Re: #5549 ...)
Measuring the performance impact of shuffling imports is tricky. At the moment, all of our modules have imports at the top, so all it takes is *one* module with a bad import at the top to basically charge everyone the loading cost for all that code. Therefore, you don't see any performance improvement by piecemeal changes: you have to do a substantial amount of refactoring before you finally get enough imports off the startup path to cause an improvement. If you remove 'import foo' from one place where it's not needed, but leave 'import bar', and bar in turn imports foo (whether it's needed or not), you don't see any improvement. But I contend that it is still worth doing! When you finally get around to fixing 'bar', you'll start seeing performance improvements. The first time this issue arose was in conjunction with: http://dev.laptop.org/ticket/5538 and I definitely *did* see concrete performance improvements from the changes I made: but they were in a special case where Pippy wanted to be able to 'import sugar.activity' in a reasonable amount of time, but *wasn't* doing a full activity startup. I wasn't benchmarking full activity startup because that's not what I was interested in. The hostile reaction to my initial patch did not convince me it would be worth my time extending my work to the point where it made a difference to full activity startup, which undoubtedly would be a more invasive patch. I think the full solution will probably be a combination of lazy module loading and moving the most egregious gratuitous imports. 'import sugar.activity.activity' still takes 3.7s *by itself* on build 703. Why? --scott p.s. I suspect part of the larger startup issue may be that we are rendering SVGs on demand for the toolbar, etc. We can either defer that rendering, allowing us to open the activity quickly and then later fill in the icons (as the gnome panel does), or maintain a persistent cache of SVG renderings. -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: python imports and performance (was Re: #5549 ...)
On Mon, Jun 9, 2008 at 6:35 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:
> Measuring the performance impact of shuffling imports is tricky. At
> the moment, all of our modules have imports at the top, so all it
> takes is *one* module with a bad import at the top to basically charge
> everyone the loading cost for all that code. Therefore, you don't see
> any performance improvement by piecemeal changes: you have to do a
> substantial amount of refactoring before you finally get enough
> imports off the startup path to cause an improvement. If you remove
> 'import foo' from one place where it's not needed, but leave 'import
> bar', and bar in turn imports foo (whether it's needed or not), you
> don't see any improvement. But I contend that it is still worth
> doing! When you finally get around to fixing 'bar', you'll start
> seeing performance improvements.
Yes, but once we have shuffled all the imports in our codebase and
seen little improvement, then we'll need to start patching upstream
code so the imports are inline...
At that point, must be easier to send patches to upstream so that the
expensive initializations happen lazily.
> The first time this issue arose was in conjunction with:
> http://dev.laptop.org/ticket/5538
> and I definitely *did* see concrete performance improvements from the
> changes I made: but they were in a special case where Pippy wanted to
> be able to 'import sugar.activity' in a reasonable amount of time, but
> *wasn't* doing a full activity startup. I wasn't benchmarking full
> activity startup because that's not what I was interested in. The
> hostile reaction to my initial patch did not convince me it would be
> worth my time extending my work to the point where it made a
> difference to full activity startup, which undoubtedly would be a more
> invasive patch.
If we can shuffle imports around and drop the prefork hack, I'd be all
for it. Unfortunately, import shuffling hasn't shown yet as much
performance benefits.
> I think the full solution will probably be a combination of lazy
> module loading and moving the most egregious gratuitous imports.
> 'import sugar.activity.activity' still takes 3.7s *by itself* on build
> 703. Why?
See below for a tip on how to check.
> p.s. I suspect part of the larger startup issue may be that we are
> rendering SVGs on demand for the toolbar, etc. We can either defer
> that rendering, allowing us to open the activity quickly and then
> later fill in the icons (as the gnome panel does), or maintain a
> persistent cache of SVG renderings.
I don't remember seeing icon rendering in the activity startup
profile, but is easy to test:
import os
import cProfile
import lsprofcalltree
profiler = cProfile.Profile()
profiler.enable()
### code to profile ###
profiler.disable()
k = lsprofcalltree.KCacheGrind(profiler)
data = open('/tmp/import.kgrind', 'w+')
k.output(data)
data.close()
http://www.gnome.org/~johan/lsprofcalltree.py
You can read the .kgrind file with kcachegrind.
Good luck,
Tomeu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
On Mon, Jun 09, 2008 at 09:55:20AM +0200, Guillaume Desmottes wrote: > Latest Salut release has a new Avahi abstraction layer (see #6658). > It's still unclear if Cerebro should be integrated as an Salut backend > or in its own connection manager though. What lack of clarity do you observe? From the Collabora work statement: Integrating Cerebro into Telepathy framework We've spoken to Polychronis about how Cerebro works, and attended his presentation last week, and now have a better understanding of the functions provided by Cerebro, and how it could be best integrated into Telepathy framework for use by the presence service, Sugar and activities. We propose to continue work on the “telepathy-cerebro” connection manager which implements the Telepathy API by using the communications provided by Cerebro, so that we can make its functionality available to the existing software on the XOs without modification, and allow observations of the behaviour and reliability of Cerebro in our test environments. http://teach.laptop.org/~mstone/collabora.txt Michael P.S. - For hints, see http://dev.laptop.org/git/users/mstone/telepathy-cerebro ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] python imports and performance (was Re: #5549 ...)
On Mon, Jun 09, 2008 at 12:35:56PM -0400, C. Scott Ananian wrote: > p.s. I suspect part of the larger startup issue may be that we are > rendering SVGs on demand for the toolbar, etc. We can either defer > that rendering, allowing us to open the activity quickly and then > later fill in the icons (as the gnome panel does), or maintain a > persistent cache of SVG renderings. If this is the case I will work on it immediately. Load-time rendered SVGs should be cached. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Trac Triage
Jim pointed out that he shouldn't be owning the default trac component so we made a new one called 'not assigned' to contain bugs which have never been assigned to a component. Bugs which require that a new component be created can be assigned to the 'new component' component or can be left 'not assigned' and marked as blocking on a component creation ticket. We have not marked anyone as the owner of the 'not assigned' component. We have not migrated old distro tickets to the 'not assigned' component. We discussed making a 'triage' or 'janitors' list to own the 'not-assigned' component. We also considered creating a report for sampling trac weekly for new 'not assigned' tickets and for mailing results to [EMAIL PROTECTED] Thoughts on how to organize ticket triage would be most welcome. Thanks. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: journal object transfer for 8.2
Tomeu, > have heard occasional requests to implement the sending and sharing of > journal entries. It's a desirable feature but, from my perspective, it's much lower in immediate priority than work which brings the sugar UI revision into a releasable condition and which "polish" the existing work by closing several of the 379 tickets assigned to component 'sugar': http://dev.laptop.org/query?status=assigned&status=new&status=reopened&component=sugar&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component > So the questions are: is this a feature we should deliver for the 8.2 > release? In my opinion, "no". Do you think differently? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: journal object transfer for 8.2
I would argue otherwise. Since Sugar has no control over the robustness of the network, having some way of sharing at a basic level from the Journal is seemingly a high priority. Half of the high-priority bugs in the link you provide are in fact not really Sugar bugs, but subsystem bugs. The others don't seem to be particularly pressing. -walter On Mon, Jun 9, 2008 at 4:12 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > Tomeu, > >> have heard occasional requests to implement the sending and sharing of >> journal entries. > > It's a desirable feature but, from my perspective, it's much lower in > immediate priority than work which brings the sugar UI revision into a > releasable condition and which "polish" the existing work by closing > several of the 379 tickets assigned to component 'sugar': > > > http://dev.laptop.org/query?status=assigned&status=new&status=reopened&component=sugar&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component > >> So the questions are: is this a feature we should deliver for the 8.2 >> release? > > In my opinion, "no". > > Do you think differently? > > Michael > ___ > 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: journal object transfer for 8.2
On Mon, Jun 09, 2008 at 04:18:10PM -0400, Walter Bender wrote: > I would argue otherwise. Since Sugar has no control over the > robustness of the network, having some way of sharing at a basic level > from the Journal is seemingly a high priority. My feeling is that since Sugar has no control over the robustness of the network, the feature will function poorly, if at all. Consequently, I would rather see bug-fixes which will bring the system closer to its intended operation with high probability. However, this is just a personal preference. I'm (mostly) happy to release whatever you send my way, so long as it fixes more problems than it creates. > Half of the high-priority bugs in the link you provide are in fact not > really Sugar bugs, but subsystem bugs. The others don't seem to be > particularly pressing. Perhaps a few hours of triage are called for? Here are a few of my favorites: http://dev.laptop.org/ticket/7011 <--- Zoom buttons should cycle http://dev.laptop.org/ticket/7220 <--- Populate activity ring http://dev.laptop.org/ticket/4236 <--- Cancel activity startup http://dev.laptop.org/ticket/7020 <--- Force activity shutdown http://dev.laptop.org/ticket/6895 <--- Access point UI http://dev.laptop.org/ticket/6909 http://dev.laptop.org/ticket/5444 <--- Robustness to failure http://dev.laptop.org/ticket/6148 <--- Non-ASCII Activity Names http://dev.laptop.org/ticket/6471 <--- Activity startup times http://dev.laptop.org/ticket/6472 http://dev.laptop.org/ticket/6237 <--- Cloaked APs http://dev.laptop.org/ticket/6281 <--- 802.1x for NY,UY! http://dev.laptop.org/ticket/4877 <--- Session API Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: journal object transfer for 8.2
An OLPC intern would have actually taken up this task, but changed direction for the summer. I 'm not sure though how network robustness will improve if some networking (such as file transfer) is done in the Journal. A slightly more radical change may be necessary ;-) p. Walter Bender wrote: > I would argue otherwise. Since Sugar has no control over the > robustness of the network, having some way of sharing at a basic level > from the Journal is seemingly a high priority. Half of the > high-priority bugs in the link you provide are in fact not really > Sugar bugs, but subsystem bugs. The others don't seem to be > particularly pressing. > > -walter > > On Mon, Jun 9, 2008 at 4:12 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > >> Tomeu, >> >> >>> have heard occasional requests to implement the sending and sharing of >>> journal entries. >>> >> It's a desirable feature but, from my perspective, it's much lower in >> immediate priority than work which brings the sugar UI revision into a >> releasable condition and which "polish" the existing work by closing >> several of the 379 tickets assigned to component 'sugar': >> >> >> http://dev.laptop.org/query?status=assigned&status=new&status=reopened&component=sugar&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component >> >> >>> So the questions are: is this a feature we should deliver for the 8.2 >>> release? >>> >> In my opinion, "no". >> >> Do you think differently? >> >> Michael >> ___ >> 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 > -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] journal object transfer for 8.2
On Mon, Jun 9, 2008 at 10:12 PM, Michael Stone <[EMAIL PROTECTED]> wrote: >> So the questions are: is this a feature we should deliver for the 8.2 >> release? > > In my opinion, "no". > > Do you think differently? Personally I think we should put it at the very end of the prioritized list of new features: http://wiki.sugarlabs.org/go/ReleaseTeam/Roadmap#New_features If someone find time to work in by the feature freeze (20 June), it will be a nice feature to have. But otherwise let's focus to complete the features which are already scheduled for inclusion and on bugfixes. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: journal object transfer for 8.2
On Mon, Jun 9, 2008 at 10:57 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > On Mon, Jun 09, 2008 at 04:18:10PM -0400, Walter Bender wrote: >> I would argue otherwise. Since Sugar has no control over the >> robustness of the network, having some way of sharing at a basic level >> from the Journal is seemingly a high priority. > > My feeling is that since Sugar has no control over the robustness of the > network, the feature will function poorly, if at all. Consequently, I > would rather see bug-fixes which will bring the system closer to its > intended operation with high probability. However, this is just a > personal preference. I'm (mostly) happy to release whatever you send my > way, so long as it fixes more problems than it creates. > >> Half of the high-priority bugs in the link you provide are in fact not >> really Sugar bugs, but subsystem bugs. The others don't seem to be >> particularly pressing. > > Perhaps a few hours of triage are called for? Here are a few of my > favorites: After the feature freeze we should definitely spend a good amount of time on bugs triage. The sugar components has not been seriously triaged in the last several months. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Flash is too full
2008/6/9 David Leeming <[EMAIL PROTECTED]>: > I have an XO-1 that has stopped booting correctly after I tried to install > some large activities from a flash drive. Ugh, that sounds bad. > for minutes due to "respawning too fast" and I have a window when I can log > onto the back end / shell as root and type commands. But not sure what to > do! press enter and you will get a line starting with "#" and the cursor next to it - that is a root prompt. First of all, call the following command (the # here is for illustration, you don't need to type it) # su olpc Now you have switched to the olpc user - this gives you a safer environment, and changes the "prompt" to "$", so you'll see "$" followed by the cursor. So do (again the $ is for illustration) $ df -h this will list various mountpoints, the main one is the one named "/" and it will show you space available. If it's really very low, then your diagnosis is correct. If there is disk space and the problem is different - don't follow the instructions below ;-) So - assuming a real space problem the next step is to change to the installed activities directory $ cd /home/olpc/Activities $ ls this will list the activities installed there $ du -sh * will take a few seconds, and will list them with their size. So pick a candidate to delete and do _with a lot of care_ $ rm -fr MyFooActivity.activity repeat the above action with every activity you want to remove. Then restart. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- 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: Downloading large updates and builds in PNG
Would it be worth setting up a BitTorrent tracker for builds? BitTorrent is very reliable, excellent at resuming, doesn't require command line use, and can take advantage of local seeds. Best, Wade 2008/6/9 Carol Lerche <[EMAIL PROTECTED]>: > Here is what I did when I was fighting battles with an unreliable > connection a few months ago. (It doesn't solve the cost of downloading, but > it does solve the lost connection problem). Use > > wget -c url-of-the-wanted-file > > This command line program will allow you to resume the download again and > again when the inevitable happens and the connection is lost. If you find > that it downloads more reliably if you limit the bandwidth, there is another > option to set a rate limit, namely: > > wget --limit-rate=20k -c url-of-the-wanted-file > > (the rate is given in bytes per second, so the above example is 20,000 > bytes per second). > > Living at the far end of the DSL reaches, wget is my favorite program! > > Regards, > > Carol Lerche > > > On Mon, Jun 9, 2008 at 12:29 AM, James Cameron <[EMAIL PROTECTED]> wrote: > >> No, FTP is not more reliable, if you have a problem with HTTP downloads >> of the image you will have the same problems with FTP. >> >> Yes, it can be made available in smaller chunks, but it is best to >> download it with a restartable downloader, which recovers from >> interruptions. wget on Linux can do this, as can rsync. There are >> restartable downloaders available for other operating systems. Ability >> to restart at last known point after an interruption is inherent in the >> HTTP, FTP and rsync protocols. But many HTTP clients do not use the >> feature. >> >> Yes, there is a better way of making new builds and updates available, >> and that is the olpc-update mechanism. It restarts from where it was >> disconnected as well, since it uses rsync. >> >> -- >> James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ >> ___ >> Devel mailing list >> Devel@lists.laptop.org >> http://lists.laptop.org/listinfo/devel >> > > > > -- > "Always do right," said Mark Twain. "This will gratify some people and > astonish the rest." > ___ > 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: Downloading large updates and builds in PNG
It would be a good alternative to have, although we know various ISPs (e.g. comcast) are interfering with bittorrent, so it has good and bad sides. On Mon, Jun 9, 2008 at 5:19 PM, Wade Brainerd <[EMAIL PROTECTED]> wrote: > Would it be worth setting up a BitTorrent tracker for builds? > > BitTorrent is very reliable, excellent at resuming, doesn't require command > line use, and can take advantage of local seeds. > > Best, > Wade > > 2008/6/9 Carol Lerche <[EMAIL PROTECTED]>: > > Here is what I did when I was fighting battles with an unreliable >> connection a few months ago. (It doesn't solve the cost of downloading, but >> it does solve the lost connection problem). Use >> >> wget -c url-of-the-wanted-file >> >> This command line program will allow you to resume the download again and >> again when the inevitable happens and the connection is lost. If you find >> that it downloads more reliably if you limit the bandwidth, there is another >> option to set a rate limit, namely: >> >> wget --limit-rate=20k -c url-of-the-wanted-file >> >> (the rate is given in bytes per second, so the above example is 20,000 >> bytes per second). >> >> Living at the far end of the DSL reaches, wget is my favorite program! >> >> Regards, >> >> Carol Lerche >> >> >> On Mon, Jun 9, 2008 at 12:29 AM, James Cameron <[EMAIL PROTECTED]> wrote: >> >>> No, FTP is not more reliable, if you have a problem with HTTP downloads >>> of the image you will have the same problems with FTP. >>> >>> Yes, it can be made available in smaller chunks, but it is best to >>> download it with a restartable downloader, which recovers from >>> interruptions. wget on Linux can do this, as can rsync. There are >>> restartable downloaders available for other operating systems. Ability >>> to restart at last known point after an interruption is inherent in the >>> HTTP, FTP and rsync protocols. But many HTTP clients do not use the >>> feature. >>> >>> Yes, there is a better way of making new builds and updates available, >>> and that is the olpc-update mechanism. It restarts from where it was >>> disconnected as well, since it uses rsync. >>> >>> -- >>> James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ >>> ___ >>> Devel mailing list >>> Devel@lists.laptop.org >>> http://lists.laptop.org/listinfo/devel >>> >> >> >> >> -- >> "Always do right," said Mark Twain. "This will gratify some people and >> astonish the rest." >> ___ >> Devel mailing list >> Devel@lists.laptop.org >> http://lists.laptop.org/listinfo/devel >> >> > -- "Always do right," said Mark Twain. "This will gratify some people and astonish the rest." ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Games depending on OpenGL and GLX - any way to test on XO with regular OLPC image?
I adapted TinyGL to render to an arbitrary sized framebuffer, later scaled to fullscreen with the xvideo extension. I currently don't have time to work on it, but if anyone is interested, I'll send the code. Daniel Benjamin M. Schwartz escreveu: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Bert Freudenberg wrote: > | A 400x300 mode scaled up by 3 to the panel resolution would be > | awesome, and should allow nice software rendering. If such a mode > | existed, maybe it would even make sense to ship Mesa (a software > | OpenGL implementation) and GLUT, which would allow some OpenGL > | programs to run unmodified. > > One way to implement such a scaling system would be to use Xv, rather than > mode-setting. The 2D engine does support scaling with Xv, so a 400x300 3D > area could be scaled up to fill the whole screen. > > Unfortunately, neither SDL nor Mesa seems to have built-in support for > using Xv to scale output, so a substantial amount of work is required in > software. > > - --Ben > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkhL8ZIACgkQUJT6e6HFtqRuswCfdq7ZEsQHLULyywrKEnfv1XRq > DIoAn3WssLRS4mDCJM4zQx4S1QpgxQFe > =nc3v > -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
New joyride build 2029
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2029 Changes in build 2029 from build: 2024 Size delta: 0.00M -olpcupdate 2.6-0 +olpcupdate 2.7-0 -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Localization] [Fwd: Re: #7116 NORM Never A: Possible European G1G1 program needs appropriate keyboards]
On Mon, Jun 9, 2008 at 11:00 AM, Carlo Falciola <[EMAIL PROTECTED]> wrote: > > What about to delivery plain intn'l machines with default keyboard and > then set up some stocks of nationalized keyboards (FR, DE, IT, GR, etc.. ) > and offer them at a price that's commisurated to the production cost of the > keyboard itself (and the planned numbers), not burdening at all XO > production? > I sincerely hope the OLPC has learned some lessons from the first G1G1 program. While it seems clear enough that the logistics of providing a "factory-localized" laptop are very likely insurmountable, it also seems clear that shipping only US International keyboard to an EU-focused G1G1 program will NOT be well received and will only bring accusations of cultural and linguistic imperialism and the like to an organization that should be earning praise for it's efforts to make computing in local languages possible. There must be a third path. Imagine instead a different sort of G1G1 process that incorporates Carlo's suggestion. The web-site for an EU G1G1 program clearly explains some of the XO's remarkable flexibility (both in hardware and in software) and the immense level of control handed over to the user. EU donors order their G1G1 in a selection of several languages (en, fr, es, de, it, however many are relevant and feasible). It is clearly explained that what the donor will receive is a US International formatted XO and an envelope containing the keyboard membrane for the language of their choice along with a beautifully illustrated brochure explaining how to swap keyboard membranes, the brochure to be localized in the same language as the keyboard. The brochure will also explain how to use a newly created activity called LocalizeMyXO. LocalizeMyXO comes pre-installed in the EU G1G1 image. The user changes the keyboard membrane using the supplied hard-copy directions and then clicks on one of the flags displayed by the LocalizeMyXO activity as described in the brochure. The LocalizeMyXO activity reaches out to a controlled location on OLPC servers (or mirrors in EU) and in a scripted fashion, performs all of the necessary steps to re-localize the laptop to the relevant language, switches keyboard settings, downloads a fresh image with the right Pootle strings, including activities, etc. LocalizeMyXO does all of this without any substantial user intervention once the language has been selected. The LocalizeMyXO activity stays available, and if the donor wants to switch back, they just click on another flag. This requires no special logistics in manufacturing, other than preparing some additional membranes in various languages and adding the proposed LocalizeMyXO activity to the image. There would need to be better logistics on the distribution end, but we knew that already. The language choice field have to be tracked by the hopefully much improved donor tracking/shipping system (it should not be guessed from ship to address). The packing and shipping operation will need to drop the correct envelope into the correct box. Distribution processing could be bulk sorted into several streams (by language packet) to make it simpler. Let's say you do a different language every day, in rotation, for the heavy phase of the shipping cycle to avoid slighting any one language group, or do it for several days, whatever, just don't leave one language group to the bitter end. Net result, G1G1 donors ultimately get the localized machine they want for their Get One. They know upfront they will have to do a little work (keyboard membrane change), but the logistics of manufacturing runs and cost savings have been clearly and politely explained to them in advance and they knowingly opt in. They gain the experience of how easily an XO keyboard is swapped (beauty of hardware design) and how cleanly a localization change can be performed, if executed in more-or-less one-click fashion by LocalizeMyXO (beauty of software design). OLPC distributes the accumulated Give Ones to children without buying itself a totally unnecessary public relations nightmare. Final score: Get One Donor, Win. Give One Child, Win. OLPC, Win. Additional mfg costs: Must factor extra membranes into cost. Make mfg/distribution cost of membrane explicit. Need to create LocalizeMyXO activity, it would be a variation on theme of scripts/procedures already existing for updating to newer builds (Update.1 and after) and for re-installing G1G1 bundles Additional distribution costs: These would need to be factored in as well. If a competent EU-savvy distributor is selected, these should be relatively modest and can be rolled into membrane upcharge. I'm a North American G1G1 donor, and while it took longer than I had hoped to get my XO, I got it and I'm very happy with it. It got me to work on contributing to OLPC (mostly on wiki, focused on content, not code). That's the sort of "fringe benefit" you want to get from a G1G1 program. How can OLPC exp
Re: Games depending on OpenGL and GLX - any way to test on XO with regular OLPC image?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Monteiro Basso wrote: | I adapted TinyGL to render to an arbitrary sized framebuffer, later | scaled to fullscreen with the xvideo extension. I currently don't have | time to work on it, but if anyone is interested, I'll send the code. | I can think of a number of people who might be interested in that code. Please post it. Thank you, Ben Schwartz -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhN0osACgkQUJT6e6HFtqRWmwCggRddTctRrvj95bSblBjiIWFn lcgAnjzkBfBKdRlCi2tiOxwv/jwLxO44 =IOdu -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
ANN: 8.1.1 Candidate Build - candidate-708
Dear world, I'm pleased to announce that our first signed release candidate for the 8.1.1 bugfix release is now available for downloading and updating. Please help test it by 1. Procuring activities if you need them. See the release notes for details. and ONE OF 2a. olpc-update -f candidate-708 && reboot 2b. secure-reflash or copy-nand on material from http://download.laptop.org/xo-1/os/candidate/708/jffs2/ Next, PLEASE SHOUT if you experience a regression in connectivity from 65x to 70x. (We've got another G1G1 visible on the horizon and we'd really like to know about connectivity problems as soon as you can tell us.) If you wish to help perform this testing (or to verify the fixes for specific issues), please record your results at http://wiki.laptop.org/go/OLPC_SW-ECO_5 You can see that Simon and I have been checking off individual tickets; more free-form remarks can go in the 'Test Results' space below. Finally, if you want to help make this release suitable for Joe User, please help update the http://wiki.laptop.org/go/OLPC_8.1.1_Software_Release_Notes Thanks very much! Michael P.S. - Special thanks are due, in this release, to Sayamindu, Tomeu, Ricardo, Dennis, Blake, Mitch, and Kim for extraordinary patience in the face of my novice release efforts. My official award for "Best Volunteer Contributions to the Release Candidate" goes to Blake Setlow for his efforts to restore support for both the PenTablet and USB ethernet adapters. Thanks for your hard work, Blake! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New faster build 2029
http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build2029 Changes in build 2029 from build: 2024 Size delta: 0.00M -olpcupdate 2.6-0 +olpcupdate 2.7-0 -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/faster-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Localization] [Fwd: Re: #7116 NORM Never A: Possible European G1G1 program needs appropriate keyboards]
On Mon, 9 Jun 2008, Chris Leonard wrote: > >> >> What about to delivery plain intn'l machines with default keyboard and >> then set up some stocks of nationalized keyboards (FR, DE, IT, GR, etc.. ) >> and offer them at a price that's commisurated to the production cost of the >> keyboard itself (and the planned numbers), not burdening at all XO >> production? >> > > I sincerely hope the OLPC has learned some lessons from the first G1G1 > program. While it seems clear enough that the logistics of providing a > "factory-localized" laptop are very likely insurmountable, it also seems > clear that shipping only US International keyboard to an EU-focused G1G1 > program will NOT be well received and will only bring accusations of > cultural and linguistic imperialism and the like to an organization that > should be earning praise for it's efforts to make computing in local > languages possible. by screaming that any EU available G1G1 program must have many different keyboards available or OLPC will be condemmed, all you are doing is making sure that future G1G1 programs are not made available in europe. the logistics of getting the proper keyboards don't change significantly between having the local keybard installed in the machine, or having it encosed in the box (in fact, I suspect that it would be cheaper to install it, putting it in the box is going to be a manual process) if you can find a supplier to make the keybard skins, and OLPC can ship a single keyboard, with the people receiving the machines ordering the keybards and installing them themselves you may then have something. but demanding that OLPC make them available in more places, and at the same time threatening them unless they provide dozens of localized versions, is not productive. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Localization] [Fwd: Re: #7116 NORM Never A: Possible European G1G1 program needs appropriate keyboards]
On Mon, Jun 09, 2008 at 06:19:58PM -0700, [EMAIL PROTECTED] wrote: > but demanding that OLPC make them available in more places, and at the > same time threatening them unless they provide dozens of localized > versions, is not productive. Agreed. If this is going to cost too much, just give up on Europe. Concentrate on what you are good at. (In Australia, we use US keyboard layout, and only occasionally miss having the BBQ and PUB keys.) -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-LiveCD Release 080607
This worked pretty well for me. I booted the LiveCD off my Macbook Pro and it started up the 703build of sugar (the previous LiveCD). Nice and fast! The only problem was the aspect ratio of my screen doesn't meet that of Sugar so some things are cut off the bottom making it difficult or impossible in some activities to work. Record couldn't use the camera or microphone, but measure could use the mic. Pippy could use the sound well, but you can't read the 'run' and 'stop' buttons. They are just buttons with no words. I think this is a great way for teachers or others who don't have an XO to work with Sugar and the activities to help design or enhance their curriculum. Thanks!! Kim On Mon, Jun 9, 2008 at 3:10 AM, <[EMAIL PROTECTED]> wrote: > A new release 080607 of the Livebackup XO-LiveCD is available at: > > http://dev.laptop.org/pub/livebackupcd/build-708+joyride-2024 > > and mirrored in Germany at > > ftp://rohrmoser-engineering.de/pub/XO-LiveCD/ > > > Main features and changes since version 080321: > > * Dual boot option for update.1 and joyride builds, > You can try out the new SUGAR design by booting a recent > OLPC joyride version. > > * Improved CD customization. Additional activities and RPM packages > can be installed by putting them into CD top-level directories. > > * A new script to prepare USB boot devices out of the Live-ISO image. > > * Tested on a wide range of PC and laptop hardware and proved to work > with all common virtual machines on Windows, MacOS and Linux. > > * Additional Xorg graphic drivers and improved X11 > auto-configuration tools. > > * Bug fixes, updates and new activities. > > * Linux kernel 2.6.24.7, using the aufs-filesystem. > > > This Live-CD project targets the main goals: > > * Give children, students, teachers and parents > the opportunity to participate and use the > educational software on a common PC. > > * Demonstration of OLPC/Sugar software to non-developers, you can also > start the sugar desktop on Windows, Linux or MacOS using a > Virtual Machine. > > * For developers the CD provides an easy maintainable Live-System, > which could be used to develop and test activities on the sugar > desktop. > > > Further information is available in the PDF document: > > ftp://rohrmoser-engineering.de/pub/XO-LiveCD/XO-LiveCD_080607.pdf > > For discussion we invite you to join the mailing list: > > http://lists.laptop.org/listinfo/livebackup-xo-cd > > > Regards > > Wolfgang Rohrmoser > > ___ > 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: [Fwd: Re: #7116 NORM Never A: Possible European G1G1 program needs appropriate keyboards]
On Mon, Jun 9, 2008 at 12:07 PM, James Cameron <[EMAIL PROTECTED]> wrote: > On Mon, Jun 09, 2008 at 11:28:34AM +0200, Sebastien Adgnot wrote: > > Do you have an idea of the minimum quantity required so the > > manufacturer could build laptops with localized keyboards? > > I'm sure they would. > > It wouldn't be a minimum quantity per se, it would be a set of > quantities and how much they would cost in tooling, production, separate > shipping, and integration. Then OLPC would have to choose which is > economically sensible, including how long it would take. Kim's > statement was simplifying the realities of production costing, and > advising that it is already judged too expensive for a G1G1. I take it > that the incremental cost of localised keyboard would increase the cost > per unit to the point where it would not generate sufficient units sold > by the G1G1, or the delay would be so considerable as to make the plan > void. I understand. But something to keep in mind is 200$ is a little bit less than 130 euros which stay a very good price in Europe for a laptop. I was asking that question, just in case somebody in France would ask the same one. Because without an AZERTY keyboard, it will be hard to defend the project here. We are not the kings of cultural exception for nothing (that might be directly translated from french, sorry)! > > > If a review of the decision is needed, better to focus instead on new > information that can be integrated into the review ... such as whether a > non-localised keyboard would be usable, and what quantity you think you > will need. Maybe you already mentioned that though. I'm focusing on > one reply out of many. I have no idea of the quantity we would need. I really understand the complexity of producing, maintaining, etc. multi-layout keyboards or any other parts of the laptop. > > p.s. I'm a volunteer, not an employee. > > -- > James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ Thanks Sebastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Trac jiggery pokery
I did some minor updates to Trac so we can actually remove spam. If you see anything explode, please notify the proper authorities. On a related note, we now have to ability to force users to validate their email address before touching tickets. This is currently disabled, but do you guys want this on? --Noah signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
