Re: activation cert
Sameer - Yes, tell your browser to trust it. The activation server uses a self-signed certificate that your browser doesn't know to trust by default. All XO laptops trust it. - Ed On Jul 7, 2010, at 8:41 PM, Sameer Verma wrote: > activation.laptop.org is throwing a SSL error. > > "activation.laptop.org uses an invalid security certificate. > > The certificate is not trusted because the issuer certificate is unknown. > > (Error code: sec_error_unknown_issuer)" > > This makes getting the dev key problematic (wget part). > > Any ideas/fixes? > > cheers, > Sameer > ___ > 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
activation cert
activation.laptop.org is throwing a SSL error. "activation.laptop.org uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer)" This makes getting the dev key problematic (wget part). Any ideas/fixes? cheers, Sameer ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Announce: OLPC software strategy.
On Wed, Jul 7, 2010 at 3:01 PM, Chris Ball wrote: > Hi, > > Now that the 10.1.1 release for XO-1.5 is out, it's a good time to > talk about OLPC's software strategy for the future. We've got a few > announcements to make: > > XO-1: > = > > OLPC wasn't planning to make a Fedora 11 release of the XO-1 OS, but > a group of volunteers including Steven Parrish, Bernie Innocenti, > Paraguay Educa and Daniel Drake stepped up and produced Fedora 11 XO-1 > builds that follow the OLPC 10.1.1 work. I'm happy to announce that > we're planning on releasing an OLPC-signed version of that work, and > that this release will happen alongside the next XO-1.5 point release > in the coming weeks. So, OLPC release 10.1.2 will be available for > both XO-1 and XO-1.5 at the same time, and will contain Sugar 0.84, > GNOME 2.26 and Fedora 11. We think that offering this fully > interoperable software stack between XO-1 and XO-1.5 laptops will > greatly aid deployments, and we're very thankful to everyone who has > enabled us to be able to turn this XO-1 work into a supported release! > > To prepare for this XO-1 release, we've started working on fixing > some of the remaining bugs in the community F11/XO-1 builds. Paul Fox > recently solved a problem with suspend/resume and wifi in the F11/XO-1 > kernel, which was the largest blocker for a supported release. We'll > continue to work on the remaining bugs, particularly the ones that > OLPC is uniquely positioned to help with. > > The first development builds for this release will be published later > this week. > > XO-1.5: > === > > We'll be continuing to work on XO-1.5 improvements, incorporating > fixes to the "Known Problems" section of the 10.1.1 release notes¹ > into the 10.1.2 release. > > XO-1.75 and beyond: > === > > XO-1.75 software development is underway. Today we're announcing > that we're planning on using Fedora as the base distribution for the > XO-1.75. This wasn't an obvious decision -- ARM is not a release > architecture in Fedora, and so we're committing to help out with that > port. Our reasons for choosing Fedora even though ARM work is needed > were that we don't want to force our deployments to learn a new > distribution and re-write any customizations they've written, we want > to reuse the packaging work that's already been done in Fedora for > OLPC and Sugar packages, and we want to continue our collaboration > with the Fedora community who we're getting to know and work with > well. > > We've started to help with Fedora ARM by adding five new build > machines (lent to OLPC by Marvell; thanks!) to the Fedora ARM koji > build farm, and we have Fedora 12 and Sugar 0.86 running on early 1.75 > development boards. We'd prefer to use Fedora 13 for the XO-1.75, but > it hasn't been built for ARM yet -- if anyone's interested in helping > out with this or other Fedora ARM work, please check out the Fedora > ARM page on the Fedora Wiki². We're also interested in hiring ARM and > Fedora developers to help with this; if you're interested in learning > more, please send an e-mail to jobs-engineer...@laptop.org. > > We'll also be continuing to use Open Firmware on the XO-1.75, and > Mitch Bradley has an ARM port of OFW running on our development boards > already. > > EC-1.75 open source EC code: > > > OLPC is proud to announce that the XO-1.75 embedded controller will > have an open codebase (with a small exception, see below). After much > behind-the-scenes effort, EnE has agreed to provide us with a public > version of the KB3930 datasheet and is allowing our new code to be > made public. > > The code is not available yet due to a few chunks of proprietary code > that need to be purged and some other reformatting. A much more > detailed announcement will be provided once the new code is pushed to > a public repository. The code will be licensed under the GPL with a > special exception for OLPC use. > > The exception is because EnE has not released the low-level details on > the PS/2 interface in the KB3930, so there will be some code that is > not available -- relative to the codebase this is a very small amount > of code. The GPL licensing exception will allow for linking against > this closed code. We're going to investigate ways to move away from > this code in the future. (As far as we're aware, this will make the > XO-1.75 the first laptop with open embedded controller code!) > > Multi-touch Sugar: > == > > We've begun working on modifications to Sugar to enable touchscreen > and multitouch use (the XO-1.75 will have a touchscreen, as will > future OLPC tablets based on its design), and we'll continue to do so. > The first outcome from this work is Sayamindu Dasgupta's port of the > Meego Virtual Keyboard³ to Sugar -- you can see a screencast of it in > action here⁴. > > It's an exciting time for software development at OLPC. Many thanks > for all of your support and efforts
Re: Uruguay violates GPL by deleting root on OLPCs
Jacob - The Linux kernel question is easy, as it's largely GPL v2; the Fedora one is by no means easy. The Fedora Project maintains a list of software licenses which are considered acceptable for software to be packaged in Fedora. That doesn't mean *all* these licenses are in use in any particular Fedora release, but it does give you a sense of the possibilities. You can find the list, with all 206 "good" software license possibilities (26 of which are GPL variations) at http://fedoraproject.org/wiki/Licensing#SoftwareLicenses - as well as the acceptable documentation licenses. It's a fine list, but the 49th license listed stands out from a crowded pack, and rewards the modest effort required to count up to 49. - Ed On Jul 7, 2010, at 6:23 PM, Chris Ball wrote: > Hi, > >> forgive an honest question that may spark a philosophical debate: >> Since the Linux kernel and Fedora are both licensed under GPL.2, >> how would this violate an unrelated license? (which reading, it >> may or may not...) > > Because it's not true that "Fedora" is licensed under GPLv2 -- > it's licensed under a mix of licenses, including some GPLv3. > > - Chris. > -- > Chris Ball > One Laptop Per Child > ___ > 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: Uruguay violates GPL by deleting root on OLPCs
I agree with you completely. This is bad, it's just not complete TiVoization: "If you insert a USB flash drive or SD card, the boot firmware will only boot from it if the files are tested and cryptographically signed by OLPC." What stops one person of then adding root access again? This will hardly deter theft. Best regards, Tiago On Wed, Jul 7, 2010 at 8:42 PM, John Gilmore wrote: > > Please explain your statement that lack of root violates GPLv3. > Couldn't > > the owner of the system insert a SD card with a developer's version of > > Linux, mount the internal drive of the XO, and tinker with the installed > > packages as root from the external OS? Does GPLv3 expressly mention root > > access? > > The laptops refuse to boot a "developer's version of Linux". They > require a signed kernel and initrd. Some people call this DRM; > it's definitely "TiVoization" (check Wikipedia if you don't know the term). > > > I think Ubuntu disables root logins, but allows sudo access for root > > permissions. Is that a violation of the GPLv3? > > As Eben explained, the GPLv3 doesn't require root, it just requires > that you be provided all the info you need to install modified > software of your choice, in the environment in which the binaries were > shipped. "su" is fine, if documented, and it is. > >John > > PS: Get a clue, folks. This is bigger than OLPC. You've been spoiled > by 50+ years of general purpose computers without cryptographic access > controls. Four big oligopolies (Intel, Microsoft, Hollywood, and NSA) > are all trying to wipe out the general purpose computer and replace it > with one that only allows running "approved" software. They've > jiggered the law to make it illegal to "circumvent" such controls, > even if you own the hardware and all the software is free. All the > Apple products except the Macintosh are already this way (and they > produce more revenue for Apple than the Macintosh), and their > customers have barely noticed or complained. It gets harder in every > generation of iPhones to jailbreak them, even if it was legal; they're > closing in on shipping products that close *all* the exploitable > holes, leaving the buyer totally at Apple's mercy. If even the free > software community shuts up and demurs when one of our flagship > projects locks down the hardware to disallow freedom, why should *any* > evil empire delay going right ahead and screwing every consumer, every > curious questioner, and every tinkerer? > ___ > 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: Removing RTC from Theft-Deterrence
On Wed, Jul 7, 2010 at 6:54 PM, John Watlington wrote: > > On Jul 7, 2010, at 5:07 PM, James Cameron wrote: > >> On Wed, Jul 07, 2010 at 04:57:19PM -0400, C. Scott Ananian wrote: >>> Unfortunately, the software changes required are to EC code, which is >>> difficult for outside contributors to work on. >> >> Yeah, that would be good to change. > > Have you forgotten that Richard and I have been working > to get that changed for XO-1.75 ? Or did we forget to report it ? I hope that XO-1.75 will also have space for a small serial flash on the motherboard then. =) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing RTC from Theft-Deterrence
On Jul 7, 2010, at 5:07 PM, James Cameron wrote: > On Wed, Jul 07, 2010 at 04:57:19PM -0400, C. Scott Ananian wrote: >> Unfortunately, the software changes required are to EC code, which is >> difficult for outside contributors to work on. > > Yeah, that would be good to change. Have you forgotten that Richard and I have been working to get that changed for XO-1.75 ? Or did we forget to report it ? Maybe Richard can update us on the status. Regards, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Announce: OLPC software strategy.
Massive kudos for everything :) Keep up the great work and keep us up to date on those ARM developments. Best regards, Tiago On Wed, Jul 7, 2010 at 11:01 PM, Chris Ball wrote: > Hi, > > Now that the 10.1.1 release for XO-1.5 is out, it's a good time to > talk about OLPC's software strategy for the future. We've got a few > announcements to make: > > XO-1: > = > > OLPC wasn't planning to make a Fedora 11 release of the XO-1 OS, but > a group of volunteers including Steven Parrish, Bernie Innocenti, > Paraguay Educa and Daniel Drake stepped up and produced Fedora 11 XO-1 > builds that follow the OLPC 10.1.1 work. I'm happy to announce that > we're planning on releasing an OLPC-signed version of that work, and > that this release will happen alongside the next XO-1.5 point release > in the coming weeks. So, OLPC release 10.1.2 will be available for > both XO-1 and XO-1.5 at the same time, and will contain Sugar 0.84, > GNOME 2.26 and Fedora 11. We think that offering this fully > interoperable software stack between XO-1 and XO-1.5 laptops will > greatly aid deployments, and we're very thankful to everyone who has > enabled us to be able to turn this XO-1 work into a supported release! > > To prepare for this XO-1 release, we've started working on fixing > some of the remaining bugs in the community F11/XO-1 builds. Paul Fox > recently solved a problem with suspend/resume and wifi in the F11/XO-1 > kernel, which was the largest blocker for a supported release. We'll > continue to work on the remaining bugs, particularly the ones that > OLPC is uniquely positioned to help with. > > The first development builds for this release will be published later > this week. > > XO-1.5: > === > > We'll be continuing to work on XO-1.5 improvements, incorporating > fixes to the "Known Problems" section of the 10.1.1 release notes¹ > into the 10.1.2 release. > > XO-1.75 and beyond: > === > > XO-1.75 software development is underway. Today we're announcing > that we're planning on using Fedora as the base distribution for the > XO-1.75. This wasn't an obvious decision -- ARM is not a release > architecture in Fedora, and so we're committing to help out with that > port. Our reasons for choosing Fedora even though ARM work is needed > were that we don't want to force our deployments to learn a new > distribution and re-write any customizations they've written, we want > to reuse the packaging work that's already been done in Fedora for > OLPC and Sugar packages, and we want to continue our collaboration > with the Fedora community who we're getting to know and work with > well. > > We've started to help with Fedora ARM by adding five new build > machines (lent to OLPC by Marvell; thanks!) to the Fedora ARM koji > build farm, and we have Fedora 12 and Sugar 0.86 running on early 1.75 > development boards. We'd prefer to use Fedora 13 for the XO-1.75, but > it hasn't been built for ARM yet -- if anyone's interested in helping > out with this or other Fedora ARM work, please check out the Fedora > ARM page on the Fedora Wiki². We're also interested in hiring ARM and > Fedora developers to help with this; if you're interested in learning > more, please send an e-mail to jobs-engineer...@laptop.org. > > We'll also be continuing to use Open Firmware on the XO-1.75, and > Mitch Bradley has an ARM port of OFW running on our development boards > already. > > EC-1.75 open source EC code: > > > OLPC is proud to announce that the XO-1.75 embedded controller will > have an open codebase (with a small exception, see below). After much > behind-the-scenes effort, EnE has agreed to provide us with a public > version of the KB3930 datasheet and is allowing our new code to be > made public. > > The code is not available yet due to a few chunks of proprietary code > that need to be purged and some other reformatting. A much more > detailed announcement will be provided once the new code is pushed to > a public repository. The code will be licensed under the GPL with a > special exception for OLPC use. > > The exception is because EnE has not released the low-level details on > the PS/2 interface in the KB3930, so there will be some code that is > not available -- relative to the codebase this is a very small amount > of code. The GPL licensing exception will allow for linking against > this closed code. We're going to investigate ways to move away from > this code in the future. (As far as we're aware, this will make the > XO-1.75 the first laptop with open embedded controller code!) > > Multi-touch Sugar: > == > > We've begun working on modifications to Sugar to enable touchscreen > and multitouch use (the XO-1.75 will have a touchscreen, as will > future OLPC tablets based on its design), and we'll continue to do so. > The first outcome from this work is Sayamindu Dasgupta's port of the > Meego Virtual Keyboard³ to Sugar -- you can see a screencast of it
Re: [Sugar-devel] Announce: OLPC software strategy.
Chris, thanks a lot for the extensive (and exciting!) updates and information, much appreciated:-) Cheers, Christoph Am 08.07.2010 um 00:01 schrieb Chris Ball : > Hi, > > Now that the 10.1.1 release for XO-1.5 is out, it's a good time to > talk about OLPC's software strategy for the future. We've got a few > announcements to make: > > XO-1: > = > > OLPC wasn't planning to make a Fedora 11 release of the XO-1 OS, but > a group of volunteers including Steven Parrish, Bernie Innocenti, > Paraguay Educa and Daniel Drake stepped up and produced Fedora 11 XO-1 > builds that follow the OLPC 10.1.1 work. I'm happy to announce that > we're planning on releasing an OLPC-signed version of that work, and > that this release will happen alongside the next XO-1.5 point release > in the coming weeks. So, OLPC release 10.1.2 will be available for > both XO-1 and XO-1.5 at the same time, and will contain Sugar 0.84, > GNOME 2.26 and Fedora 11. We think that offering this fully > interoperable software stack between XO-1 and XO-1.5 laptops will > greatly aid deployments, and we're very thankful to everyone who has > enabled us to be able to turn this XO-1 work into a supported release! > > To prepare for this XO-1 release, we've started working on fixing > some of the remaining bugs in the community F11/XO-1 builds. Paul Fox > recently solved a problem with suspend/resume and wifi in the F11/XO-1 > kernel, which was the largest blocker for a supported release. We'll > continue to work on the remaining bugs, particularly the ones that > OLPC is uniquely positioned to help with. > > The first development builds for this release will be published later > this week. > > XO-1.5: > === > > We'll be continuing to work on XO-1.5 improvements, incorporating > fixes to the "Known Problems" section of the 10.1.1 release notes¹ > into the 10.1.2 release. > > XO-1.75 and beyond: > === > > XO-1.75 software development is underway. Today we're announcing > that we're planning on using Fedora as the base distribution for the > XO-1.75. This wasn't an obvious decision -- ARM is not a release > architecture in Fedora, and so we're committing to help out with that > port. Our reasons for choosing Fedora even though ARM work is needed > were that we don't want to force our deployments to learn a new > distribution and re-write any customizations they've written, we want > to reuse the packaging work that's already been done in Fedora for > OLPC and Sugar packages, and we want to continue our collaboration > with the Fedora community who we're getting to know and work with > well. > > We've started to help with Fedora ARM by adding five new build > machines (lent to OLPC by Marvell; thanks!) to the Fedora ARM koji > build farm, and we have Fedora 12 and Sugar 0.86 running on early 1.75 > development boards. We'd prefer to use Fedora 13 for the XO-1.75, but > it hasn't been built for ARM yet -- if anyone's interested in helping > out with this or other Fedora ARM work, please check out the Fedora > ARM page on the Fedora Wiki². We're also interested in hiring ARM a > nd > Fedora developers to help with this; if you're interested in learning > more, please send an e-mail to jobs-engineer...@laptop.org. > > We'll also be continuing to use Open Firmware on the XO-1.75, and > Mitch Bradley has an ARM port of OFW running on our development boards > already. > > EC-1.75 open source EC code: > > > OLPC is proud to announce that the XO-1.75 embedded controller will > have an open codebase (with a small exception, see below). After much > behind-the-scenes effort, EnE has agreed to provide us with a public > version of the KB3930 datasheet and is allowing our new code to be > made public. > > The code is not available yet due to a few chunks of proprietary code > that need to be purged and some other reformatting. A much more > detailed announcement will be provided once the new code is pushed to > a public repository. The code will be licensed under the GPL with a > special exception for OLPC use. > > The exception is because EnE has not released the low-level details on > the PS/2 interface in the KB3930, so there will be some code that is > not available -- relative to the codebase this is a very small amount > of code. The GPL licensing exception will allow for linking against > this closed code. We're going to investigate ways to move away from > this code in the future. (As far as we're aware, this will make the > XO-1.75 the first laptop with open embedded controller code!) > > Multi-touch Sugar: > == > > We've begun working on modifications to Sugar to enable touchscreen > and multitouch use (the XO-1.75 will have a touchscreen, as will > future OLPC tablets based on its design), and we'll continue to do so. > The first outcome from this work is Sayamindu Dasgupta's port of the > Meego Virtual Keyboard³ to Sugar -- you can see a screencast of it in > acti
Re: Uruguay violates GPL by deleting root on OLPCs
Hi, > forgive an honest question that may spark a philosophical debate: > Since the Linux kernel and Fedora are both licensed under GPL.2, > how would this violate an unrelated license? (which reading, it > may or may not...) Because it's not true that "Fedora" is licensed under GPLv2 -- it's licensed under a mix of licenses, including some GPLv3. - Chris. -- Chris Ball One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Uruguay violates GPL by deleting root on OLPCs
forgive an honest question that may spark a philosophical debate: Since the Linux kernel and Fedora are both licensed under GPL.2, how would this violate an unrelated license? (which reading, it may or may not...) * Message: 4 Date: Wed, 7 Jul 2010 16:23:55 -0400 From: Martin Langhoff Subject: Re: Uruguay violates GPL by deleting root on OLPCs To: John Gilmore Cc: OLPC Devel ,Sugar Devel ,Bernie Innocenti , mog...@softwarefreedom.org Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 7, 2010 at 3:42 PM, John Gilmore wrote: > The laptops refuse to boot a "developer's version of Linux". ?They > require a signed kernel and initrd. ?Some people call this DRM; > it's definitely "TiVoization" (check Wikipedia if you don't know the term). I think it is a very well understood concept around here. And it is also well understood that not all developers complain about TiVo. Major projects are holding to GPLv2. > As Eben explained, the GPLv3 doesn't require root, it just requires > that you be provided all the info you need to install modified > software of your choice, in the environment in which the binaries were > shipped. ?"su" is fine, if documented, and it is. And I think PATH="~/bin/:$PATH" is fine too :-) > PS: Get a clue, folks. ?This is bigger than OLPC. I understand and value that 'macro' fight, but OLPC, and OLPC deployments are not the enemy. You also need to know that OLPC is about a lot more than just software. We are a very big tent, and we work in some very hard places. Think of explaining this to teachers, or to the parents of children. I can only suggest getting closer to a large real life deployment (not just Uruguay) to get a sense of the challenges we face on the ground in the work we do... and to get a sense of what our who our users actually are. > locks down the hardware to disallow freedom, Let's leave hyperbole for another day. It is a very practical concern -- across the varied world of our deployments *theft* is a very real concern. My personal experience in a very cottoned middle-class environment in latam is that by age 15 everyone in my age group had had something stolen in one way or another -- mostly in relatively low-key muggings. I will be optimistic and hope that 1% of the kids needs root at some point. Most places I go to in latam is about the same -- with of course some exceptions in both directions. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Announce: OLPC software strategy.
Hi, Now that the 10.1.1 release for XO-1.5 is out, it's a good time to talk about OLPC's software strategy for the future. We've got a few announcements to make: XO-1: = OLPC wasn't planning to make a Fedora 11 release of the XO-1 OS, but a group of volunteers including Steven Parrish, Bernie Innocenti, Paraguay Educa and Daniel Drake stepped up and produced Fedora 11 XO-1 builds that follow the OLPC 10.1.1 work. I'm happy to announce that we're planning on releasing an OLPC-signed version of that work, and that this release will happen alongside the next XO-1.5 point release in the coming weeks. So, OLPC release 10.1.2 will be available for both XO-1 and XO-1.5 at the same time, and will contain Sugar 0.84, GNOME 2.26 and Fedora 11. We think that offering this fully interoperable software stack between XO-1 and XO-1.5 laptops will greatly aid deployments, and we're very thankful to everyone who has enabled us to be able to turn this XO-1 work into a supported release! To prepare for this XO-1 release, we've started working on fixing some of the remaining bugs in the community F11/XO-1 builds. Paul Fox recently solved a problem with suspend/resume and wifi in the F11/XO-1 kernel, which was the largest blocker for a supported release. We'll continue to work on the remaining bugs, particularly the ones that OLPC is uniquely positioned to help with. The first development builds for this release will be published later this week. XO-1.5: === We'll be continuing to work on XO-1.5 improvements, incorporating fixes to the "Known Problems" section of the 10.1.1 release notes¹ into the 10.1.2 release. XO-1.75 and beyond: === XO-1.75 software development is underway. Today we're announcing that we're planning on using Fedora as the base distribution for the XO-1.75. This wasn't an obvious decision -- ARM is not a release architecture in Fedora, and so we're committing to help out with that port. Our reasons for choosing Fedora even though ARM work is needed were that we don't want to force our deployments to learn a new distribution and re-write any customizations they've written, we want to reuse the packaging work that's already been done in Fedora for OLPC and Sugar packages, and we want to continue our collaboration with the Fedora community who we're getting to know and work with well. We've started to help with Fedora ARM by adding five new build machines (lent to OLPC by Marvell; thanks!) to the Fedora ARM koji build farm, and we have Fedora 12 and Sugar 0.86 running on early 1.75 development boards. We'd prefer to use Fedora 13 for the XO-1.75, but it hasn't been built for ARM yet -- if anyone's interested in helping out with this or other Fedora ARM work, please check out the Fedora ARM page on the Fedora Wiki². We're also interested in hiring ARM and Fedora developers to help with this; if you're interested in learning more, please send an e-mail to jobs-engineer...@laptop.org. We'll also be continuing to use Open Firmware on the XO-1.75, and Mitch Bradley has an ARM port of OFW running on our development boards already. EC-1.75 open source EC code: OLPC is proud to announce that the XO-1.75 embedded controller will have an open codebase (with a small exception, see below). After much behind-the-scenes effort, EnE has agreed to provide us with a public version of the KB3930 datasheet and is allowing our new code to be made public. The code is not available yet due to a few chunks of proprietary code that need to be purged and some other reformatting. A much more detailed announcement will be provided once the new code is pushed to a public repository. The code will be licensed under the GPL with a special exception for OLPC use. The exception is because EnE has not released the low-level details on the PS/2 interface in the KB3930, so there will be some code that is not available -- relative to the codebase this is a very small amount of code. The GPL licensing exception will allow for linking against this closed code. We're going to investigate ways to move away from this code in the future. (As far as we're aware, this will make the XO-1.75 the first laptop with open embedded controller code!) Multi-touch Sugar: == We've begun working on modifications to Sugar to enable touchscreen and multitouch use (the XO-1.75 will have a touchscreen, as will future OLPC tablets based on its design), and we'll continue to do so. The first outcome from this work is Sayamindu Dasgupta's port of the Meego Virtual Keyboard³ to Sugar -- you can see a screencast of it in action here⁴. It's an exciting time for software development at OLPC. Many thanks for all of your support and efforts! - Chris, on behalf of the OLPC Engineering team. Footnotes: ¹: http://wiki.laptop.org/go/Release_notes/10.1.1 ²: http://fedoraproject.org/wiki/Architectures/ARM ³: http://gitorious.org/fvkbd ⁴: http://dev.laptop.org/~sayami
Re: USB2VGA adapters on XO-1.5 (and XO-1 with F11 images)
On Wed, Jul 7, 2010 at 5:21 PM, C. Scott Ananian wrote: > Might try some of the VNC encoding options, like those at: Yes but no. The documentation doesn't match actual outcomes. Raw segfaults in ugly ways. > This is a feature of vnc -- since the "remote system" cursor may lag Been using VNC for a good number of years :-) -- found a way to disable it but the cursor handling is *very* buggy. I've updated the script today after a bit of testing and fiddling. This probably needs a real VNC expert that can chase / file some bugs... cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Uruguay violates GPL by deleting root on OLPCs
Ed, Thanks for helping me to understand the context here. Brett is certainly the right person at FSF. I'm happy to do anything I can to help further the conversation, and am always available to answer any questions anyone may have. Best regards, Eben On Wednesday, 7 July 2010, Ed McNierney wrote: Eben - Hi; thanks. Chris Ball and I had some correspondence with Brett Smith a few months ago in order to make some introductions and get the FSF and Plan Ceibal talking. It seems that that didn't quite happen, and we've asked Martin Langhoff (who's responsible for OLPC technical work with Plan Ceibal) to pick up the ball and try again. If Brett's not the right person to do that, just let Martin know. - Ed Ed McNierney CTO / VP of Engineering One Laptop per Child e...@laptop.org +1 (978) 761-0049 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Announcing the OLPC OS 10.1.1 final release!
Hi, I'm very pleased to announce build os206 as the final 10.1.1 release build for XO-1.5 laptops. Here are its release notes: http://wiki.laptop.org/go/Release_notes/10.1.1 Instructions for installing the release on an XO-1.5 can be found at: http://wiki.laptop.org/go/Release_notes/10.1.1#Installation Many thanks to everyone who contributed to this release! - Chris. -- Chris Ball One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: USB2VGA adapters on XO-1.5 (and XO-1 with F11 images)
On Fri, Jul 2, 2010 at 4:53 PM, Martin Langhoff wrote: > - It is slow and laggy. A VNC protocol expert may be able to help us > optimise... Might try some of the VNC encoding options, like those at: http://www.realvnc.com/products/free/4.1/winvncviewer.html#ColorEncoding Assuming you're using a Unix domain or localhost socket, the "raw" encoding might be best, with # colors matched to the source/dest. > - If you look carefully, the mirror session has a small square cursor > in the middle of the screen. We need a variant on > http://wiki.x.org/wiki/AdvancedTopicsFAQ#Iwanttomakethemousecursorinvisible > but I could not make it work. Given how the technique works, I think > vncviewer is overriding the root window cursor. This is a feature of vnc -- since the "remote system" cursor may lag your local cursor, VNC represents your local cursor with a small box, so that any mismatch between local and remote cursors is obvious and visible. The "UseLocalCursor" option to VNC should affect this. (You also might want to look into AutoReconnect.) I'm using the names of the options in the "official" vnc viewer, but I think the open source ones have the same options, maybe spelled somewhat differently. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing RTC from Theft-Deterrence
On Wed, Jul 07, 2010 at 04:57:19PM -0400, C. Scott Ananian wrote: > Unfortunately, the software changes required are to EC code, which is > difficult for outside contributors to work on. Yeah, that would be good to change. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: USB2VGA adapters on XO-1.5 (and XO-1 with F11 images)
On Fri, Jul 2, 2010 at 4:53 PM, Martin Langhoff wrote: > 2 - From http://dev.laptop.org/~martin/usbvga/ grab > > xorg-xo1.5-dcon.conf - goes into /etc/X11/ > olpc-usbvgamirror - goes into /usr/bin/ - mark it executable! > 95-usbvga.rules - goes into /etc/udev/rules.d Updated olpc-usbvgamirror with tweaks for better performance. It still drops off after a while -- with no errors to speak of in any log, which is weird. All processes still running, all looks smooth but there's no VGA output. Odd. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing RTC from Theft-Deterrence
On Wed, Jul 7, 2010 at 4:01 PM, C. Scott Ananian wrote: > * Updating exactly every hour is vulnerable to an attacker who > arranges to remove the battery from the machine exactly 55 minutes > after power on, every time. This is still quite awkward, but to avoid > even this attack, the EC can pseudo-randomly decide exactly when to > update the EC based on a random seed passed in from OFW from the > Geode's HWRNG, with an *average* interval of an hour. We probably > don't have to perform this extra trickery if we just shorten the > interval to 6 minutes or so, but the means that the EC's EEPROM will > wear out at the end of the 5 year service life of the machine. We can > probably detect this condition (EEPROM no longer writes reliably) and > just disable passive kill security at this point, though, which might > be nice for freedom-loving reasons. 2010 thoughts: I like the idea of pseudo-random updates. Having a uniform 1/60 probability of update every minute makes powering off as a circumvention mechanism pointless, while reducing EEPROM writes. A very simple linear feedback shift register for generating pseudo-random bits would be sufficient, since the inputs and outputs of the system are hidden. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On Wed, Jul 7, 2010 at 2:16 AM, Aleksey Lim wrote: > On Wed, Jul 07, 2010 at 01:18:04AM -0400, Michael Stone wrote: >> Bernie wrote: >> On Tue, 2010-07-06 at 12:02 -0400, Benjamin M. Schwartz wrote: >> >> I think you are missing an important requirement: installation without >> >> elevated permissions. >> > >> > Rainbow has been bit-rotting for the past 2 years >> >> Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and >> still >> received no independent testing despite repeated calls for same. >> >> Rainbow, on the other hand, has seen a major new release, feature development >> that spurred new work in general Linux sandboxing, and is now available in >> more >> distributions than ever before thanks to dedicated support by folks like >> Luke, >> Sascha, and Jonas. >> >> Finally, if rainbow itself now receives little day-to-day attention, this is >> because it mostly does what its authors require and it does it well enough >> not >> to require their continued hand-holding. > > To be honest I wasn't a fan of rainbow a bit time ago.. > But having Zero Sugar fully implemented and potential possibility to launch > almost any piece of software - compile on demand is a regular workflow within > 0install (existed sugar doesn't not let such possibility:), rainbow should > be more then essential requirement. I took some time to read up on 0install -- very impressive technology, good work. I agree with Michael that this (userland installs) is the direction Sugar should be pursuing. With rainbow (or other sandbox) integration, this would accomplish all of the original goals with a much more robust packaging and dependency system than the .xo bundle. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing RTC from Theft-Deterrence
On Wed, Jul 7, 2010 at 4:48 PM, John Watlington wrote: > On Jul 7, 2010, at 4:01 PM, C. Scott Ananian wrote: > >> Since "RTC security" is being discussed again, I'm going to repost two >> relevant proposals from "the good old days". First: on making >> theft-deterrence a "feature"; then technical details of a $0.16 change >> to remove RTC dependence from the theft-deterrence feature. >> Unfortunately, the specific circuit changes required are XO-1 >> specific; presumably some slightly different version is needed for XO >> 1.5, XO 1.75, etc. I vaguely remember wad saying he managed to make >> this change in hardware at some point; I don't know if corresponding >> software was ever written. > > The EEPROM needed for this was included in early XO-1.5 prototypes, > but was dropped from production due to the lack of software making use > of it. It could be added back to any XO-1.5 SKU for a slight cost increase. Unfortunately, the software changes required are to EC code, which is difficult for outside contributors to work on. (Also some OFW work, but that's available and easily hackable.) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing RTC from Theft-Deterrence
On Jul 7, 2010, at 4:01 PM, C. Scott Ananian wrote: > Since "RTC security" is being discussed again, I'm going to repost two > relevant proposals from "the good old days". First: on making > theft-deterrence a "feature"; then technical details of a $0.16 change > to remove RTC dependence from the theft-deterrence feature. > Unfortunately, the specific circuit changes required are XO-1 > specific; presumably some slightly different version is needed for XO > 1.5, XO 1.75, etc. I vaguely remember wad saying he managed to make > this change in hardware at some point; I don't know if corresponding > software was ever written. The EEPROM needed for this was included in early XO-1.5 prototypes, but was dropped from production due to the lack of software making use of it. It could be added back to any XO-1.5 SKU for a slight cost increase. Regards, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Uruguay violates GPL by deleting root on OLPCs
Eben - Hi; thanks. Chris Ball and I had some correspondence with Brett Smith a few months ago in order to make some introductions and get the FSF and Plan Ceibal talking. It seems that that didn't quite happen, and we've asked Martin Langhoff (who's responsible for OLPC technical work with Plan Ceibal) to pick up the ball and try again. If Brett's not the right person to do that, just let Martin know. - Ed Ed McNierney CTO / VP of Engineering One Laptop per Child e...@laptop.org +1 (978) 761-0049 On Jul 7, 2010, at 12:47 PM, Eben Moglen wrote: > I don't know what the technical details are, but it sounds as though > the right people are present in the conversation. For GPLv3 > programs-- which would include bash, tar, and Samba as well as the > toolchain, to take some examples--the requirement is for "installation > information" to be provided to anyone who requests or receives source > code. Installation information is defined as "any methods, > procedures, authorization keys, or other information required to > install and execute modified versions of a covered work in [the > laptop] from a modified version of its Corresponding Source." That > requirement can be satisfied, for some programs, by informing the user > how to run a replacement copy, without root privilege, out of the > primary user's home directory. Some programs might require escalated > privileges in order to install and run a modified version (of a > daemon, for example). Side-stepping the OS on the hard drive, booting > a system on removable media, and then installing the new version on > the fixed disk would be a "method" within the meaning of the license > in those cases. > > Details are crucial. Working with relevant parties to ensure > compliance is SFLC's purpose in a situation such as this. We'd be > happy to help if there is interest. > > Regards, > Eben > > ___ > 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: [Sugar-devel] Clocks on XOs
On Sat, Jul 3, 2010 at 9:54 AM, Bernie Innocenti wrote: >> NetworkManager used to call ntpdate when it setup a connection. Was that an >> OLPC addition? Yes, although it's now present in litl's software builds as well. > We figured out that the ntp package has never been present on the XO > images. It was ntpdate, which was smaller than the whole ntp package. > There's no way to practical way to implement effective anti-theft > without taking away root from the user. And once we take away root > access, we've also taken away olpc's principle #1: child ownership. See my recent message on this topic. Apart from the hardware fix (which avoids RTC dependency altogether), it is also possible to separate most of root's authority from the RTC priviledge. Installing software, for example, requires root access to the filesystem, but not access to the RTC. >> What are the school servers doing to keep their clocks reasonable? > > They're using ntp, with the Fedora pool of ntp servers. You should probably apply for your own pool: http://www.pool.ntp.org/en/vendors.html#open-source It's pretty painless, and makes you a better netizen. >> > Why aren't we using ntp? >> >> ntp is probably overkill for XOs. Besides, who would want to give up that >> much ram? On top of that, ntpd doesn't get along with power saving mode. That's why you use ntpdate. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Uruguay violates GPL by deleting root on OLPCs
On Wed, Jul 7, 2010 at 3:42 PM, John Gilmore wrote: > The laptops refuse to boot a "developer's version of Linux". They > require a signed kernel and initrd. Some people call this DRM; > it's definitely "TiVoization" (check Wikipedia if you don't know the term). I think it is a very well understood concept around here. And it is also well understood that not all developers complain about TiVo. Major projects are holding to GPLv2. > As Eben explained, the GPLv3 doesn't require root, it just requires > that you be provided all the info you need to install modified > software of your choice, in the environment in which the binaries were > shipped. "su" is fine, if documented, and it is. And I think PATH="~/bin/:$PATH" is fine too :-) > PS: Get a clue, folks. This is bigger than OLPC. I understand and value that 'macro' fight, but OLPC, and OLPC deployments are not the enemy. You also need to know that OLPC is about a lot more than just software. We are a very big tent, and we work in some very hard places. Think of explaining this to teachers, or to the parents of children. I can only suggest getting closer to a large real life deployment (not just Uruguay) to get a sense of the challenges we face on the ground in the work we do... and to get a sense of what our who our users actually are. > locks down the hardware to disallow freedom, Let's leave hyperbole for another day. It is a very practical concern -- across the varied world of our deployments *theft* is a very real concern. My personal experience in a very cottoned middle-class environment in latam is that by age 15 everyone in my age group had had something stolen in one way or another -- mostly in relatively low-key muggings. I will be optimistic and hope that 1% of the kids needs root at some point. Most places I go to in latam is about the same -- with of course some exceptions in both directions. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Clocks on XOs
On Tue, Jul 06, 2010 at 04:36:55PM -0600, Daniel Drake wrote: > > > PS: I just found yet another laptop which won't activate because the > > clock was set to 15 July 2000 (not 2010!). Do you see many of these? > > This was probably a human error in the Fix_clock repair process that > happened on that laptop. from my understanding of the 'fix clock'/rtc issue, the clock would go back to about 1970? and not something as recent as 2000. -- | .''`. == Debian GNU/Linux ==.| http://kevix.myopenid.com..| | : :' : The Universal OS| mysite.verizon.net/kevin.mark/.| | `. `' http://www.debian.org/.| http://counter.li.org [#238656]| |___`-Unless I ask to be CCd,.assume I am subscribed._| ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Uruguay violates GPL by deleting root on OLPCs
I don't know what the technical details are, but it sounds as though the right people are present in the conversation. For GPLv3 programs-- which would include bash, tar, and Samba as well as the toolchain, to take some examples--the requirement is for "installation information" to be provided to anyone who requests or receives source code. Installation information is defined as "any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in [the laptop] from a modified version of its Corresponding Source." That requirement can be satisfied, for some programs, by informing the user how to run a replacement copy, without root privilege, out of the primary user's home directory. Some programs might require escalated privileges in order to install and run a modified version (of a daemon, for example). Side-stepping the OS on the hard drive, booting a system on removable media, and then installing the new version on the fixed disk would be a "method" within the meaning of the license in those cases. Details are crucial. Working with relevant parties to ensure compliance is SFLC's purpose in a situation such as this. We'd be happy to help if there is interest. Regards, Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Clocks on XOs
On Tue, Jul 06, 2010 at 05:03:02PM -0400, Bernie Innocenti wrote: > > PS: I just found yet another laptop which won't activate because the > clock was set to 15 July 2000 (not 2010!). Do you see many of these? just a query as I dont know the details of activation: if the rtc is off by a year or more (10 year?) the laptop will not activte using the required activation lease key? so the rtc must be up-to-date to use an activation lease key? -- | .''`. == Debian GNU/Linux ==.| http://kevix.myopenid.com..| | : :' : The Universal OS| mysite.verizon.net/kevin.mark/.| | `. `' http://www.debian.org/.| http://counter.li.org [#238656]| |___`-Unless I ask to be CCd,.assume I am subscribed._| ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Removing RTC from Theft-Deterrence
Since "RTC security" is being discussed again, I'm going to repost two relevant proposals from "the good old days". First: on making theft-deterrence a "feature"; then technical details of a $0.16 change to remove RTC dependence from the theft-deterrence feature. Unfortunately, the specific circuit changes required are XO-1 specific; presumably some slightly different version is needed for XO 1.5, XO 1.75, etc. I vaguely remember wad saying he managed to make this change in hardware at some point; I don't know if corresponding software was ever written. Note that the principle here is that OFW and the EC are the only "protected code" in the system, and the only pieces which must be protected from unauthorized update/modification. The EC is a separate processor running its program independent of OS interference, and so is the perfect place "on which to stand" to implement a security system. Computation capabilities in the EC are limited, so any lease validation, cryptography, etc, is done in OFW on the main processor in the protected run time before the OS boots. Once the OS boots we don't expect any additional trusted computation to be done on the main processor. --scott -- Forwarded message -- From: C. Scott Ananian Date: Fri, Oct 17, 2008 at 3:11 PM Subject: 9.1 Proposal: Improving antitheft To: Devel List , sugar I'd like our antitheft support to be more of a "feature" which G1G1 users could elect to enable, if they like. This involved making it much more visible and configurable, most likely putting it in the control panel. The idea is if you are taking a trip or leaving home for a few days, you could "turn on theft-deterrence" before you go, get some added tracking/remote-kill features, and then turn it off later when you get home. Other topics: * ECO fix and EC improvements * Security control panel, with "am I stolen" and lease renewal buttons: ticket #1502, ticket #6428 * olpcrd work: ticket #7397 * Revoke root capabilities when booted with security enabled: ticket #7562 --scott -- Forwarded message -- From: C. Scott Ananian Date: Tue, Jul 15, 2008 at 1:40 PM Subject: Re: EC EEPROM security mod. To: John Watlington , Richard Smith , techteam Context for tech team: working on a minimal hardware fix that would provide enough "protected real-time clock" functionality that we could enable root and still believe in passive kill for theft-deterrence. Proposed hardware ECO: a) depopulate D31 b) add Microchip 24LC00T/OT (SOT-23 package), wiring: pin 1 (SCL) to SPIWP# (EC GPIOEC) pin 2 (Vss) to ground pin 3 (SDA) to EC_WP# (EC GPIOE0) pin 4 is n/c pin 5 (Vcc) to 3VPCU The 24LC00 part is less than $0.16 in quantity (maybe less from a Chinese source, there are lots of equivalent parts), some tiny fraction of which would be recouped by eliminating D31. This gives us 128 bits of nonvolatile storage accessible only via the EC. We use this to backstop the RTC to prevent clock replay attacks as follows: * At boot time, OFW asks the EC to read the EEPROM and takes max(RTC time, EC time) as its notion of "current time" when evaluating the validity of leases. [2010 edit: may want to completely ignore RTC instead, so that lease isn't shortened by accidentally setting RTC ahead too far in the future.] * At the point where OFW disables writes to the SPI flash, it also asks the EC to write the calculated "current time" back to its own EEPROM. Writes to the EEPROM after this point are disabled. * About once an hour (although it can be as frequently as every six minutes and still stay within the rated erase cycles of the EEPROM) the EC increments the EEPROM's value of time with its own notion of how much time has passed. We will probably deliberately calibrate this to be just shy of "real time" so the EC clock never runs faster than real time. (Details below.) The EEPROM is not accessible except via the EC, and no kernel commands can cause the EC to either avoid updating or misupdate its internal EEPROM. This allows us to give root priviledges to code running on the main processor without affecting the security of the passive kill system, addressing the major weakness in the current system. Lease times are more properly thought of in terms of "powered up time", not "real time", but they still perform their intended purpose. In my copious free time, I'll try to perform this ECO on a spare machine and hack up some EC code to drive it to prove the concept. --scott Details for the strong-hearted: * Updating exactly every hour is vulnerable to an attacker who arranges to remove the battery from the machine exactly 55 minutes after power on, every time. This is still quite awkward, but to avoid even this attack, the EC can pseudo-randomly decide exactly when to update the EC based on a random seed passed in from OFW from the Geode's HWRNG, with an *average* interval of an hour. We probably don't have to perform this extra
Re: Uruguay violates GPL by deleting root on OLPCs
> Please explain your statement that lack of root violates GPLv3. Couldn't > the owner of the system insert a SD card with a developer's version of > Linux, mount the internal drive of the XO, and tinker with the installed > packages as root from the external OS? Does GPLv3 expressly mention root > access? The laptops refuse to boot a "developer's version of Linux". They require a signed kernel and initrd. Some people call this DRM; it's definitely "TiVoization" (check Wikipedia if you don't know the term). > I think Ubuntu disables root logins, but allows sudo access for root > permissions. Is that a violation of the GPLv3? As Eben explained, the GPLv3 doesn't require root, it just requires that you be provided all the info you need to install modified software of your choice, in the environment in which the binaries were shipped. "su" is fine, if documented, and it is. John PS: Get a clue, folks. This is bigger than OLPC. You've been spoiled by 50+ years of general purpose computers without cryptographic access controls. Four big oligopolies (Intel, Microsoft, Hollywood, and NSA) are all trying to wipe out the general purpose computer and replace it with one that only allows running "approved" software. They've jiggered the law to make it illegal to "circumvent" such controls, even if you own the hardware and all the software is free. All the Apple products except the Macintosh are already this way (and they produce more revenue for Apple than the Macintosh), and their customers have barely noticed or complained. It gets harder in every generation of iPhones to jailbreak them, even if it was legal; they're closing in on shipping products that close *all* the exploitable holes, leaving the buyer totally at Apple's mercy. If even the free software community shuts up and demurs when one of our flagship projects locks down the hardware to disallow freedom, why should *any* evil empire delay going right ahead and screwing every consumer, every curious questioner, and every tinkerer? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Eben Moglen: Re: Uruguay violates GPL by deleting root on OLPCs
[I didn't see a copy of this come through on devel, so assumed that it bounced because he's not a recipient. --gnu] Date: Wed, 7 Jul 2010 12:47:26 -0400 To: martin.langh...@gmail.com, g...@toad.com, ber...@codewiz.org, devel@lists.laptop.org, sugar-de...@lists.sugarlabs.org Subject: Re: Uruguay violates GPL by deleting root on OLPCs In-Reply-To: Martin Langhoff's message of Wed, 07 Jul 2010 11:21:27 -0400 From: Eben Moglen I don't know what the technical details are, but it sounds as though the right people are present in the conversation. For GPLv3 programs-- which would include bash, tar, and Samba as well as the toolchain, to take some examples--the requirement is for "installation information" to be provided to anyone who requests or receives source code. Installation information is defined as "any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in [the laptop] from a modified version of its Corresponding Source." That requirement can be satisfied, for some programs, by informing the user how to run a replacement copy, without root privilege, out of the primary user's home directory. Some programs might require escalated privileges in order to install and run a modified version (of a daemon, for example). Side-stepping the OS on the hard drive, booting a system on removable media, and then installing the new version on the fixed disk would be a "method" within the meaning of the license in those cases. Details are crucial. Working with relevant parties to ensure compliance is SFLC's purpose in a situation such as this. We'd be happy to help if there is interest. Regards, Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Anti-theft vs RTC (Was Re: NetworkManager time sync)
On Tue, Jul 6, 2010 at 2:32 PM, Hal Murray wrote: > It's probably possible to make the anti-theft stuff significantly more robust > in this area. I think it would be a lot of work. Yes. Much more work than mere conversation. Are you planning to hack on this? Moving a good chunk of olpc-update-query logic into the initramfs could be something to start. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO 1.5 B2 Died On Me
No, you should send it back to us with minimal opening (you can keep the SD card if you have data on it you want.) We'll send a replacement. Please reply with an address via private email. Cheers! wad On Jul 7, 2010, at 8:41 AM, Tiago Marques wrote: > Hi all, > > Renaming this thread to see if I can get the message through. Message below. > > Best regards, > Tiago > > -- Forwarded message -- > From: Tiago Marques > Date: Mon, Jul 5, 2010 at 3:13 PM > Subject: Re: F11-for-XO1.5 Release 10.1.1 Release Candidate 4- Hardware issue? > To: Yioryos Asprobounitis > Cc: Devel > > > Hi all, > > My XO-1.5 B2 just entered this state last night. The only difference is that > I was using it, writing e-mail, and then it rebooted itself. After that it > would no longer boot so I tried to run memtest. It crashed on the second test > with a random character on the right side of the screen and then it would no > longer boot, the screen just flashes. > > Should I disassemble it to inspect it? I have some experience repairing > motherboards with cold solders, bad caps, etc. > > Best regards, > Tiago > > > On Thu, Jul 1, 2010 at 5:03 PM, Yioryos Asprobounitis > wrote: > I doubt is related to the build but just in case... > I clean installed os205 on an a working XO-1.5 (#SHC00500908). > On first boot it froze about 4sec into the boot process, I think at "loading > mass storage devices" or something relevant. > On hard reboot (with power button for 5sec) the backlight blinks for a split > second but the screen stays dark. The power light comes on but not the > processor and wifi lights. No chime either. > Reseting the EC by battery removal, get the familiar blinks but no change in > behavior. > Is the XO-1.5 bricked? > Is there anything that I can do (replace micro-sd? make sure screen ribbon is > fine? other?). > Any ideas > Thx > > > > > --- On Wed, 6/30/10, Chris Ball wrote: > > > From: Chris Ball > > Subject: F11-for-XO1.5 Release 10.1.1 Release Candidate 4 > > To: "Fedora OLPC" > > Cc: test...@lists.laptop.org, "Devel" > > Date: Wednesday, June 30, 2010, 7:28 PM > > http://wiki.laptop.org/go/F11_for_1.5 > > http://build.laptop.org/10.1.1/os205 > > > > Compressed image size: 705.45mb (+0.16mb since build 204) > > > > This is the fourth RC build for the 10.1.1 release. > > Changes: > > > > * #10186: Fix permissions problem on /home/olpc > > * #10175: Fix "Record-81 generates audio/ogg file > > with silent start" > > * #10183: Fix "Record-82 crashes while saving a > > just-recorded audio clip > > * #9112: Fix "Enable Browse to embed PDF > > files in itself" regression > > > > ___ > > olpc mailing list > > o...@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/olpc > > > > > > > ___ > 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
Rainbow
On Wed, 2010-07-07 at 01:18 -0400, Michael Stone wrote: > > XO and SoaS distributions are configured for sudo with no password. > > Yes. However, Uruguay does not maintain this configuration choice. I'm very sorry about this. > > Rainbow has been bit-rotting for the past 2 years > > Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and still > received no independent testing despite repeated calls for same. Raul and I would have liked to resurrect Rainbow in time for F11-0.84, and then for F11-0.88. We asked a couple of times about the current packaging status and what patches still need to be applied in Sugar, but it seemed that there was still too much integration work to be done. > > and nobody volunteered to work on it. > > If you check the dates carefully, you'll find that most of my recent work on > rainbow and rainbow/sugar integration has occurred while I was on vacation > from > my real job. So please do count that as "volunteer hours". Don't get me wrong, your volunteer work to enhance Rainbow is much appreciated, but it is not by itself sufficient to get Rainbow to work again with Sugar. There seems to be the need for someone who'd be willing to do the missing integration work. People with both Sugar and Rainbow expertise aren't that common. > Sure. And if, by some miracle, Sugar ever becomes *worth* attacking [1], then > we will all rue the day when we had the opportunity to make it safe and chose > not to. I wouldn't worry very much: the attack surface of Sugar from the public Internet is very small: basically, just xulrunner. The LAN of an elementary school is relatively free of advanced crackers. This leaves out only unusual Sugar instances that are being used from home networks connected directly to the Internet. The worst attack vector I can think of would be a malicious activity. I think this is pretty much the same threat of malicious Firefox plugins, and it is being taken care of exactly in the same way. If it becomes Perhaps I'm not being paranoid enough... but anyway, if the situation worsens, we could always restore Rainbow and/or check gpg signatures on installation, like most Linux distros do. > > A non-privileged account can already effectively do anything that a spammer > > would like to do. > > And when will you be shipping my prctl(PR_DISABLENETWORK) kernel patch? > > (Or have you a better approach?) I thought the review got swamped on lkml a long time ago? Or maybe I was dropped off the cc list... Last thing I know, there was disagreement about what the correct approach was and some linux hackers derailed the thread by invoking the stackable LSM bullshit. What matters the most is that nobody thought that the scenario that your patch was trying to address wasn't an interesting one. You might have a chance to get *some* version of your patch approved if you aggressively reply to the nonsense reviews asking the reviewer: - how would you do it instead? - does your alternative effectively address my use-case? - you and X sent conflicting feedback, please sort it out among yourselves and let me know which approach is preferred - who is the authoritative maintainer to ack a patch like this? In a case like yours, the technical side of getting the patch right is very easy compared to mediating among conflicting design goals. > I am still much more satisfied with the approach taken by 0install. [2] 0install is a huge leap forward compared to the crap xo bundle format, but still too much prototypal to cover half of our requirements. The biggest flaw is that there's no well-defined build system to obtain binaries from sources, so activities authors would have to setup multiple environments and build manually for all the architectures we intend to support. When you add a new architecture, it takes months or years before most activities become available for it. I've been advocating a proper build cluster for years. Now that OLPC is working on an ARM-based platform, it will be clear to anyone why it was needed. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NetworkManager time sync
On Wed, Jul 7, 2010 at 12:20 PM, Martin Langhoff
wrote:
> On Mon, Jul 5, 2010 at 11:52 PM, Daniel Drake wrote:
>> While we have your attention on this topic...
>> Do you not think that this is a security issue? In that a thief could
>> put a laptop on a network with rigged DNS and have control over the
>> time/date on the laptop?
>
> We *really* have to get OFW clock checks working -- then this
> disappears as an issue. I really want to be able to use ntp (at least
> ntpdate on NM successful connect). The OATS clock sync is very rough
> -- on purpose.
I believe my proposal was to use OFW protected execution to replace
"trust the RTC clock" -- which is pretty daft, even if theoretically
vserver would let you isolate that priviledge domain -- with having
OFW keep a monotonically increasing counter of CPU time (not "real
time"). Theft-deterrence leases would be then good for a certain
amount of CPU time, and you can screw with your RTC all you like.
("CPU time" is also guaranteed to increase by some amount on every
boot, so the lease also roughly limits "number of boots".)
I think wad said he managed to squeeze the hardware to enable this
into the latest generation, but I don't know if the support was ever
fully integrated. It's mostly a OFW/EC hack, since all the privileged
code is removed from the OS in this case.
--scott
--
( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: NetworkManager time sync
On Mon, Jul 5, 2010 at 11:52 PM, Daniel Drake wrote: > While we have your attention on this topic... > Do you not think that this is a security issue? In that a thief could > put a laptop on a network with rigged DNS and have control over the > time/date on the laptop? We *really* have to get OFW clock checks working -- then this disappears as an issue. I really want to be able to use ntp (at least ntpdate on NM successful connect). The OATS clock sync is very rough -- on purpose. Apparently the ntp protocol supports some server-signing of the messages -- we could use an OATS key for that. But it looks rickety. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Uruguay violates GPL by deleting root on OLPCs
On Wed, Jul 7, 2010 at 5:32 AM, John Gilmore wrote: > Shipping the laptops without root access is a direct violation of the > GPLv3 license on a dozen packages (probably 50+ packages in later While I understand and agree with the spirit of what John wants, "direct violation" is a strong thing to say. Is it true? If you can get the src, compile and install and use the GPLv3 software. A quick check of "old" official images that I have around shows very few gplv3 packages, all of them things that I can easily recompile and put in my ~/bin, tweak my PATH envvar, and use from there. > these scofflaws These scofflaws are trying to protect kids from theft, John. Userbase 6 to 12 years old. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Clocks on XOs
On Tue, Jul 6, 2010 at 10:14 PM, Bernie Innocenti wrote: >> And that there are efforts to solve that in the future. > > Oh, I was unaware of this. Who is working on it, and what's the exact > plan? http://dev.laptop.org/ticket/9564 Now, folks, please be careful here with all the exaggeration and drama. This list is full of people who don't understand humour or exaggeration. And who don't necesarily understand that security is never absolute, never perfect. Our antitheft scheme doesn't work in a vacuum -- it only works as a social device, to strongly discourage theft and grey-market sales. Tradeoffs is what it's all about. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Moodle is disabled at the moment - Any Possible Solution
Hi Hasikala, apologies for the delay -- your msg got caught in the "message moderation" system. Hope my response is still useful somehow... On Sat, Jun 5, 2010 at 7:34 AM, Hasikala Anuruddhi wrote: > We are fourth year students of University of Colombo School of Computing > ,following Information and Communication Technology degree .Currently we are > developing an Infromation portal for Sri Lanka OLPC project. That's a great project! > We installed XS 0.6 in one location and we retrived a copy of its moodle > instance to a flash drive.Then we installed that moodle instance in xampp in > a windows machine.When we accessing the moodle through local host it > indicates "moodle is disabled at the moment".We could not find out possible > solutions for the problem. Uh, that will be pretty hard to make work. How did you "retrieve a copy of the moodle instance"? I will be very tricky work to "copy" the data + code from the XS to an 'xampp' setup. What is your end-goal? Maybe there are other ways to achive it that don't involve an xampp setup... cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: Uruguay violates GPL by deleting root on OLPCs
Please explain your statement that lack of root violates GPLv3. Couldn't the owner of the system insert a SD card with a developer's version of Linux, mount the internal drive of the XO, and tinker with the installed packages as root from the external OS? Does GPLv3 expressly mention root access? I think Ubuntu disables root logins, but allows sudo access for root permissions. Is that a violation of the GPLv3? On Wed, Jul 7, 2010 at 2:32 AM, John Gilmore wrote: > > > Ignoring the fact that some deployments ship without root access. > > > > Is the practice of completely locking-down the laptops something we'd > > even want to encourage? > > Shipping the laptops TiVoized like Uruguay does has put them into serious > legal trouble. OLPC should definitely not encourage anybody else to do > this. > Why bankrupt your project by losing a copyright enforcement lawsuit? > > Shipping the laptops without root access is a direct violation of the > GPLv3 license on a dozen packages (probably 50+ packages in later > Fedoras). They have shipped binaries, while using technological means > to deny the recipient the practical ability to upgrade or replace them > with versions modified or chosen by the recipient. > > Only an idiot would distribute hundreds of thousands of units while > setting themselves up to pay the Free Software Foundation any amount > of money they demand. (Given the way OLPC and Uruguay have > ignored the notice that they're in violation, for years, I do hope FSF > extracts both future compliance, and its next ten years of operating > expenses, from these scofflaws.) > > Or does Uruguay think, "Sue us for copyright violation in our own > courts -- we'll make sure you lose"?? In other words, do they > just brazenly steal the GNU Project's software, knowing it's wrong? > >John Gilmore > > ___ > 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: [Server-devel] sample Moodle course
On Tue, Jul 6, 2010 at 12:54 PM, Sameer Verma wrote: > We are putting together a sample course in Moodle to test load > performance of XS on various hardware Cool. You could even use one of the "demo courses" from Moodle. > Is there a place where we can host this and build it up? I would suggest using the "Course Exchange" at Moodle.org -- upload it as a 'course backup' (which is a zipfile). When you have the howto written up in docs.moodle.org, that's where you'll want to have it anyway ;-) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Sugar-devel] Activity packaging
Aleksey wrote: > On Wed, Jul 07, 2010 at 01:18:04AM -0400, Michael Stone wrote: >> Bernie wrote: >> On Tue, 2010-07-06 at 12:02 -0400, Benjamin M. Schwartz wrote: >> >> I think you are missing an important requirement: installation without >> >> elevated permissions. >> > >> > Rainbow has been bit-rotting for the past 2 years >> >> Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and >> still >> received no independent testing despite repeated calls for same. > > To be honest I wasn't a fan of rainbow a bit time ago.. > > But having Zero Sugar fully implemented and potential possibility to launch > almost any piece of software... rainbow should be more then essential > requirement. Let's be clear: the actual requirement is for something more like "safety" or "isolation". Rainbow is merely one of several reasonable approaches -- and competition and interoperability would be no bad thing here. Michael P.S. - Several other isolation shells that might be worth thinking about, if only to better understand the tradeoffs that rainbow makes, are briefly described at http://sandboxing.org P.P.S. - Also, either way, thanks for your encouragement. :) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Uruguay violates GPL by deleting root on OLPCs
Please, when you say Uruguay you should just say Plan Ceibal. Has anyone formally requested Plan Ceibal to correct this situation? Thanks, Gabriel 2010/7/7 John Gilmore : >> > Ignoring the fact that some deployments ship without root access. >> >> Is the practice of completely locking-down the laptops something we'd >> even want to encourage? > > Shipping the laptops TiVoized like Uruguay does has put them into serious > legal trouble. OLPC should definitely not encourage anybody else to do this. > Why bankrupt your project by losing a copyright enforcement lawsuit? > > Shipping the laptops without root access is a direct violation of the > GPLv3 license on a dozen packages (probably 50+ packages in later > Fedoras). They have shipped binaries, while using technological means > to deny the recipient the practical ability to upgrade or replace them > with versions modified or chosen by the recipient. > > Only an idiot would distribute hundreds of thousands of units while > setting themselves up to pay the Free Software Foundation any amount > of money they demand. (Given the way OLPC and Uruguay have > ignored the notice that they're in violation, for years, I do hope FSF > extracts both future compliance, and its next ten years of operating > expenses, from these scofflaws.) > > Or does Uruguay think, "Sue us for copyright violation in our own > courts -- we'll make sure you lose"?? In other words, do they > just brazenly steal the GNU Project's software, knowing it's wrong? > > John Gilmore > > ___ > 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
XO 1.5 B2 Died On Me
Hi all, Renaming this thread to see if I can get the message through. Message below. Best regards, Tiago -- Forwarded message -- From: Tiago Marques Date: Mon, Jul 5, 2010 at 3:13 PM Subject: Re: F11-for-XO1.5 Release 10.1.1 Release Candidate 4- Hardware issue? To: Yioryos Asprobounitis Cc: Devel Hi all, My XO-1.5 B2 just entered this state last night. The only difference is that I was using it, writing e-mail, and then it rebooted itself. After that it would no longer boot so I tried to run memtest. It crashed on the second test with a random character on the right side of the screen and then it would no longer boot, the screen just flashes. Should I disassemble it to inspect it? I have some experience repairing motherboards with cold solders, bad caps, etc. Best regards, Tiago On Thu, Jul 1, 2010 at 5:03 PM, Yioryos Asprobounitis wrote: > I doubt is related to the build but just in case... > I clean installed os205 on an a working XO-1.5 (#SHC00500908). > On first boot it froze about 4sec into the boot process, I think at > "loading mass storage devices" or something relevant. > On hard reboot (with power button for 5sec) the backlight blinks for a > split second but the screen stays dark. The power light comes on but not the > processor and wifi lights. No chime either. > Reseting the EC by battery removal, get the familiar blinks but no change > in behavior. > Is the XO-1.5 bricked? > Is there anything that I can do (replace micro-sd? make sure screen ribbon > is fine? other?). > Any ideas > Thx > > > > > --- On Wed, 6/30/10, Chris Ball wrote: > > > From: Chris Ball > > Subject: F11-for-XO1.5 Release 10.1.1 Release Candidate 4 > > To: "Fedora OLPC" > > Cc: test...@lists.laptop.org, "Devel" > > Date: Wednesday, June 30, 2010, 7:28 PM > > http://wiki.laptop.org/go/F11_for_1.5 > > http://build.laptop.org/10.1.1/os205 > > > > Compressed image size: 705.45mb (+0.16mb since build 204) > > > > This is the fourth RC build for the 10.1.1 release. > > Changes: > > > > * #10186: Fix permissions problem on /home/olpc > > * #10175: Fix "Record-81 generates audio/ogg file > > with silent start" > > * #10183: Fix "Record-82 crashes while saving a > > just-recorded audio clip > > * #9112: Fix "Enable Browse to embed PDF > > files in itself" regression > > > > ___ > > olpc mailing list > > o...@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/olpc > > > > > > > ___ > 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: [Sugar-devel] UI experiments: pop-up menus and hot corners
On Wed, Jul 7, 2010 at 01:39, Bernie Innocenti wrote: > On Tue, 2010-07-06 at 20:06 +0100, Gary Martin wrote: > >> Activity start-up times are significantly better than they used to be, >> so no specific bug that I'm aware of, was just hopeful of any >> opportunities to further improve performance > > On F11-0.88, I often see long startup times. I have some non-conclusive > clues to think on: > > 1) using top from the console, I see the CPU split (50%/50%) between > sugar-session and the loading activity The shell cpu usage looks very bad, I will do some profiling. > 2) activities using 0sugar seem to take forever to run > > 3) Browse and Record are amongst the worst offenders Browse I can believe it's because of mozilla, but Record?? If someone would like to profile I will be glad to give some pointers. Regards, Tomeu > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] UI experiments: pop-up menus and hot corners
On Tue, Jul 6, 2010 at 12:38, Marco Pesenti Gritti wrote: > On 6 Jul 2010, at 04:26, Gary Martin wrote: > >> Pre-rendering is tricky as both stroke/fill colour, and image size are >> variable. > > I think Benjamin had this more or less working at some point, I don't > remember why we didn't land it. The results on the XO-1 weren't conclusive AFAIR (cc'ing Benjamin). Regards, Tomeu > Marco > ___ > 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
Uruguay violates GPL by deleting root on OLPCs
> > Ignoring the fact that some deployments ship without root access. > > Is the practice of completely locking-down the laptops something we'd > even want to encourage? Shipping the laptops TiVoized like Uruguay does has put them into serious legal trouble. OLPC should definitely not encourage anybody else to do this. Why bankrupt your project by losing a copyright enforcement lawsuit? Shipping the laptops without root access is a direct violation of the GPLv3 license on a dozen packages (probably 50+ packages in later Fedoras). They have shipped binaries, while using technological means to deny the recipient the practical ability to upgrade or replace them with versions modified or chosen by the recipient. Only an idiot would distribute hundreds of thousands of units while setting themselves up to pay the Free Software Foundation any amount of money they demand. (Given the way OLPC and Uruguay have ignored the notice that they're in violation, for years, I do hope FSF extracts both future compliance, and its next ten years of operating expenses, from these scofflaws.) Or does Uruguay think, "Sue us for copyright violation in our own courts -- we'll make sure you lose"?? In other words, do they just brazenly steal the GNU Project's software, knowing it's wrong? John Gilmore ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] UI experiments: pop-up menus and hot corners
On Tue, Jul 6, 2010 at 22:00, Mikus Grinbergs wrote: >> Activity start-up times are significantly better than they used to be, so no >> specific bug >> that I'm aware of, was just hopeful of any opportunities to further improve >> performance > > It's my impression that activity start-up times are affected by the > "size" (by that I mean "memory usage") of the activity. If on the XO-1 > I start up a large activity (e.g., Help, TamTamSynth, etc) for the first > time, it takes a number of seconds for me to see the activity's own > screen. Smaller activities (e.g., Bounce, Arithmetic) seem to start > more quickly. The no. 1 factor in python activities is generally the number of modules imported, which could be seen related to the amount of functionality it provides. It also implies more memory usage. Would be interesting to test with newer python releases if it has improved there. Regards, Tomeu > mikus > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
