[Sugar-devel] Fwd: SarynPaint: a Java program packaged for the OLPC
Rafael Ortiz -- Forwarded message -- From: Ben Wiley Sittler Date: Sat, Aug 29, 2009 at 12:29 AM Subject: SarynPaint: a Java program packaged for the OLPC To: OLPC Developer's List A friend of mine wrote a hand/eye coordination game called SarynPaint and recently released the source code. SarynPaint is written in Java, so you'll need to install OpenJDK to use it. I just checked in minimal support for launching it from Sugar and rolled a .xo activity bundle file. The project: http://sarynpaint.googlecode.com/ The activity bundle file: http://sarynpaint.googlecode.com/files/sarynpaint-1.xo How to get OpenJDK: http://wiki.laptop.org/go/Java#Installing_OpenJDK_Java I haven't been able to test that .xo link on an actual OLPC yet, so feel free to pass along bug reports, experiences, etc. So, is there some way I could list the OpenJDK dependency in the activity.info file and have the system offer to download and install OpenJDK if it has not yet been installed? -Ben ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] clash of user- and system-installed activities (was: Release Physics-3)
On Fri, Aug 28, 2009 at 05:53:51PM +0200, Jonas Smedegaard wrote: > On Fri, Aug 28, 2009 at 02:15:29PM +0100, Gary C Martin wrote: > >Hi Dave, > > > >Do you have Physics-2 installed on the SoaS? Depending on the SoaS > >version you have, the early ones had Activities installed in non- > >standard places, with non user permissions, and sometimes symbolic > >links :-( You would need to drop down into terminal, find and remove > >that Physics.activity folder. Then the normal install process should > >work as normal. > > > >FWIW: On old SoaS, my first task would be to drop into the Terminal > >and clean this all up manually, so that all the *.activity directories > >were migrated the expected ~/Activities, and ownership permissions of > >them given back to the user (recursive chown on ~/Activities). In the > >current SoaS activities are installed from their .xo bundles so this > >is no longer an issue :-) > > Is this an issue specific to SoaS and/or Physics, or generally a > limitation of current Sugar that older system-installed Activities > disturb newer user-installed ones? Thats right for <=0.84, if you have system-installed activities you can't upgrade it from .xo but it was fixed in 0.86 http://dev.sugarlabs.org/ticket/701 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Ad-hoc network identification badge
Hi Eben, On 29 Aug 2009, at 04:26, Eben Eliason wrote: > On Fri, Aug 28, 2009 at 5:41 PM, Gary C Martin > wrote: >> On 28 Aug 2009, at 21:51, Eben Eliason wrote: >> >>> On Fri, Aug 28, 2009 at 4:16 PM, Gary C Martin >>> wrote: On 27 Aug 2009, at 22:24, Simon Schampijer wrote: > On 08/27/2009 10:42 PM, Gary C Martin wrote: >> >> Quick ping, >> >> Do we need something like an emblem-buddy.svg for ad-hoc >> network icons >> (e.g. an XO icon used in same way as the star and lock icon are >> used >> to badge AP icons)? Sorry couldn't find a trac ticket or the >> right ML >> thread. >> >> Regards, >> --Gary > > Yeah, I think we settled on a badged AP icon. If you have > something in > mind - please share it with us ;p OK :-) Just tested the buddy icon pretty much as is for an emblem, but it doesn't quite ring true (feels too fussy). Here's a few screen shots: So taking a leaf out of the emblem-locked style and came up with what I think is a much better emblem using a box outline and solid stroke colour for the buddy icon: >>> >>> Yup. I would definitely recommend the (unstroked, as you show it) XO >>> icon within the box, as well. The badge feels just a little high in >>> your mockups (it should be at a 45 degree angle from center, and >>> positioned so that the lower-right corner falls outside the 55px >>> recommended icon region, at (70,70)), but that's just an issue of >>> defining the hotspot correctly. >> >> I copied the existing emblem-locked.svg positioning without falter, >> so >> assume this is the emblem placing code that's a little off (unless >> emblem-locked is wrong). >> >>> Also, all bages are supposed to be >>> black fills with white strokes (and white symbols within the box, >>> eg. >>> the XO itself). I think that never happened because entity support >>> was >>> never added for badges. >> >> Oh, OK. So black box (white stroke?) with white buddy icon (in this >> example) >> is the intention? > > Yup, these look great! Fab :-) >>> Does someone know how to add that so we can fix the badges up? >>> Alternatively, does someone want to update all of the default SVGs >>> for >>> the badges so that they use the correct colors without use of >>> entities? >> >> Well the one's I've looked at have &stroke_color and &fill_color so >> it could >> just be a simple code change I guess (above screen shot was taken >> just by > > Right. I made them with the proper entities, but the code path for > creating the badges isn't tied into the Sugar classes that do the > entity replacement (or something like that). So we'd have to look into > the badging code to see how to hook that up. Understood. >> changing stroke to white, and fill to black). But I can do that in >> each of >> the emblem-*.svg if that's all that is needed, and is easier for >> core devs? > > That seems like a really quick short term fix, so it might be worth > doing, unless a few minutes investigation of the code presents an > obvious solution. Actually, we've honestly never had any designs for > colored badges and I don't anticipate them in the near term, so maybe > supporting entities there is overkill and modifying the SVGs directly > is the right course anyway. OK, sounds like we should just make these svg modifications now, and consider code changes in the future if really needed. I'll go through and adjust each of the svg later tomorrow. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] FSF attitude to xo and sugar
bill wrote: > On Fri, Aug 28, 2009 at 4:35 PM, Bastien wrote: > > > After a discussion with the FSF, they agreed the picture was not really > > appropriate and that the text should clearly distinguish OLPC from Sugar. i'm confused. it's okay to smear olpc, but not sugar?? > > > > They will make an update - stay tuned. > > the picture is gone but the words are still there: > > > As a result, it is expected that the main effect of the OLPC project -- if > > it succeeds -- will be to turn millions of children into Microsoft > > dependents. That is a negative effect, to the point where the world would > > be > > better off if the OLPC project had never existed > > still over zealous, purist and FUD indeed. paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Ad-hoc network identification badge
On Fri, Aug 28, 2009 at 5:41 PM, Gary C Martin wrote: > On 28 Aug 2009, at 21:51, Eben Eliason wrote: > >> On Fri, Aug 28, 2009 at 4:16 PM, Gary C Martin >> wrote: >>> >>> On 27 Aug 2009, at 22:24, Simon Schampijer wrote: >>> On 08/27/2009 10:42 PM, Gary C Martin wrote: > > Quick ping, > > Do we need something like an emblem-buddy.svg for ad-hoc network icons > (e.g. an XO icon used in same way as the star and lock icon are used > to badge AP icons)? Sorry couldn't find a trac ticket or the right ML > thread. > > Regards, > --Gary Yeah, I think we settled on a badged AP icon. If you have something in mind - please share it with us ;p >>> >>> OK :-) Just tested the buddy icon pretty much as is for an emblem, but it >>> doesn't quite ring true (feels too fussy). Here's a few screen shots: >>> >>> So taking a leaf out of the emblem-locked style and came up with what I >>> think is a much better emblem using a box outline and solid stroke colour >>> for the buddy icon: >> >> Yup. I would definitely recommend the (unstroked, as you show it) XO >> icon within the box, as well. The badge feels just a little high in >> your mockups (it should be at a 45 degree angle from center, and >> positioned so that the lower-right corner falls outside the 55px >> recommended icon region, at (70,70)), but that's just an issue of >> defining the hotspot correctly. > > I copied the existing emblem-locked.svg positioning without falter, so > assume this is the emblem placing code that's a little off (unless > emblem-locked is wrong). > >> Also, all bages are supposed to be >> black fills with white strokes (and white symbols within the box, eg. >> the XO itself). I think that never happened because entity support was >> never added for badges. > > Oh, OK. So black box (white stroke?) with white buddy icon (in this example) > is the intention? Yup, these look great! >> Does someone know how to add that so we can fix the badges up? >> Alternatively, does someone want to update all of the default SVGs for >> the badges so that they use the correct colors without use of >> entities? > > Well the one's I've looked at have &stroke_color and &fill_color so it could > just be a simple code change I guess (above screen shot was taken just by Right. I made them with the proper entities, but the code path for creating the badges isn't tied into the Sugar classes that do the entity replacement (or something like that). So we'd have to look into the badging code to see how to hook that up. > changing stroke to white, and fill to black). But I can do that in each of > the emblem-*.svg if that's all that is needed, and is easier for core devs? That seems like a really quick short term fix, so it might be worth doing, unless a few minutes investigation of the code presents an obvious solution. Actually, we've honestly never had any designs for colored badges and I don't anticipate them in the near term, so maybe supporting entities there is overkill and modifying the SVGs directly is the right course anyway. Eben >> Thanks Gary! (For the mockups, that is; I'm not volunteering you for >> the above task). > > Hey, no problem, I've been volunteered for far worse things ;-) > > Regards, > --Gary > > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Read-only access to thumb drive forbidden by Rainbow?
You can isolate Rainbow by disabling it and seeing if the problem goes away.
sudo rm /etc/olpc-security
will disable Rainbow
sudo touch /etc/olpc-security
will reenable it.
-walter
On Fri, Aug 28, 2009 at 10:19 PM, Jim Simmons wrote:
> As I have mentioned in this list before, I am trying to make View
> Slides able to get pictures that may or may not be in the Journal and
> add them to a slide presentation. Under .82 objects in thumb drives
> can be listed using the Data Store API, which was fine. In .84 you
> cannot do that any more, but I was led to believe that if I just
> wanted to READ these files that Python IO would work. So I use this
> code:
>
> valid_endings = ('.jpg', '.jpeg', '.JPEG', '.JPG', '.gif',
> '.GIF', '.tiff', '.TIFF', '.png', '.PNG')
> for dirname, dirnames, filenames in os.walk('/media'):
> for filename in filenames:
> if filename.endswith(valid_endings):
> iter = self.ls_right.append()
> jobject_wrapper = JobjectWrapper()
>
> jobject_wrapper.set_file_path(os.path.join(dirname, filename))
> self.ls_right.set(iter, COLUMN_IMAGE, filename)
> self.ls_right.set(iter, COLUMN_PATH, jobject_wrapper)
>
> Now this code runs just fine on the Sugar test environment of Fedora
> 11 (.84) and Fedora 10 (.82). However, if I try running the same code
> on my XO, currently running .82, the Activity does not even finish
> coming up. Using the Log Activity does not give me any useful
> messages. I can only suspect that Rainbow is the culprit here,
> although I'm not getting any actual messages that say that. It's just
> a guess on my part.
>
> In the code above the jobject_wrapper is a class I created so that my
> table column could hold an object that would return a file path,
> either by getting it from a wrapped journal object or from a path
> supplied by the code above. Works fine in my test environment, but
> bails out on my XO.
>
> Does anyone have any ideas? Thanks,
>
> James Simmons
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Read-only access to thumb drive forbidden by Rainbow?
As I have mentioned in this list before, I am trying to make View
Slides able to get pictures that may or may not be in the Journal and
add them to a slide presentation. Under .82 objects in thumb drives
can be listed using the Data Store API, which was fine. In .84 you
cannot do that any more, but I was led to believe that if I just
wanted to READ these files that Python IO would work. So I use this
code:
valid_endings = ('.jpg', '.jpeg', '.JPEG', '.JPG', '.gif',
'.GIF', '.tiff', '.TIFF', '.png', '.PNG')
for dirname, dirnames, filenames in os.walk('/media'):
for filename in filenames:
if filename.endswith(valid_endings):
iter = self.ls_right.append()
jobject_wrapper = JobjectWrapper()
jobject_wrapper.set_file_path(os.path.join(dirname, filename))
self.ls_right.set(iter, COLUMN_IMAGE, filename)
self.ls_right.set(iter, COLUMN_PATH, jobject_wrapper)
Now this code runs just fine on the Sugar test environment of Fedora
11 (.84) and Fedora 10 (.82). However, if I try running the same code
on my XO, currently running .82, the Activity does not even finish
coming up. Using the Log Activity does not give me any useful
messages. I can only suspect that Rainbow is the culprit here,
although I'm not getting any actual messages that say that. It's just
a guess on my part.
In the code above the jobject_wrapper is a class I created so that my
table column could hold an object that would return a file path,
either by getting it from a wrapped journal object or from a path
supplied by the code above. Works fine in my test environment, but
bails out on my XO.
Does anyone have any ideas? Thanks,
James Simmons
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] FSF attitude to xo and sugar
On Fri, Aug 28, 2009 at 4:35 PM, Bastien wrote: > After a discussion with the FSF, they agreed the picture was not really > appropriate and that the text should clearly distinguish OLPC from Sugar. > > They will make an update - stay tuned. the picture is gone but the words are still there: > As a result, it is expected that the main effect of the OLPC project -- if > it succeeds -- will be to turn millions of children into Microsoft > dependents. That is a negative effect, to the point where the world would be > better off if the OLPC project had never existed still over zealous, purist and FUD ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] windows7sins
On Fri, Aug 28, 2009 at 3:08 AM, Joshua N Pritikin wrote: > I am surprised to read: "As a result, it is expected that the main > effect of the OLPC project -- if it succeeds -- will be to turn millions > of children into Microsoft dependents." > > Some of your other criticisms of OLPC are fair, but this is pure > speculation. Even though there is a Windows XP port to the XO laptop, to > my knowledge, OLPC has not shipped any Windows or dual-boot XOs to > customers. (Or was there a small trial that fizzled?) On the other hand, > OLPC has put free software into more children's hands than any other > project so far. You ought to give them credit for that, at least. Your > interpretation of events seems excessively pessimistic. > > -- > American? Vote on the National Initiative for Democracy, http://votep2.us > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > FSF hasn't done its homework properly. Sameer -- Dr. Sameer Verma, Ph.D. Associate Professor, Information Systems Director, Center for Business Solutions San Francisco State University http://verma.sfsu.edu/ http://cbs.sfsu.edu/ http://is.sfsu.edu/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] FSF attitude to xo and sugar
Thanks! We'd still love for them to come by GPA just for the sheer joy of seeing an entire room of old windows machines shinning with Open Source software. Caroline On Fri, Aug 28, 2009 at 3:05 AM, Bastien wrote: > After a discussion with the FSF, they agreed the picture was not really > appropriate and that the text should clearly distinguish OLPC from Sugar. > > They will make an update - stay tuned. > > Thanks! > > -- > Bastien > -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] FSF attitude to xo and sugar
After a discussion with the FSF, they agreed the picture was not really appropriate and that the text should clearly distinguish OLPC from Sugar. They will make an update - stay tuned. Thanks! -- Bastien ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] OCR?
Edward Cherlin wrote: > Is there a Free Software OCR engine of adequate quality? http://code.google.com/p/tesseract-ocr/ The question is: adequate for what? (A question likely to be answered only by testing.) signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Ad-hoc network identification badge
On 28 Aug 2009, at 21:51, Eben Eliason wrote: On Fri, Aug 28, 2009 at 4:16 PM, Gary C Martin wrote: On 27 Aug 2009, at 22:24, Simon Schampijer wrote: On 08/27/2009 10:42 PM, Gary C Martin wrote: Quick ping, Do we need something like an emblem-buddy.svg for ad-hoc network icons (e.g. an XO icon used in same way as the star and lock icon are used to badge AP icons)? Sorry couldn't find a trac ticket or the right ML thread. Regards, --Gary Yeah, I think we settled on a badged AP icon. If you have something in mind - please share it with us ;p OK :-) Just tested the buddy icon pretty much as is for an emblem, but it doesn't quite ring true (feels too fussy). Here's a few screen shots: So taking a leaf out of the emblem-locked style and came up with what I think is a much better emblem using a box outline and solid stroke colour for the buddy icon: Yup. I would definitely recommend the (unstroked, as you show it) XO icon within the box, as well. The badge feels just a little high in your mockups (it should be at a 45 degree angle from center, and positioned so that the lower-right corner falls outside the 55px recommended icon region, at (70,70)), but that's just an issue of defining the hotspot correctly. I copied the existing emblem-locked.svg positioning without falter, so assume this is the emblem placing code that's a little off (unless emblem-locked is wrong). Also, all bages are supposed to be black fills with white strokes (and white symbols within the box, eg. the XO itself). I think that never happened because entity support was never added for badges. Oh, OK. So black box (white stroke?) with white buddy icon (in this example) is the intention? <><><><> Does someone know how to add that so we can fix the badges up? Alternatively, does someone want to update all of the default SVGs for the badges so that they use the correct colors without use of entities? Well the one's I've looked at have &stroke_color and &fill_color so it could just be a simple code change I guess (above screen shot was taken just by changing stroke to white, and fill to black). But I can do that in each of the emblem-*.svg if that's all that is needed, and is easier for core devs? Thanks Gary! (For the mockups, that is; I'm not volunteering you for the above task). Hey, no problem, I've been volunteered for far worse things ;-) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] OCR?
I've heard good things about OpenCV http://opencv.willowgarage.com/wiki/ though i haven't use it yet. Rafael Ortiz On Fri, Aug 28, 2009 at 3:31 PM, Edward Cherlin wrote: > I was at a presentation last week of Abbyy OCR software, which works > on pictures taken by mobile phone cameras in more than 100 languages. > The company wants to give away software (though not source code) in > was that will get the company good publicity. So we are talking about > using their software with the XO camera to read signs or full pages in > books. Also whether we can add languages. > > This would mean making the OCR engine a separate download, the way we > handle Adobe Flash. > > So is this likely to be worth the effort? > > Is there a Free Software OCR engine of adequate quality? > > Any other questions? > > -- > Edward Mokurai Cherlin > Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name, and > Children are > my nation. The Cosmos is my dwelling place, the Truth my destination. > http://earthtreasury.org/ > ___ > IAEP -- It's An Education Project (not a laptop project!) > i...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] clash of user- and system-installed activities (was: Release Physics-3)
On Fri, Aug 28, 2009 at 10:15:09PM +0100, Gary C Martin wrote: On 28 Aug 2009, at 21:42, Walter Bender wrote: On Fri, Aug 28, 2009 at 11:53 AM, Jonas Smedegaard wrote: On Fri, Aug 28, 2009 at 02:15:29PM +0100, Gary C Martin wrote: Hi Dave, Do you have Physics-2 installed on the SoaS? Depending on the SoaS version you have, the early ones had Activities installed in non- standard places, with non user permissions, and sometimes symbolic links :-( You would need to drop down into terminal, find and remove that Physics.activity folder. Then the normal install process should work as normal. FWIW: On old SoaS, my first task would be to drop into the Terminal and clean this all up manually, so that all the *.activity directories were migrated the expected ~/Activities, and ownership permissions of them given back to the user (recursive chown on ~/Activities). In the current SoaS activities are installed from their .xo bundles so this is no longer an issue :-) Is this an issue specific to SoaS and/or Physics, or generally a limitation of current Sugar that older system-installed Activities disturb newer user-installed ones? (or did I get it wrong that that was the actual issue here?) I think you got it right. Thanks for the confirmation, Walter :-) Dave reported (off-list) that a manual deletion of v2, reboot, and then install of v3 worked fine. My radar was going off regarding the addition of MIME support, as I have a few hairs standing up on the back of my neck about how Sugar deals with that step. Almost no activities except pre-installed Fructose have exercised this code path much, sugar-install-bundle was doing odd things as I was having to reboot for the activity to show up, so I assume it was silently borking some place, but installing an .xo via Journal (equiv. Browse download) was running just fine. Not quite sure I understand this fully, but seems to be tied to b tied to doing system installs directly into the running system - as opposed to installing into a packaging environment and use that for the final install. In other words, I will try to keep this in the back of my head but for now don't expect it to be a problem for Debian-packages Sugar activities. thanks for elaborating! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] clash of user- and system-installed activities (was: Release Physics-3)
On 28 Aug 2009, at 21:42, Walter Bender wrote: > On Fri, Aug 28, 2009 at 11:53 AM, Jonas Smedegaard wrote: >> On Fri, Aug 28, 2009 at 02:15:29PM +0100, Gary C Martin wrote: >>> >>> Hi Dave, >>> >>> Do you have Physics-2 installed on the SoaS? Depending on the SoaS >>> version you have, the early ones had Activities installed in non- >>> standard places, with non user permissions, and sometimes symbolic >>> links :-( You would need to drop down into terminal, find and remove >>> that Physics.activity folder. Then the normal install process should >>> work as normal. >>> >>> FWIW: On old SoaS, my first task would be to drop into the Terminal >>> and clean this all up manually, so that all the *.activity >>> directories >>> were migrated the expected ~/Activities, and ownership permissions >>> of >>> them given back to the user (recursive chown on ~/Activities). In >>> the >>> current SoaS activities are installed from their .xo bundles so this >>> is no longer an issue :-) >> >> Is this an issue specific to SoaS and/or Physics, or generally a >> limitation >> of current Sugar that older system-installed Activities disturb newer >> user-installed ones? >> >> (or did I get it wrong that that was the actual issue here?) >> > > I think you got it right. > > -walter Dave reported (off-list) that a manual deletion of v2, reboot, and then install of v3 worked fine. My radar was going off regarding the addition of MIME support, as I have a few hairs standing up on the back of my neck about how Sugar deals with that step. Almost no activities except pre-installed Fructose have exercised this code path much, sugar-install-bundle was doing odd things as I was having to reboot for the activity to show up, so I assume it was silently borking some place, but installing an .xo via Journal (equiv. Browse download) was running just fine. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 07:02:30PM +0200, Tomeu Vizoso wrote: On Fri, Aug 28, 2009 at 18:55, Jonas Smedegaard wrote: On Fri, Aug 28, 2009 at 12:02:44PM +0200, Tomeu Vizoso wrote: On Fri, Aug 28, 2009 at 11:37, Jonas Smedegaard wrote: On Fri, Aug 28, 2009 at 10:13:24AM +0200, Tomeu Vizoso wrote: If fat binaries are not desired, which alternatives do we have? 1) Include more aggressively/liberally arch-dependent stuff in Sucrose, and include/write wrappers for popular arch-independent languages (e.g. Python) 2) Promote as "first class Activities" those written in arch- independent languages and depending only on stuff included in Sucrose. Both sound like good ideas to me, It was meant as a single alternative containing 2 steps. though 1) concerns more to deployers: do they want to have to install hundreds of megs of software that might or might not be used by any Sugar activities they get to use? Sucrose does not grow automatically. Sugarlabs maintains Sucrose, so gets to decide if it should bloat or if the author of an activity written in YACNL (Yet Another Cool New Language) is told to either rewrite in one of the existing supported languages or accept that the Activity will be a 2nd class activity due to the weird choice of language. I think that deployers should be the ones to say what can go in the platform and what not. But the more we have there, the easier it is for us developers. Could you give a concrete example of this dilemma (preferrably non-theoretical - i.e. tied to actual activities and languages currently used for them)? Let's say that a country wants to develop activities in java and have it as part of the platform. Maybe some other deployer with restricted disk space would be opposed to have to ship Java? Same with the cups filters, Mono, etc Not a problem if the deplyer wants to extend locally with Java or some other bloat. Sugarlabs need not change the Fructose specs for that. The rest of the world need not suffer from such local oddities. If, on the other hand, Sugarlabs choose to adopt all those cool activities created in Java, then Sugarlabs would bloat Fructose globally, and we would all suffer from the bloat. True. But really such problem of Sugarlabs shooting itself in the foot like that is IMHO independent from the challenge of arch-dependent code in activity packages: If Sugarlabs wants the ability to make small-diskspace deployments then Sugarlabs must set the bar high for 1st class activities. Oh, and in case we might be talking past each other due to terminology: I use the term "Fructose" as "the very minimal core set of stuff that must always be available for a system to sanely claim to run "Sugar". I apologize for any confusion if I misunderstood the term. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Ad-hoc network identification badge
On Fri, Aug 28, 2009 at 4:16 PM, Gary C Martin wrote: > On 27 Aug 2009, at 22:24, Simon Schampijer wrote: > >> On 08/27/2009 10:42 PM, Gary C Martin wrote: >>> >>> Quick ping, >>> >>> Do we need something like an emblem-buddy.svg for ad-hoc network icons >>> (e.g. an XO icon used in same way as the star and lock icon are used >>> to badge AP icons)? Sorry couldn't find a trac ticket or the right ML >>> thread. >>> >>> Regards, >>> --Gary >> >> Yeah, I think we settled on a badged AP icon. If you have something in >> mind - please share it with us ;p > > OK :-) Just tested the buddy icon pretty much as is for an emblem, but it > doesn't quite ring true (feels too fussy). Here's a few screen shots: > > > > So taking a leaf out of the emblem-locked style and came up with what I > think is a much better emblem using a box outline and solid stroke colour > for the buddy icon: Yup. I would definitely recommend the (unstroked, as you show it) XO icon within the box, as well. The badge feels just a little high in your mockups (it should be at a 45 degree angle from center, and positioned so that the lower-right corner falls outside the 55px recommended icon region, at (70,70)), but that's just an issue of defining the hotspot correctly. Also, all bages are supposed to be black fills with white strokes (and white symbols within the box, eg. the XO itself). I think that never happened because entity support was never added for badges. Does someone know how to add that so we can fix the badges up? Alternatively, does someone want to update all of the default SVGs for the badges so that they use the correct colors without use of entities? Thanks Gary! (For the mockups, that is; I'm not volunteering you for the above task) Eben > > > > Attaching the .svg for this version to the email, though happy to provide > the other if folks think that looks better. > > Regards, > --Gary > > > > > > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
On Fri, Aug 28, 2009 at 05:04:32PM +, Aleksey Lim wrote: Purposes for 0install(or so) in comparing with native packages: * one way to install deps in all environments * non-root install * requires reliable internet access at install time - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
On Fri, Aug 28, 2009 at 09:55:37PM +0200, Elena of Valhalla wrote: On Fri, Aug 28, 2009 at 6:44 PM, Jonas Smedegaard wrote: What would "universal" be in the Sugar context? i386 + amd64? i686 + amd64? i386 + i686 + amd64? i386 would work on all of them, even if not optimally, but then True only if the underlying system is i386 too, of if it at least provides i386 libraries for all of the bindings. powerpc + i386 + amd64? armel + i386 + amd64? powerpc + armel + i386 + amd64? +mips, I guess ...and then when all users have gotten used to Sugar "universal" meaning that bunch, in comes SuperH hardware and we confuse them yet again. Compare with Apple: "Universal" means simply "contains both new and old", with the exact meaning of "new" and "old" shifting tied to a corporate decision and backed by massive marketing. It is plain ugly IMHO! and wasteful and still only addresses arch-differences - not same-arch incompatibilities between different minor versions of libraries and different dependencies linked in (e.g. some distributions using libssl and others using gnutls). Just avoid that mess! It seems difficult to constrain activity developers to only code using arch-independent runtime code, but accepting arch-dependent stuff is an evergrowing hell - it is what "distributions" spend humongous man-hours handling! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] clash of user- and system-installed activities (was: Release Physics-3)
On Fri, Aug 28, 2009 at 11:53 AM, Jonas Smedegaard wrote: > On Fri, Aug 28, 2009 at 02:15:29PM +0100, Gary C Martin wrote: >> >> Hi Dave, >> >> Do you have Physics-2 installed on the SoaS? Depending on the SoaS >> version you have, the early ones had Activities installed in non- >> standard places, with non user permissions, and sometimes symbolic >> links :-( You would need to drop down into terminal, find and remove >> that Physics.activity folder. Then the normal install process should >> work as normal. >> >> FWIW: On old SoaS, my first task would be to drop into the Terminal >> and clean this all up manually, so that all the *.activity directories >> were migrated the expected ~/Activities, and ownership permissions of >> them given back to the user (recursive chown on ~/Activities). In the >> current SoaS activities are installed from their .xo bundles so this >> is no longer an issue :-) > > Is this an issue specific to SoaS and/or Physics, or generally a limitation > of current Sugar that older system-installed Activities disturb newer > user-installed ones? > > (or did I get it wrong that that was the actual issue here?) > I think you got it right. -walter > Kind regards, > > - Jonas > > Worried if Debian-packages activities conflict with user-installed ones. > > > -- > * Jonas Smedegaard - idealist og Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQIcBAEBCgAGBQJKl/2PAAoJECx8MUbBoAEh2NQQAIXD8YOZIEQepC8EzNUtK4sw > BYx2kXaNh5ge28+2pf+cy06T2KXHWA1G5IHYjRdrhyrWV/j56TV5iCtIPIi3Ppsa > R3igY5UX3kpEfOP/mhErniv4ZNdA2kysR2cRYI5qPDa4aClbaOjyCmvOm8/AIXMR > yDtghwKn5Iz+NSUpHDdHIwGKU1Dxb/OvwqC62kEWpVBxuacoki5PDaCEO2yzp417 > 8jyQZ9vth/SpJeWwMgIZcnzpCFqwYs4XOvmAUb2epeUxn+Eu9ifZEwdwoy/Or1oN > IiKEBGDpaUAD9rRheDTrZ7qdlGMdXRGvpsR+45ieNbidm2yDwzftQPd6Sg1hp1lY > bq7FHVEz7QYxKDlPJXjUKsRzthILw//I8WM5Ak+l9GW2bahXv0ZfLkN4AZBWnBKk > Z7klpXwUuV9mgpWMVLkmSJYYQ++G09twefXS3/8ghknqSxxPDtW+HpRp+TBoT56n > SK6CNnwkxPCipkyVWIWk5/aNUiQdXUGkX+kzZZ7F18vkp6AV4/yqZn9w7o7i+CMM > QMgEhxI4yUIFckC6YVKwer+NiPTTPvAjJ/zfEBoMcHG+CdWJ/y6LX3c8MxhWWazU > EeM9DdNZ0ICVTrK6Tx5LapL972fSn2XM9kRJgv3n4RlBgb0+jeNiK//g/jrtFstU > wXJNEunwWRDBTyMFws3p > =vRtN > -END PGP SIGNATURE- > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] OCR?
I was at a presentation last week of Abbyy OCR software, which works on pictures taken by mobile phone cameras in more than 100 languages. The company wants to give away software (though not source code) in was that will get the company good publicity. So we are talking about using their software with the XO camera to read signs or full pages in books. Also whether we can add languages. This would mean making the OCR engine a separate download, the way we handle Adobe Flash. So is this likely to be worth the effort? Is there a Free Software OCR engine of adequate quality? Any other questions? -- Edward Mokurai Cherlin Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name, and Children are my nation. The Cosmos is my dwelling place, the Truth my destination. http://earthtreasury.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
On Fri, Aug 28, 2009 at 6:44 PM, Jonas Smedegaard wrote: > What would "universal" be in the Sugar context? > i386 + amd64? > i686 + amd64? > i386 + i686 + amd64? i386 would work on all of them, even if not optimally, but then > powerpc + i386 + amd64? > armel + i386 + amd64? > powerpc + armel + i386 + amd64? +mips, I guess > It is plain ugly IMHO! and wasteful -- Elena ``of Valhalla'' homepage: http://www.trueelena.org email: elena.valha...@gmail.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] ASLO download numbers seem suspect
For weeks now I have had two of the most popular Activities on ASLO: View Slides and Read Etexts. Both of these were downloaded 2000+ times this week alone, and 20,000+ times total. I also have one of the less popular Activities: Get Internet Archive Books, which has been downloaded only a little over 1,000 times total. I wish I could believe these numbers, but I can't. They seem way too high. I also question the numbers for Speak. Why would over 1,000 people a week download an Activity that they should already have? If View Slides is so insanely popular why hasn't it received any comments? If Read Etexts is so popular why haven't more people viewed the video about it? (Last time I looked it was about 12 views, many of them by me). If Sugar users like reading so much why isn't Get Internet Archive Books more popular? James Simmons ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
Peter Robinson wrote: > Fedora doesn't have x11vnc because it uses tigervnc which is a fork > based on tinyvnc (I think) which is massively optimised over the > original vnc. So why is that not usable? Why is what not usable? x11vnc is a VNC server that connects to a pre-existing X session and listens for DAMAGE events, which it uses to update a virtual framebuffer. The only other server I'm aware of that behaves this way is Vino, which can only be launched by the Gnome session daemon, not as a standalone program. tightvnc and tigervnc may provide this functionality, but I cannot find any documentation to indicate that they do. Neither was packaged for Fedora 9, so this would not help to get my activity working on existing XO Sugar deployments. Moreover, I feel it's important that my activity run in deployments like Uruguay's where students do not have root access, and so cannot install system packages. > The problem with providing > copies of things like statically linked applications is that they are > then not open to the usual security updates etc. Activities are not designed to be secure. Like javascript webapps, they're untrusted, and run in an isolation shell. However, I absolutely agree that shipping static binaries is a terrible idea... which is why I'm trying to find a better alternative. > I would have thought > that gtk-vnc-python would be completely unusable in Fedora without > some form of VNC in Fedora so if x11vnx wasn't there it must have been > replaced with something else. gtk-vnc is purely a VNC client, not a VNC server. They are independent. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 12:16:36PM +0200, Tomeu Vizoso wrote: Also, Sugar has been reported to run on the Gdium which uses a MIPS Loongson CPU. If someone on this list has access to one of those, we could check that activities with binaries are made to run there as well. Yeah, I applied for a developer machine for Sugar testing when they advertised a developers' program, but they never replied on that - only subscribed me to their general (advertising-like) mailinglsit and wanted me to then join some Google group which I declined. If anyone is in contact with those guys, I am still interested in devoting time on that - if being sponsored the hardware. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 07:11:54AM -0400, Walter Bender wrote: On Fri, Aug 28, 2009 at 6:57 AM, Tomeu Vizoso wrote: On Fri, Aug 28, 2009 at 12:51, Peter Robinson wrote: As a developer, dropping .xo support would take a lot of work from my shoulders, but I suspect our users would kill us... I suspect users will kill you as well when activities don't work on machine X but they do on Y... your damned if you do, damned if you don't. Either way there's going to be pain, whether its the in the short or the long term. Yeah, I guess Jonas' suggestion of promoting platform independent bundles as "first class" addresses this concern. I personally don't think we are going to be able to outdo rpms nor debs so the less binary code we have the better. That said, our users are free to do whatever they want and Sugar will be deployed in wildly different scenarios. So I think that leaving some extra flexibility is wise because if we try to anticipate all the ways in which Sugar will be used, we'll fail. That's the advantage of open source - people can do what ever they like. I think from the sugar perspective there needs to be some standard defined and recommendation made +to make supporting it easier rather than just sitting on the fence. Deployments or people of course are then free to ignore those recommendations and package half a binary distribution up in their .xo if they so choose. At the moment its not so much of an issue but moving forward I think that if something isn't well defined now we're going to end up with a massive support burden going forward with users coming to mailing lists complaining because activities don't work and that sugar is bad because nothing works. I agree, what's the Activity Team's opinion on this? Wearing my lowly activity-developer hat, I am looking for guidance. I have stalled out on the maintenance of several activities (Turtle Art with Sensors and Measure) because I don't want to make unilateral (uniformed) decisions about how to handle the multi-arch issue. I await guidance from those with more packaging experience than me (just about anyone on this list). Not quite sure what kind of guidance you ask for, but here's some random thoughts. I apologize ahead if they are hilariously obvious: For each major Sugar release, document the provided ABIs offered for 1st class activities (i.e. arch-independent activities depending only on Fructose). For each 1st class activity, decide on a minimum requirement - e.g. "needs Fructose 0.82 or newer". Treat "funky things" requiring more than the bare minimum as optional. That is, make sure that the activity does not explode if the requirements are not met on the host system - e.g. hide that non-working funky feature from the menus. Treat binary blobs outside of Fructose as "cheating". That is, require official releases of 1st class activities to not contain arch-dependent binary blobs. Optionally promote as "dirty hacks" some alternatative, unofficial releases that also contain some binary blobs to make the activity work better on some specific system (i.e. a specific version of SoaS for a specific hardware platform). Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
On Fri, Aug 28, 2009 at 04:47:53AM +0100, Gary C Martin wrote: > Hi Benjamin, > > On 28 Aug 2009, at 03:58, Benjamin M. Schwartz wrote: > > > Bobby Powers wrote: > >> I think having something like: > >> > >> example.activity > >> |-arch/ > >> |-arch/x86/ > >> |-arch/x86/bin/ > >> |-arch/x86/lib/ > >> |-arch/armel/ > >> ... > >> > >> could work. Sugar could set an environmental variable ARCH to the > >> relevant value, and we could have a reference activity_startup.sh > >> which adds the correct lib path to LD_LIBRARY_PATH and launches the > >> appropriate executable (or maybe a flag in activty.info which has > >> sugar do this). This is still somewhat kludgy, but I'm not sure of a > >> better way. > > > > Which solution we should choose is a technical discussion that > > deserves > > its own thread. I'm personally not enthusiastic about the "fat > > packages" > > approach, in which binaries for many architectures are included in > > one .xo > > bundle, because: > > What would be your recommendation? As a long time Mac user (and > developer) I was/am all for "fat packages" (universal binaries), and > we certainly don't have the ability to compile binaries on demand for > the significant portion of target sugar HW. Activity bundles are a > major plus, from where I'm standing, vs. the traditional ./configure, > make install, and dependancy requirements. > > With my activity author hat on, I've gone out of my way to avoid the > hell of binary blobs, it breaks the whole idea of providing code in > Python source for others to easily edit, modify, learn from. But I > understand (having adopted maintenance of some old projects) that this > has not always been possible for authors (though it woul would always > be my goal when writing code). Another option is adding 0install[1](or so) to sugar e.g.: * activity bundles dont include any blobs at all * on uploading .xo to journal, sugar popups 0install regular dialog to install all needed by activity dependancies * activity author "package"(in meaning of packaging in 0install) binary dependancies for all environments/plarforms/architectures that he wants to support Purposes for 0install(or so) in comparing with native packages: * one way to install deps in all environments * non-root install [1] http://0install.net/ -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 18:55, Jonas Smedegaard wrote: > On Fri, Aug 28, 2009 at 12:02:44PM +0200, Tomeu Vizoso wrote: >> >> On Fri, Aug 28, 2009 at 11:37, Jonas Smedegaard wrote: >>> >>> On Fri, Aug 28, 2009 at 10:13:24AM +0200, Tomeu Vizoso wrote: If fat binaries are not desired, which alternatives do we have? >>> >>> 1) Include more aggressively/liberally arch-dependent stuff in Sucrose, >>> and include/write wrappers for popular arch-independent languages >>> (e.g. Python) >>> 2) Promote as "first class Activities" those written in arch- >>> independent languages and depending only on stuff included in >>> Sucrose. >> >> Both sound like good ideas to me, > > It was meant as a single alternative containing 2 steps. > > >> though 1) concerns more to deployers: do they want to have to install >> hundreds of megs of software that might or might not be used by any Sugar >> activities they get to use? > > Sucrose does not grow automatically. Sugarlabs maintains Sucrose, so gets > to decide if it should bloat or if the author of an activity written in > YACNL (Yet Another Cool New Language) is told to either rewrite in one of > the existing supported languages or accept that the Activity will be a 2nd > class activity due to the weird choice of language. > > >> I think that deployers should be the ones to say what can go in the >> platform and what not. But the more we have there, the easier it is >> for us developers. > > Could you give a concrete example of this dilemma (preferrably > non-theoretical - i.e. tied to actual activities and languages currently > used for them)? Let's say that a country wants to develop activities in java and have it as part of the platform. Maybe some other deployer with restricted disk space would be opposed to have to ship Java? Same with the cups filters, Mono, etc Regards, Tomeu > > > Kind regards, > > - Jonas > > -- > * Jonas Smedegaard - idealist og Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQIcBAEBCgAGBQJKmAwMAAoJECx8MUbBoAEh6bUP/1iv83WI3RJDjeeopO1nTMDs > PhZ6HXVKgljRX1unPS8D3cVdCFY9iHsM7cll3XYNWvlNW1B0R3R13t53unoUXCj0 > ik0rjRJ2hB7hkXjl6rgPFoGBGqufRDjRsR3CzsoCUw6PL/ZdI2w4ZEn+i3FtNI8i > ErP3NMmHr6GbrGWjFihJbLQnRScmBqZK5bLHA6HVsODPbSUspcwlyd18tHAfqCgB > GLTS2r1adoyjSHSE75FBGvrr+hdV3XRw49jAtNB+X9MrkF1Hv3XE92sRMnn+ixiN > vCQMofbaHIAQAY6u/pcq1uE2z8gURKzUcBVXYlA7CSxVo6Vxfx4N3/EfqUGWXfNm > lBCLiAU6TE75IzywNV/UShYlMpuj1ChBXVifVBlUC7PEh4gsMGvWLBrKdvjwDVcb > YuTaAEb1w4JCe+8LW8mzblQVy6nYWskpD1Pfax9snX4ApE2+dHskGD8OvsTaMuzg > OId/YIB4P3cPHCXMduyQXZxWR7iiiP2JKh3LB2B1Hwcu6/FMCI55xUjAulIDY0Z9 > beIHjiOWYG7sl+VGUS7Y9kuPZq6HJuw0tF5xzUYBMlMtRgDOz3w3vW2sBMUe8nWw > y6F/vh9Gc8S7RlSKMTXGIR4n0DA5DwpA+bxQaFS5q1CYnMk38zCAgp38eIDiU4Od > xnpgrmKvbdvNvIdc7MRa > =xc55 > -END PGP SIGNATURE- > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 12:02:44PM +0200, Tomeu Vizoso wrote: On Fri, Aug 28, 2009 at 11:37, Jonas Smedegaard wrote: On Fri, Aug 28, 2009 at 10:13:24AM +0200, Tomeu Vizoso wrote: If fat binaries are not desired, which alternatives do we have? 1) Include more aggressively/liberally arch-dependent stuff in Sucrose, and include/write wrappers for popular arch-independent languages (e.g. Python) 2) Promote as "first class Activities" those written in arch- independent languages and depending only on stuff included in Sucrose. Both sound like good ideas to me, It was meant as a single alternative containing 2 steps. though 1) concerns more to deployers: do they want to have to install hundreds of megs of software that might or might not be used by any Sugar activities they get to use? Sucrose does not grow automatically. Sugarlabs maintains Sucrose, so gets to decide if it should bloat or if the author of an activity written in YACNL (Yet Another Cool New Language) is told to either rewrite in one of the existing supported languages or accept that the Activity will be a 2nd class activity due to the weird choice of language. I think that deployers should be the ones to say what can go in the platform and what not. But the more we have there, the easier it is for us developers. Could you give a concrete example of this dilemma (preferrably non-theoretical - i.e. tied to actual activities and languages currently used for them)? Kind regards, - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
Hi all, Feel free to ignore my comments here - after all I am not doing any of the heavy lifting in this field, I "just" continue to package for Debian from source, independent on what you come up with here... On Fri, Aug 28, 2009 at 04:47:53AM +0100, Gary C Martin wrote: As a long time Mac user (and developer) I was/am all for "fat packages" (universal binaries), and we certainly don't have the ability to compile binaries on demand for the significant portion of target sugar HW. Activity bundles are a major plus, from where I'm standing, vs. the traditional ./configure, make install, and dependancy requirements. Macintosh "universal binaries" was binaries that contained both "the new stuff" and "the old stuff". Pretty easy for users to grasp. (Back in the day it meant "m68k + powerpc" and later, when m68k was officially dead for some years, it meant "powerpc + i386" (and possibly amd64 too, but I suspect that to be optional for some years) What would "universal" be in the Sugar context? i386 + amd64? i686 + amd64? i386 + i686 + amd64? powerpc + i386 + amd64? armel + i386 + amd64? powerpc + armel + i386 + amd64? It is plain ugly IMHO! With my activity author hat on, I've gone out of my way to avoid the hell of binary blobs, it breaks the whole idea of providing code in Python source for others to easily edit, modify, learn from. But I understand (having adopted maintenance of some old projects) that this has not always been possible for authors (though it woul would always be my goal when writing code). So you find it acceptable for old code to contain binary blobs. I am with you on that. I worry about new Activities using binary blobs too, if not explicitly and loudly discouraged by the Sugar project. Kind regards, - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On 28 Aug 2009, at 11:57, Tomeu Vizoso wrote: > On Fri, Aug 28, 2009 at 12:51, Peter Robinson > wrote: > As a developer, dropping .xo support would take a lot of work > from my > shoulders, but I suspect our users would kill us... I suspect users will kill you as well when activities don't work on machine X but they do on Y... your damned if you do, damned if you don't. Either way there's going to be pain, whether its the in the short or the long term. >>> >>> Yeah, I guess Jonas' suggestion of promoting platform independent >>> bundles as "first class" addresses this concern. >>> >>> I personally don't think we are going to be able to outdo rpms nor >>> debs so the less binary code we have the better. >>> >>> That said, our users are free to do whatever they want and Sugar >>> will >>> be deployed in wildly different scenarios. So I think that leaving >>> some extra flexibility is wise because if we try to anticipate all >>> the >>> ways in which Sugar will be used, we'll fail. >> >> That's the advantage of open source - people can do what ever they >> like. I think from the sugar perspective there needs to be some >> standard defined and recommendation made +to make supporting it >> easier >> rather than just sitting on the fence. Deployments or people of >> course >> are then free to ignore those recommendations and package half a >> binary distribution up in their .xo if they so choose. At the moment >> its not so much of an issue but moving forward I think that if >> something isn't well defined now we're going to end up with a massive >> support burden going forward with users coming to mailing lists >> complaining because activities don't work and that sugar is bad >> because nothing works. > > I agree, what's the Activity Team's opinion on this? My vote would go to agreeing on N (where N is a very small number) architectures we want to support, and then having a 'fat' Activity bundle solution so that Activity Authors desperate/keen enough to use something binary, that is not provided by the Sugar Platform, are recommended to include a binary for each N architectures in their .xo bundle. Unsupported architectures are unsupported, until which time the community agrees to support a new architecture (i.e Nokia or Sharp offer to support us to make Sugar run well on there new glossy 10 inch multi touch wireless & 3G tablet aimed at educational markets, you know, the new wave that will hit in 6+ months once they start trying to play catch with Apple). No compiling, no yum'ing, no apt'ing. A simple hello_architecture activity and some Activity Team wiki notes would act as a template for authors. Perhaps we could fix up Paint/ Colours/Physics as other working examples. Regards, --Gary P.S. Think this is pretty close to some work already done by Aleksey. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] clash of user- and system-installed activities (was: Release Physics-3)
On Fri, Aug 28, 2009 at 02:15:29PM +0100, Gary C Martin wrote: Hi Dave, Do you have Physics-2 installed on the SoaS? Depending on the SoaS version you have, the early ones had Activities installed in non- standard places, with non user permissions, and sometimes symbolic links :-( You would need to drop down into terminal, find and remove that Physics.activity folder. Then the normal install process should work as normal. FWIW: On old SoaS, my first task would be to drop into the Terminal and clean this all up manually, so that all the *.activity directories were migrated the expected ~/Activities, and ownership permissions of them given back to the user (recursive chown on ~/Activities). In the current SoaS activities are installed from their .xo bundles so this is no longer an issue :-) Is this an issue specific to SoaS and/or Physics, or generally a limitation of current Sugar that older system-installed Activities disturb newer user-installed ones? (or did I get it wrong that that was the actual issue here?) Kind regards, - Jonas Worried if Debian-packages activities conflict with user-installed ones. -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 4:26 PM, Benjamin M. Schwartz wrote: > Martin Langhoff wrote: >> On Fri, Aug 28, 2009 at 3:41 PM, Benjamin M. >> Schwartz wrote: >>> I think I am understanding. My claim is that different distros are >>> sufficiently dissimilar that we would end up needing a different bundle >>> for every distro. The dependencies, even if they have the same name, do >>> not provide the same API on different distros. >> >> That's a strange claim. Can you give me an example? Assuming the >> activity itself is written in Python and uses either binaries or >> python bindings... what big unmanageable API changes would it see? > > I agree that python module interfaces tend to be relatively stable, but I > am not concerned exclusively with pure-python activities. > > My most recent experience here is with the Watch Me Activity [1]. Watch > Me is just a python wrapper around gtk-vnc-python (the client) and x11vnc > (the server). gtk-vnc-python is packaged for Fedora, but x11vnc is > written in C and is not in any of the Fedora repositories. x11vnc is > packaged for Gentoo and Debian Stable, so I'm not sure why Fedora doesn't > have it, but it doesn't, and I wasn't willing to wait a year for x11vnc to > make it into a Fedora release. Therefore, I decided to include a binary > copy of it in the bundle, so that Watch Me would work on OLPC's 8.2 series. Fedora doesn't have x11vnc because it uses tigervnc which is a fork based on tinyvnc (I think) which is massively optimised over the original vnc. So why is that not usable? The problem with providing copies of things like statically linked applications is that they are then not open to the usual security updates etc. I would have thought that gtk-vnc-python would be completely unusable in Fedora without some form of VNC in Fedora so if x11vnx wasn't there it must have been replaced with something else. yum list *vnc* will show you that there's a whole collection of vnc packages. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
Martin Langhoff wrote: > On Fri, Aug 28, 2009 at 3:41 PM, Benjamin M. > Schwartz wrote: >> I think I am understanding. My claim is that different distros are >> sufficiently dissimilar that we would end up needing a different bundle >> for every distro. The dependencies, even if they have the same name, do >> not provide the same API on different distros. > > That's a strange claim. Can you give me an example? Assuming the > activity itself is written in Python and uses either binaries or > python bindings... what big unmanageable API changes would it see? I agree that python module interfaces tend to be relatively stable, but I am not concerned exclusively with pure-python activities. My most recent experience here is with the Watch Me Activity [1]. Watch Me is just a python wrapper around gtk-vnc-python (the client) and x11vnc (the server). gtk-vnc-python is packaged for Fedora, but x11vnc is written in C and is not in any of the Fedora repositories. x11vnc is packaged for Gentoo and Debian Stable, so I'm not sure why Fedora doesn't have it, but it doesn't, and I wasn't willing to wait a year for x11vnc to make it into a Fedora release. Therefore, I decided to include a binary copy of it in the bundle, so that Watch Me would work on OLPC's 8.2 series. I was happy to see that the author of x11vnc provides a number of static binaries [2] for many platforms. I downloaded the i686 executable [3] and tested it on an XO. It didn't run. It didn't even launch. Instead, the dynamic linker gave me an error, due to a mismatch in the version of /usr/lib/libssl. The binary wouldn't run, because the version of libssl on my system was not the same as the one on the system used to compile the binary, never mind that I'm not making use of any encryption. I very nearly gave up entirely at this point Luckily, the author's i386 executable [4] is "even more" statically linked. It appears to include libssl entirely, along with a megabyte of other dependencies. This runs on my XO, and is included in WatchMe-2... but that's no guarantee that it'll run on your Debian system (now with eglibc!), or even on other versions of Fedora, never mind on x86-64 or ARM. --Ben [1] http://activities.sugarlabs.org/en-US/sugar/addon/4205 [2] http://www.karlrunge.com/x11vnc/bins/ [3] http://x11vnc.sourceforge.net/dev/x11vnc-0.9.9_TEST_i686-Linux [4] http://x11vnc.sourceforge.net/dev/x11vnc-0.9.9_TEST_i386-none-linux signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 3:07 PM, wrote: > Martin Langhoff wrote: >> Of course, Sugar Shell then asks the _distro_ tools to satisfy the >> requirements (PackageKit may be a good abstraction, otherwise a bit of >> glue to drive yum and apt might be needed). > > This makes sense to me. All of yum, apt, and pk have a notion of package > and version. That should be enough for impure XO bundles to identify and > request dependencies via XO metadata info. PackageKit would be the obvious choice here as its OS / package management agnostic. So the Fedora people automatically have it work with yum/rpm and the ubuntu/debian get apt support and the sugar guys only have to write one piece of code for all of it. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
Martin Langhoff wrote: > Of course, Sugar Shell then asks the _distro_ tools to satisfy the > requirements (PackageKit may be a good abstraction, otherwise a bit of > glue to drive yum and apt might be needed). This makes sense to me. All of yum, apt, and pk have a notion of package and version. That should be enough for impure XO bundles to identify and request dependencies via XO metadata info. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
I agree completely on Jonas proposal to give a strong identity to Activity developed within a sugar-portability shield, and let me expand a bit the concept to come to a proposal for a little "classification" of activity based on supported features, testing and development. I think this approach could lead to two different positive effects: 1.By knowing "upfront" some of the expected behaviour of an activity, the potential user will tend to be more positive about operational or functional limitation, instead of "expecting" them and later found that they are not there. 2.Activity developers will be upfront informed of what shoud be developed by themselves in order to be a good sugar-citizen, and maybe motivate himself to progressively increase the level of overall sugarization (maybe via a "check-list" effect). Here is what comes to my mind that should/could be part of the list (ideally the list should appears in the activity download site): 1. Architecture 1.1 "Pure": Activity developed under the umbrella of Sugar managed portable languages & libraries (a comprensive list is needed here) 1.2 Sugar version compatibility 1.3 HW tested (XO, XO1.5, ..) 1.4 Platforms supported... 2. Sugar Features 2.1 Journal integration 2.2 Collaboration supported 2.3 I know I'm forgotting something here... 3. Localization 3.1 Localizable Activity (es.: already in Pootle, pot available, ...) 3.2 Languages availables (nice if the list is written&updated by pootle automagically) No limitation at all on how an activity is being developed, but let's try to enforce the avalability on axpected behaviours. Maybe the inclusion of an activity, in some of official activity selection (honey, ...) could depends, sometimes in the future, to some subset of the list... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 3:41 PM, Benjamin M. Schwartz wrote: > I think I am understanding. My claim is that different distros are > sufficiently dissimilar that we would end up needing a different bundle > for every distro. The dependencies, even if they have the same name, do > not provide the same API on different distros. That's a strange claim. Can you give me an example? Assuming the activity itself is written in Python and uses either binaries or python bindings... what big unmanageable API changes would it see? (Minor API changes can be papered over w some glue code.) 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
Martin Langhoff wrote: > On Fri, Aug 28, 2009 at 3:03 PM, Benjamin M. > Schwartz wrote: >>> - attempt to install rpm/debs to satisfy the req's... if it can >>> (dependent on sudo access, network access, and the collaboration of >>> the underlying pkg manager) >> This doesn't solve the problem. Packages on the same arch, with the same >> name, ostensibly representing the same version of the same software, will >> often have substantially different ABI in different distros due to the >> choice of compile-time options. > > Ben -- you are not understanding. Of course, Sugar Shell then asks the > _distro_ tools to satisfy the requirements (PackageKit may be a good > abstraction, otherwise a bit of glue to drive yum and apt might be > needed). I think I am understanding. My claim is that different distros are sufficiently dissimilar that we would end up needing a different bundle for every distro. The dependencies, even if they have the same name, do not provide the same API on different distros. >> My goal is to make Activity bundles universal across >> Sugar. The only way to do this is to control the dependency chain >> ourselves, outside of the distro. > > You are going to end up writing your own package mgmt, and your own > community of packagers. Your own build infra for many arches. No. I am proposing to "bless" an existing multiplatform distribution, and then use this distro as an overlay over the base operating system. Gentoo Prefix happens to be the only existing distro of which I'm aware that is designed to be installed without root privileges, but others should also be considered. I am advocating this approach in part because it also solves the "Case 2" problem, of dealing with new Activities written in (platform-independent) C. These activities can be bundled as SRPMs, ebuild+tarball, or whatever the appropriate packaged-source format is for the blessed distribution. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] FSF attitude to xo and sugar
On Fri, Aug 28, 2009 at 15:35, Walter Bender wrote: > On Fri, Aug 28, 2009 at 9:07 AM, Caroline Meeks > wrote: >> Is the author local to Boston? Maybe we should take him over to the GPA and >> show him a room full of Windows machines all running open software. Perhaps >> seeing it for himself will >> help, the authors certainly seem to care about what kids are using for their education. > > I don't know who wrote it, but there is a large FSF community in > Boston, so let's try to arrange it. Maybe our friendly FSF sysadmins would know? Regards, Tomeu > -walter > >> On Fri, Aug 28, 2009 at 9:02 AM, Walter Bender >> wrote: >>> >>> On Fri, Aug 28, 2009 at 8:57 AM, Tomeu Vizoso wrote: >>> > On Fri, Aug 28, 2009 at 14:08, Bill Kerr wrote: >>> >> On Fri, Aug 28, 2009 at 7:18 PM, Bert Freudenberg >>> >> >>> >> wrote: >>> >>> >>> >>> On 28.08.2009, at 11:33, Bill Kerr wrote: >>> >>> >>> >>> > n Fri, Aug 28, 2009 at 7:20 AM, Walter Bender >>> >>> > wrote: >>> >>> >> === Sugar Digest === >>> >>> >> 4. The recent FSF campaign condemning the use of Windows 7 in >>> >>> >> education (See http://windows7sins.org/) imputes OLPC in complicity >>> >>> >> with Microsoft. It is disappointing that the FSF is not making any >>> >>> >> constructive arguments in favor of free software alternatives to >>> >>> >> Windows such as Sugar on GNU/Linux, which is currently shipped on >>> >>> >> every machine distributed by OLPC. >>> >>> > >>> >>> > http://windows7sins.org/#1 >>> >>> > When I first saw it I interpreted that page as contrasting the xo as >>> >>> > a positive alternative to Windows (and still think that is a valid >>> >>> > interpretation) >>> >>> > >>> >>> > When I read what walter wrote above later I was shocked to realise >>> >>> > that it could indeed be interpreted the way walter has, as well >>> >>> > >>> >>> > On revisiting I can't see any clarifying text there >>> >>> >>> >>> You need to click the "Learn more" link next to the XO picture. >>> >>> >>> >>> Citing from that concoction: >>> >>> >>> >>> "As a result, it is expected that the main effect of the OLPC project >>> >>> -- if it succeeds -- will be to turn millions of children into >>> >>> Microsoft dependents. That is a negative effect, to the point where >>> >>> the world would be better off if the OLPC project had never existed. >>> >>> The project tragically became yet another example of Microsoft >>> >>> exerting its control to ends harmful to society's freedom." >>> >>> >>> >>> It's tragic how they undermine their allies' efforts in their blind >>> >>> zealousness. >>> >> >>> >> I see it now, thanks Bert. I agree, it's far too zealous and purist. I >>> >> agree >>> >> with Luke too. >>> >> ( I did click on that link before but it sometimes seems to just reload >>> >> the >>> >> same page) >>> >> I do give the FSF an annual donation so I'll write to them and >>> >> complain. I >>> >> thought the over zealousness came more from some FSF supporters than >>> >> the >>> >> leadership but perhaps I was wrong. >>> > >>> > What I think is bad about the campaign is that they say that the OLPC >>> > project is a vector for Microsoft when the truth is that it's being a >>> > great vector for free software, regardless of what their leaders wish >>> > or have said in the past. >>> > >>> > From reading the FSF campaign, people are supposed to think that >>> > Microsoft is evil and OLPC bowed to their pressure and abandoned their >>> > principles. This, I think can have much less impact that if people >>> > learned that they can help us so more children have a great learning >>> > experience with free software. >>> > >>> > So I wouldn't ask FSF to stop bashing MS, I would ask them to >>> > publicize those projects that can have a big impact on their mission. >>> >>> That is the point I was trying to make. I don't really care what FSF >>> does re Microsoft, but they are missing out on an opportunity to >>> promote a learning project that is aligned with FLOSS by ignoring >>> Sugar. >>> >>> -walter >>> >>> > Regards, >>> > >>> > Tomeu >>> > >>> > -- >>> > «Sugar Labs is anyone who participates in improving and using Sugar. >>> > What Sugar Labs does is determined by the participants.» - David >>> > Farning >>> > ___ >>> > Sugar-devel mailing list >>> > Sugar-devel@lists.sugarlabs.org >>> > http://lists.sugarlabs.org/listinfo/sugar-devel >>> > >>> >>> >>> >>> -- >>> Walter Bender >>> Sugar Labs >>> http://www.sugarlabs.org >>> ___ >>> Sugar-devel mailing list >>> Sugar-devel@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/sugar-devel >> >> >> >> -- >> Caroline Meeks >> Solution Grove >> carol...@solutiongrove.com >> >> 617-500-3488 - Office >> 505-213-3268 - Fax >> > > > > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» -
Re: [Sugar-devel] [IAEP] FSF attitude to xo and sugar
On Fri, Aug 28, 2009 at 9:07 AM, Caroline Meeks wrote: > Is the author local to Boston? Maybe we should take him over to the GPA and > show him a room full of Windows machines all running open software. Perhaps > seeing it for himself will > help, the authors certainly seem to care about what kids are using for their education. I don't know who wrote it, but there is a large FSF community in Boston, so let's try to arrange it. -walter > On Fri, Aug 28, 2009 at 9:02 AM, Walter Bender > wrote: >> >> On Fri, Aug 28, 2009 at 8:57 AM, Tomeu Vizoso wrote: >> > On Fri, Aug 28, 2009 at 14:08, Bill Kerr wrote: >> >> On Fri, Aug 28, 2009 at 7:18 PM, Bert Freudenberg >> >> >> >> wrote: >> >>> >> >>> On 28.08.2009, at 11:33, Bill Kerr wrote: >> >>> >> >>> > n Fri, Aug 28, 2009 at 7:20 AM, Walter Bender >> >>> > wrote: >> >>> >> === Sugar Digest === >> >>> >> 4. The recent FSF campaign condemning the use of Windows 7 in >> >>> >> education (See http://windows7sins.org/) imputes OLPC in complicity >> >>> >> with Microsoft. It is disappointing that the FSF is not making any >> >>> >> constructive arguments in favor of free software alternatives to >> >>> >> Windows such as Sugar on GNU/Linux, which is currently shipped on >> >>> >> every machine distributed by OLPC. >> >>> > >> >>> > http://windows7sins.org/#1 >> >>> > When I first saw it I interpreted that page as contrasting the xo as >> >>> > a positive alternative to Windows (and still think that is a valid >> >>> > interpretation) >> >>> > >> >>> > When I read what walter wrote above later I was shocked to realise >> >>> > that it could indeed be interpreted the way walter has, as well >> >>> > >> >>> > On revisiting I can't see any clarifying text there >> >>> >> >>> You need to click the "Learn more" link next to the XO picture. >> >>> >> >>> Citing from that concoction: >> >>> >> >>> "As a result, it is expected that the main effect of the OLPC project >> >>> -- if it succeeds -- will be to turn millions of children into >> >>> Microsoft dependents. That is a negative effect, to the point where >> >>> the world would be better off if the OLPC project had never existed. >> >>> The project tragically became yet another example of Microsoft >> >>> exerting its control to ends harmful to society's freedom." >> >>> >> >>> It's tragic how they undermine their allies' efforts in their blind >> >>> zealousness. >> >> >> >> I see it now, thanks Bert. I agree, it's far too zealous and purist. I >> >> agree >> >> with Luke too. >> >> ( I did click on that link before but it sometimes seems to just reload >> >> the >> >> same page) >> >> I do give the FSF an annual donation so I'll write to them and >> >> complain. I >> >> thought the over zealousness came more from some FSF supporters than >> >> the >> >> leadership but perhaps I was wrong. >> > >> > What I think is bad about the campaign is that they say that the OLPC >> > project is a vector for Microsoft when the truth is that it's being a >> > great vector for free software, regardless of what their leaders wish >> > or have said in the past. >> > >> > From reading the FSF campaign, people are supposed to think that >> > Microsoft is evil and OLPC bowed to their pressure and abandoned their >> > principles. This, I think can have much less impact that if people >> > learned that they can help us so more children have a great learning >> > experience with free software. >> > >> > So I wouldn't ask FSF to stop bashing MS, I would ask them to >> > publicize those projects that can have a big impact on their mission. >> >> That is the point I was trying to make. I don't really care what FSF >> does re Microsoft, but they are missing out on an opportunity to >> promote a learning project that is aligned with FLOSS by ignoring >> Sugar. >> >> -walter >> >> > Regards, >> > >> > Tomeu >> > >> > -- >> > «Sugar Labs is anyone who participates in improving and using Sugar. >> > What Sugar Labs does is determined by the participants.» - David >> > Farning >> > ___ >> > Sugar-devel mailing list >> > Sugar-devel@lists.sugarlabs.org >> > http://lists.sugarlabs.org/listinfo/sugar-devel >> > >> >> >> >> -- >> Walter Bender >> Sugar Labs >> http://www.sugarlabs.org >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel > > > > -- > Caroline Meeks > Solution Grove > carol...@solutiongrove.com > > 617-500-3488 - Office > 505-213-3268 - Fax > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 3:03 PM, Benjamin M. Schwartz wrote: >> - attempt to install rpm/debs to satisfy the req's... if it can >> (dependent on sudo access, network access, and the collaboration of >> the underlying pkg manager) > > This doesn't solve the problem. Packages on the same arch, with the same > name, ostensibly representing the same version of the same software, will > often have substantially different ABI in different distros due to the > choice of compile-time options. Ben -- you are not understanding. Of course, Sugar Shell then asks the _distro_ tools to satisfy the requirements (PackageKit may be a good abstraction, otherwise a bit of glue to drive yum and apt might be needed). The core of what I am saying is: right now, Sugar Shell offers no services in this regard. It should, so that - activity authors don't write their own yum/apt/pk wrappers - 'activity needs X', 'installing', 'we're not online, try later?', 'something went wrong' messages are handled by common Sugar code > We cannot solve our problem by relying on the distros We can _only_ rely on distros, and help them do things better. > My goal is to make Activity bundles universal across > Sugar. The only way to do this is to control the dependency chain > ourselves, outside of the distro. You are going to end up writing your own package mgmt, and your own community of packagers. Your own build infra for many arches. Fun fun fun! It's 2009, we don't write CMSs or package mgmt systems from scratch no more :-) 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Physics-3
Hi Dave, Do you have Physics-2 installed on the SoaS? Depending on the SoaS version you have, the early ones had Activities installed in non- standard places, with non user permissions, and sometimes symbolic links :-( You would need to drop down into terminal, find and remove that Physics.activity folder. Then the normal install process should work as normal. FWIW: On old SoaS, my first task would be to drop into the Terminal and clean this all up manually, so that all the *.activity directories were migrated the expected ~/Activities, and ownership permissions of them given back to the user (recursive chown on ~/Activities). In the current SoaS activities are installed from their .xo bundles so this is no longer an issue :-) Regards, --Gary On 28 Aug 2009, at 12:13, Dave Bauer wrote: > Here is something from the logs > > caution: excluded filename not matched: mimetype > ** (sugar-session:2292): DEBUG: accept_ice_connection() > ** (sugar-session:2292): DEBUG: New client '0x9078180' > ** (sugar-session:2292): DEBUG: Initializing client 0x9078180 > ** (sugar-session:2292): DEBUG: Client '0x9078180' received > RegisterClient(NULL) > ** (sugar-session:2292): DEBUG: Adding new client (null) to session > ** (sugar-session:2292): DEBUG: Sending RegisterClientReply to > '0x9078180 [1046bd195532618ae12514720691018090022920001]' > ** (sugar-session:2292): DEBUG: Sending initial SaveYourself > ** (sugar-session:2292): DEBUG: Set properties from client > '0x9078180 [1046bd195532618ae12514720691018090022920001]' > ** (sugar-session:2292): DEBUG: Program = 'sugar-activity' > ** (sugar-session:2292): DEBUG: CloneCommand = 'sugar-activity' > ** (sugar-session:2292): DEBUG: RestartCommand = 'sugar-activity' > '--sm-client-id' '1046bd195532618ae12514720691018090022920001' > ** (sugar-session:2292): DEBUG: UserID = 'liveuser' > ** (sugar-session:2292): DEBUG: ProcessID = '2446' > ** (sugar-session:2292): DEBUG: RestartStyleHint = 0 > ** (sugar-session:2292): DEBUG: Client '0x9078180 [sugar-activity > 1046bd195532618ae12514720691018090022920001]' received > SaveYourselfDone(success = True) > ** (sugar-session:2292): DEBUG: sms_error_handler (0x92bbb88, FALSE, > 3, 9, 32771, 0) > ** (sugar-session:2292): DEBUG: ice_io_error_handler (0x92ca978) > ** (sugar-session:2292): DEBUG: IceProcessMessagesIOError on > '0x9078180 [sugar-activity > 1046bd195532618ae12514720691018090022920001]' > ** (sugar-session:2292): DEBUG: xsmp_finalize (0x9078180 [sugar- > activity 1046bd195532618ae12514720691018090022920001]) > 1251472216.458838 ERROR root: set_active() failed: > org.freedesktop.DBus.Error.ServiceUnknown: The name :1.17 was not > provided by any .service files > Traceback (most recent call last): > File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", > line 356, in do_size_request > surface = self._buffer.get_surface() > File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", > line 256, in get_surface > handle = self._load_svg(icon_info.file_name) > File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", > line 111, in _load_svg > return self._loader.load(file_name, entities, self.cache) > File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", > line 46, in load > icon_file = open(file_name, 'r') > IOError: [Errno 2] No such file or directory: '/tmp/activity- > physicsIYD0YD.svg' > Traceback (most recent call last): > File "/usr/lib/python2.6/site-packages/jarabe/journal/ > collapsedentry.py", line 361, in __icon_button_release_event_cb > misc.resume(self.metadata) > File "/usr/lib/python2.6/site-packages/jarabe/journal/misc.py", > line 162, in resume > registry.install(bundle) > File "/usr/lib/python2.6/site-packages/jarabe/model/ > bundleregistry.py", line 326, in install > raise AlreadyInstalledException > sugar.bundle.bundle.AlreadyInstalledException > Traceback (most recent call last): > File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", > line 379, in do_expose_event > surface = self._buffer.get_surface(sensitive, self) > File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", > line 256, in get_surface > handle = self._load_svg(icon_info.file_name) > File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", > line 111, in _load_svg > return self._loader.load(file_name, entities, self.cache) > File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", > line 46, in load > icon_file = open(file_name, 'r') > IOError: [Errno 2] No such file or directory: '/tmp/activity- > physicsIYD0YD.svg' > Traceback (most recent call last): > File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", > line 379, in do_expose_event > surface = self._buffer.get_surface(sensitive, self) > File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", > line 256, in get_surface > handle =
Re: [Sugar-devel] The ARM is near
Peter Robinson wrote: > I think from the sugar perspective there needs to be some > standard defined and recommendation made +to make supporting it easier > rather than just sitting on the fence. I agree. I am trying to devise such a recommendation. My goal is that the recommendation also be a "path of least resistance" for Activity developers, so that it's likely to actually be used. > Deployments or people of course > are then free to ignore those recommendations and package half a > binary distribution up in their .xo if they so choose. Of course. They're also free to patch Sugar however they like. > At the moment > its not so much of an issue but moving forward I think that if > something isn't well defined now we're going to end up with a massive > support burden going forward with users coming to mailing lists > complaining because activities don't work and that sugar is bad > because nothing works. I agree. Consider, for example, an isolated school in Bangladesh, with no real internet connection, running a mixture of XO-1.5's (x86-32), second-hand consumer laptops (x86-64), Lemote machines from China (MIPS), and XO-2's (ARM). One kid gets a few gigabytes of activity bundles in the mail on a USB stick from a penpal, and wants to share them with the rest of the school. I would like to make sure that this works. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] FSF attitude to xo and sugar
Is the author local to Boston? Maybe we should take him over to the GPA and show him a room full of Windows machines all running open software. Perhaps seeing it for himself will help, the authors certainly seem to care about what kids are using for their education. On Fri, Aug 28, 2009 at 9:02 AM, Walter Bender wrote: > On Fri, Aug 28, 2009 at 8:57 AM, Tomeu Vizoso wrote: > > On Fri, Aug 28, 2009 at 14:08, Bill Kerr wrote: > >> On Fri, Aug 28, 2009 at 7:18 PM, Bert Freudenberg > > >> wrote: > >>> > >>> On 28.08.2009, at 11:33, Bill Kerr wrote: > >>> > >>> > n Fri, Aug 28, 2009 at 7:20 AM, Walter Bender > >>> > wrote: > >>> >> === Sugar Digest === > >>> >> 4. The recent FSF campaign condemning the use of Windows 7 in > >>> >> education (See http://windows7sins.org/) imputes OLPC in complicity > >>> >> with Microsoft. It is disappointing that the FSF is not making any > >>> >> constructive arguments in favor of free software alternatives to > >>> >> Windows such as Sugar on GNU/Linux, which is currently shipped on > >>> >> every machine distributed by OLPC. > >>> > > >>> > http://windows7sins.org/#1 > >>> > When I first saw it I interpreted that page as contrasting the xo as > >>> > a positive alternative to Windows (and still think that is a valid > >>> > interpretation) > >>> > > >>> > When I read what walter wrote above later I was shocked to realise > >>> > that it could indeed be interpreted the way walter has, as well > >>> > > >>> > On revisiting I can't see any clarifying text there > >>> > >>> You need to click the "Learn more" link next to the XO picture. > >>> > >>> Citing from that concoction: > >>> > >>> "As a result, it is expected that the main effect of the OLPC project > >>> -- if it succeeds -- will be to turn millions of children into > >>> Microsoft dependents. That is a negative effect, to the point where > >>> the world would be better off if the OLPC project had never existed. > >>> The project tragically became yet another example of Microsoft > >>> exerting its control to ends harmful to society's freedom." > >>> > >>> It's tragic how they undermine their allies' efforts in their blind > >>> zealousness. > >> > >> I see it now, thanks Bert. I agree, it's far too zealous and purist. I > agree > >> with Luke too. > >> ( I did click on that link before but it sometimes seems to just reload > the > >> same page) > >> I do give the FSF an annual donation so I'll write to them and complain. > I > >> thought the over zealousness came more from some FSF supporters than the > >> leadership but perhaps I was wrong. > > > > What I think is bad about the campaign is that they say that the OLPC > > project is a vector for Microsoft when the truth is that it's being a > > great vector for free software, regardless of what their leaders wish > > or have said in the past. > > > > From reading the FSF campaign, people are supposed to think that > > Microsoft is evil and OLPC bowed to their pressure and abandoned their > > principles. This, I think can have much less impact that if people > > learned that they can help us so more children have a great learning > > experience with free software. > > > > So I wouldn't ask FSF to stop bashing MS, I would ask them to > > publicize those projects that can have a big impact on their mission. > > That is the point I was trying to make. I don't really care what FSF > does re Microsoft, but they are missing out on an opportunity to > promote a learning project that is aligned with FLOSS by ignoring > Sugar. > > -walter > > > Regards, > > > > Tomeu > > > > -- > > «Sugar Labs is anyone who participates in improving and using Sugar. > > What Sugar Labs does is determined by the participants.» - David > > Farning > > ___ > > Sugar-devel mailing list > > Sugar-devel@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/sugar-devel > > > > > > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
Martin Langhoff wrote: > On Fri, Aug 28, 2009 at 12:33 PM, Tomeu Vizoso wrote: >> Yeah, I guess Jonas' suggestion of promoting platform independent >> bundles as "first class" addresses this concern. > > +1 > >> I personally don't think we are going to be able to outdo rpms nor >> debs so the less binary code we have the better. > > Agreed. One thing we _could_ do, without getting into the whole mess, > is to have a 'requires' metadata that gives the Sugar shell some > hints. > > The shell can then > > - attempt to install rpm/debs to satisfy the req's... if it can > (dependent on sudo access, network access, and the collaboration of > the underlying pkg manager) This doesn't solve the problem. Packages on the same arch, with the same name, ostensibly representing the same version of the same software, will often have substantially different ABI in different distros due to the choice of compile-time options. Even ignoring this phenomenon, different distros ship different versions of underlying libraries. If your dependency is too recent, the user can't acquire it, and so can't run your code. If your dependency is too old, the version on this distro may have an API break that breaks your application. We cannot solve our problem by relying on the distros, unless we want every Activity to be repackaged and retested separately for every version of every distro. My goal is to make Activity bundles universal across Sugar. The only way to do this is to control the dependency chain ourselves, outside of the distro. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] FSF attitude to xo and sugar
On Fri, Aug 28, 2009 at 8:57 AM, Tomeu Vizoso wrote: > On Fri, Aug 28, 2009 at 14:08, Bill Kerr wrote: >> On Fri, Aug 28, 2009 at 7:18 PM, Bert Freudenberg >> wrote: >>> >>> On 28.08.2009, at 11:33, Bill Kerr wrote: >>> >>> > n Fri, Aug 28, 2009 at 7:20 AM, Walter Bender >>> > wrote: >>> >> === Sugar Digest === >>> >> 4. The recent FSF campaign condemning the use of Windows 7 in >>> >> education (See http://windows7sins.org/) imputes OLPC in complicity >>> >> with Microsoft. It is disappointing that the FSF is not making any >>> >> constructive arguments in favor of free software alternatives to >>> >> Windows such as Sugar on GNU/Linux, which is currently shipped on >>> >> every machine distributed by OLPC. >>> > >>> > http://windows7sins.org/#1 >>> > When I first saw it I interpreted that page as contrasting the xo as >>> > a positive alternative to Windows (and still think that is a valid >>> > interpretation) >>> > >>> > When I read what walter wrote above later I was shocked to realise >>> > that it could indeed be interpreted the way walter has, as well >>> > >>> > On revisiting I can't see any clarifying text there >>> >>> You need to click the "Learn more" link next to the XO picture. >>> >>> Citing from that concoction: >>> >>> "As a result, it is expected that the main effect of the OLPC project >>> -- if it succeeds -- will be to turn millions of children into >>> Microsoft dependents. That is a negative effect, to the point where >>> the world would be better off if the OLPC project had never existed. >>> The project tragically became yet another example of Microsoft >>> exerting its control to ends harmful to society's freedom." >>> >>> It's tragic how they undermine their allies' efforts in their blind >>> zealousness. >> >> I see it now, thanks Bert. I agree, it's far too zealous and purist. I agree >> with Luke too. >> ( I did click on that link before but it sometimes seems to just reload the >> same page) >> I do give the FSF an annual donation so I'll write to them and complain. I >> thought the over zealousness came more from some FSF supporters than the >> leadership but perhaps I was wrong. > > What I think is bad about the campaign is that they say that the OLPC > project is a vector for Microsoft when the truth is that it's being a > great vector for free software, regardless of what their leaders wish > or have said in the past. > > From reading the FSF campaign, people are supposed to think that > Microsoft is evil and OLPC bowed to their pressure and abandoned their > principles. This, I think can have much less impact that if people > learned that they can help us so more children have a great learning > experience with free software. > > So I wouldn't ask FSF to stop bashing MS, I would ask them to > publicize those projects that can have a big impact on their mission. That is the point I was trying to make. I don't really care what FSF does re Microsoft, but they are missing out on an opportunity to promote a learning project that is aligned with FLOSS by ignoring Sugar. -walter > Regards, > > Tomeu > > -- > «Sugar Labs is anyone who participates in improving and using Sugar. > What Sugar Labs does is determined by the participants.» - David > Farning > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] FSF attitude to xo and sugar
On Fri, Aug 28, 2009 at 14:08, Bill Kerr wrote: > On Fri, Aug 28, 2009 at 7:18 PM, Bert Freudenberg > wrote: >> >> On 28.08.2009, at 11:33, Bill Kerr wrote: >> >> > n Fri, Aug 28, 2009 at 7:20 AM, Walter Bender >> > wrote: >> >> === Sugar Digest === >> >> 4. The recent FSF campaign condemning the use of Windows 7 in >> >> education (See http://windows7sins.org/) imputes OLPC in complicity >> >> with Microsoft. It is disappointing that the FSF is not making any >> >> constructive arguments in favor of free software alternatives to >> >> Windows such as Sugar on GNU/Linux, which is currently shipped on >> >> every machine distributed by OLPC. >> > >> > http://windows7sins.org/#1 >> > When I first saw it I interpreted that page as contrasting the xo as >> > a positive alternative to Windows (and still think that is a valid >> > interpretation) >> > >> > When I read what walter wrote above later I was shocked to realise >> > that it could indeed be interpreted the way walter has, as well >> > >> > On revisiting I can't see any clarifying text there >> >> You need to click the "Learn more" link next to the XO picture. >> >> Citing from that concoction: >> >> "As a result, it is expected that the main effect of the OLPC project >> -- if it succeeds -- will be to turn millions of children into >> Microsoft dependents. That is a negative effect, to the point where >> the world would be better off if the OLPC project had never existed. >> The project tragically became yet another example of Microsoft >> exerting its control to ends harmful to society's freedom." >> >> It's tragic how they undermine their allies' efforts in their blind >> zealousness. > > I see it now, thanks Bert. I agree, it's far too zealous and purist. I agree > with Luke too. > ( I did click on that link before but it sometimes seems to just reload the > same page) > I do give the FSF an annual donation so I'll write to them and complain. I > thought the over zealousness came more from some FSF supporters than the > leadership but perhaps I was wrong. What I think is bad about the campaign is that they say that the OLPC project is a vector for Microsoft when the truth is that it's being a great vector for free software, regardless of what their leaders wish or have said in the past. >From reading the FSF campaign, people are supposed to think that Microsoft is evil and OLPC bowed to their pressure and abandoned their principles. This, I think can have much less impact that if people learned that they can help us so more children have a great learning experience with free software. So I wouldn't ask FSF to stop bashing MS, I would ask them to publicize those projects that can have a big impact on their mission. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] FSF attitude to xo and sugar
On Fri, Aug 28, 2009 at 7:18 PM, Bert Freudenberg wrote: > > On 28.08.2009, at 11:33, Bill Kerr wrote: > > > n Fri, Aug 28, 2009 at 7:20 AM, Walter Bender > > wrote: > >> === Sugar Digest === > >> 4. The recent FSF campaign condemning the use of Windows 7 in > >> education (See http://windows7sins.org/) imputes OLPC in complicity > >> with Microsoft. It is disappointing that the FSF is not making any > >> constructive arguments in favor of free software alternatives to > >> Windows such as Sugar on GNU/Linux, which is currently shipped on > >> every machine distributed by OLPC. > > > > http://windows7sins.org/#1 > > When I first saw it I interpreted that page as contrasting the xo as > > a positive alternative to Windows (and still think that is a valid > > interpretation) > > > > When I read what walter wrote above later I was shocked to realise > > that it could indeed be interpreted the way walter has, as well > > > > On revisiting I can't see any clarifying text there > > You need to click the "Learn more" link next to the XO picture. > > Citing from that concoction: > > "As a result, it is expected that the main effect of the OLPC project > -- if it succeeds -- will be to turn millions of children into > Microsoft dependents. That is a negative effect, to the point where > the world would be better off if the OLPC project had never existed. > The project tragically became yet another example of Microsoft > exerting its control to ends harmful to society's freedom." > > It's tragic how they undermine their allies' efforts in their blind > zealousness. I see it now, thanks Bert. I agree, it's far too zealous and purist. I agree with Luke too. ( I did click on that link before but it sometimes seems to just reload the same page) I do give the FSF an annual donation so I'll write to them and complain. I thought the over zealousness came more from some FSF supporters than the leadership but perhaps I was wrong. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] SoaS reliability
Has any progress been made on this front? It looks like the direction to lean is in generating comparative data. OLPC has all ready created a Nand testing frame work at http://wiki.laptop.org/go/NAND_Testing . By running these tests on standard SoaS and Satellit's full installs we can move from hand waving to knowledge. Other variables include various file systems and usb stick types. Once we have a definitive understanding of stick wear, we can create similar tests to isolate fs level corruption issues and then move onto sugar level data issues. david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 5:51 AM, Peter Robinson wrote: As a developer, dropping .xo support would take a lot of work from my shoulders, but I suspect our users would kill us... >>> >>> I suspect users will kill you as well when activities don't work on >>> machine X but they do on Y... your damned if you do, damned if you >>> don't. Either way there's going to be pain, whether its the in the >>> short or the long term. >> >> Yeah, I guess Jonas' suggestion of promoting platform independent >> bundles as "first class" addresses this concern. >> >> I personally don't think we are going to be able to outdo rpms nor >> debs so the less binary code we have the better. >> >> That said, our users are free to do whatever they want and Sugar will >> be deployed in wildly different scenarios. So I think that leaving >> some extra flexibility is wise because if we try to anticipate all the >> ways in which Sugar will be used, we'll fail. > > That's the advantage of open source - people can do what ever they > like. I think from the sugar perspective there needs to be some > standard defined and recommendation made +to make supporting it easier > rather than just sitting on the fence. This is one of the main values of the 'platform' as discussed in this week's digest. Pushing these decisions in to the sugar core creates 'conventions' for activity developers and deployers. Conventions reduce the effort required on the part of downstream developers. CORRECTION _Good_ conventions reduce the effort required on the part of downstream developers. david > Deployments or people of course > are then free to ignore those recommendations and package half a > binary distribution up in their .xo if they so choose. At the moment > its not so much of an issue but moving forward I think that if > something isn't well defined now we're going to end up with a massive > support burden going forward with users coming to mailing lists > complaining because activities don't work and that sugar is bad > because nothing works. > > Peter > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Request Feature Freeze Exception for ticket #916 to allow sugar on non-xo hardware to register with a schoolserver
Hello, I would like to kindly request for an exception to the feature freeze currently in place to allow the inclusion of a patch that will enable sugar on non-xo hardware to register with a schoolserver. The relevant ticket with details is at http://dev.sugarlabs.org/ticket/916 The patch is "register-non-xo-with-xs.patch" which can be downloaded directly from http://dev.sugarlabs.org/attachment/ticket/916/register-non-xo-with-xs.patch Thank you very much. Best, Hamilton ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Physics-3
Here is something from the logs caution: excluded filename not matched: mimetype ** (sugar-session:2292): DEBUG: accept_ice_connection() ** (sugar-session:2292): DEBUG: New client '0x9078180' ** (sugar-session:2292): DEBUG: Initializing client 0x9078180 ** (sugar-session:2292): DEBUG: Client '0x9078180' received RegisterClient(NULL) ** (sugar-session:2292): DEBUG: Adding new client (null) to session ** (sugar-session:2292): DEBUG: Sending RegisterClientReply to '0x9078180 [1046bd195532618ae12514720691018090022920001]' ** (sugar-session:2292): DEBUG: Sending initial SaveYourself ** (sugar-session:2292): DEBUG: Set properties from client '0x9078180 [1046bd195532618ae12514720691018090022920001]' ** (sugar-session:2292): DEBUG: Program = 'sugar-activity' ** (sugar-session:2292): DEBUG: CloneCommand = 'sugar-activity' ** (sugar-session:2292): DEBUG: RestartCommand = 'sugar-activity' '--sm-client-id' '1046bd195532618ae12514720691018090022920001' ** (sugar-session:2292): DEBUG: UserID = 'liveuser' ** (sugar-session:2292): DEBUG: ProcessID = '2446' ** (sugar-session:2292): DEBUG: RestartStyleHint = 0 ** (sugar-session:2292): DEBUG: Client '0x9078180 [sugar-activity 1046bd195532618ae12514720691018090022920001]' received SaveYourselfDone(success = True) ** (sugar-session:2292): DEBUG: sms_error_handler (0x92bbb88, FALSE, 3, 9, 32771, 0) ** (sugar-session:2292): DEBUG: ice_io_error_handler (0x92ca978) ** (sugar-session:2292): DEBUG: IceProcessMessagesIOError on '0x9078180 [sugar-activity 1046bd195532618ae12514720691018090022920001]' ** (sugar-session:2292): DEBUG: xsmp_finalize (0x9078180 [sugar-activity 1046bd195532618ae12514720691018090022920001]) 1251472216.458838 ERROR root: set_active() failed: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.17 was not provided by any .service files Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", line 356, in do_size_request surface = self._buffer.get_surface() File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", line 256, in get_surface handle = self._load_svg(icon_info.file_name) File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", line 111, in _load_svg return self._loader.load(file_name, entities, self.cache) File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", line 46, in load icon_file = open(file_name, 'r') IOError: [Errno 2] No such file or directory: '/tmp/activity-physicsIYD0YD.svg' Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/jarabe/journal/collapsedentry.py", line 361, in __icon_button_release_event_cb misc.resume(self.metadata) File "/usr/lib/python2.6/site-packages/jarabe/journal/misc.py", line 162, in resume registry.install(bundle) File "/usr/lib/python2.6/site-packages/jarabe/model/bundleregistry.py", line 326, in install raise AlreadyInstalledException sugar.bundle.bundle.AlreadyInstalledException Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", line 379, in do_expose_event surface = self._buffer.get_surface(sensitive, self) File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", line 256, in get_surface handle = self._load_svg(icon_info.file_name) File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", line 111, in _load_svg return self._loader.load(file_name, entities, self.cache) File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", line 46, in load icon_file = open(file_name, 'r') IOError: [Errno 2] No such file or directory: '/tmp/activity-physicsIYD0YD.svg' Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", line 379, in do_expose_event surface = self._buffer.get_surface(sensitive, self) File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", line 256, in get_surface handle = self._load_svg(icon_info.file_name) File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", line 111, in _load_svg return self._loader.load(file_name, entities, self.cache) File "/usr/lib/python2.6/site-packages/sugar/graphics/icon.py", line 46, in load icon_file = open(file_name, 'r') IOError: [Errno 2] No such file or directory: '/tmp/activity-physicsIYD0YD.svg' Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/jarabe/journal/palettes.py", line 118, in __start_activate_cb misc.resume(self._metadata) File "/usr/lib/python2.6/site-packages/jarabe/journal/misc.py", line 162, in resume registry.install(bundle) File "/usr/lib/python2.6/site-packages/jarabe/model/bundleregistry.py", line 326, in install raise AlreadyInstalledException sugar.bundle.bundle.AlreadyInstalledException 1251472230.938332 WARNING root: No gtk.AccelGroup in the top level window. 1251472230.940663 WARNING root: No gtk.AccelGroup in the top level window. ** (sugar-session:2292): DEBUG: accept_i
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 1:09 PM, Gonzalo Odiard wrote: > We can't use PackageKit for this? Sure! But you want to have the process of calling PK controlled by Sugar Shell to provide a consisten UI experience. (re-added lists to CC) 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 6:57 AM, Tomeu Vizoso wrote: > On Fri, Aug 28, 2009 at 12:51, Peter Robinson wrote: > As a developer, dropping .xo support would take a lot of work from my > shoulders, but I suspect our users would kill us... I suspect users will kill you as well when activities don't work on machine X but they do on Y... your damned if you do, damned if you don't. Either way there's going to be pain, whether its the in the short or the long term. >>> >>> Yeah, I guess Jonas' suggestion of promoting platform independent >>> bundles as "first class" addresses this concern. >>> >>> I personally don't think we are going to be able to outdo rpms nor >>> debs so the less binary code we have the better. >>> >>> That said, our users are free to do whatever they want and Sugar will >>> be deployed in wildly different scenarios. So I think that leaving >>> some extra flexibility is wise because if we try to anticipate all the >>> ways in which Sugar will be used, we'll fail. >> >> That's the advantage of open source - people can do what ever they >> like. I think from the sugar perspective there needs to be some >> standard defined and recommendation made +to make supporting it easier >> rather than just sitting on the fence. Deployments or people of course >> are then free to ignore those recommendations and package half a >> binary distribution up in their .xo if they so choose. At the moment >> its not so much of an issue but moving forward I think that if >> something isn't well defined now we're going to end up with a massive >> support burden going forward with users coming to mailing lists >> complaining because activities don't work and that sugar is bad >> because nothing works. > > I agree, what's the Activity Team's opinion on this? Wearing my lowly activity-developer hat, I am looking for guidance. I have stalled out on the maintenance of several activities (Turtle Art with Sensors and Measure) because I don't want to make unilateral (uniformed) decisions about how to handle the multi-arch issue. I await guidance from those with more packaging experience than me (just about anyone on this list). -walter > Regards, > > Tomeu > > -- > «Sugar Labs is anyone who participates in improving and using Sugar. > What Sugar Labs does is determined by the participants.» - David > Farning > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Physics-3
Re: Physics 3 Can anyone install this on Soas-strawberry by downloading from activities.sugarabs.org? I downloaded it, but clicking on the .xo file in the Journal does nothing. I tried TamTamSythnLab download and that started up. What can I do to troubleshoot this? Dave ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 12:51, Peter Robinson wrote: As a developer, dropping .xo support would take a lot of work from my shoulders, but I suspect our users would kill us... >>> >>> I suspect users will kill you as well when activities don't work on >>> machine X but they do on Y... your damned if you do, damned if you >>> don't. Either way there's going to be pain, whether its the in the >>> short or the long term. >> >> Yeah, I guess Jonas' suggestion of promoting platform independent >> bundles as "first class" addresses this concern. >> >> I personally don't think we are going to be able to outdo rpms nor >> debs so the less binary code we have the better. >> >> That said, our users are free to do whatever they want and Sugar will >> be deployed in wildly different scenarios. So I think that leaving >> some extra flexibility is wise because if we try to anticipate all the >> ways in which Sugar will be used, we'll fail. > > That's the advantage of open source - people can do what ever they > like. I think from the sugar perspective there needs to be some > standard defined and recommendation made +to make supporting it easier > rather than just sitting on the fence. Deployments or people of course > are then free to ignore those recommendations and package half a > binary distribution up in their .xo if they so choose. At the moment > its not so much of an issue but moving forward I think that if > something isn't well defined now we're going to end up with a massive > support burden going forward with users coming to mailing lists > complaining because activities don't work and that sugar is bad > because nothing works. I agree, what's the Activity Team's opinion on this? Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
>>> As a developer, dropping .xo support would take a lot of work from my >>> shoulders, but I suspect our users would kill us... >> >> I suspect users will kill you as well when activities don't work on >> machine X but they do on Y... your damned if you do, damned if you >> don't. Either way there's going to be pain, whether its the in the >> short or the long term. > > Yeah, I guess Jonas' suggestion of promoting platform independent > bundles as "first class" addresses this concern. > > I personally don't think we are going to be able to outdo rpms nor > debs so the less binary code we have the better. > > That said, our users are free to do whatever they want and Sugar will > be deployed in wildly different scenarios. So I think that leaving > some extra flexibility is wise because if we try to anticipate all the > ways in which Sugar will be used, we'll fail. That's the advantage of open source - people can do what ever they like. I think from the sugar perspective there needs to be some standard defined and recommendation made +to make supporting it easier rather than just sitting on the fence. Deployments or people of course are then free to ignore those recommendations and package half a binary distribution up in their .xo if they so choose. At the moment its not so much of an issue but moving forward I think that if something isn't well defined now we're going to end up with a massive support burden going forward with users coming to mailing lists complaining because activities don't work and that sugar is bad because nothing works. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 12:33 PM, Tomeu Vizoso wrote:
> Yeah, I guess Jonas' suggestion of promoting platform independent
> bundles as "first class" addresses this concern.
+1
> I personally don't think we are going to be able to outdo rpms nor
> debs so the less binary code we have the better.
Agreed. One thing we _could_ do, without getting into the whole mess,
is to have a 'requires' metadata that gives the Sugar shell some
hints.
The shell can then
- attempt to install rpm/debs to satisfy the req's... if it can
(dependent on sudo access, network access, and the collaboration of
the underlying pkg manager)
- warn the user if the req's aren't met
I think there are existing GPL'd parsers for 'requires' in Python that
could be used. The usual logical OR ("|") can be used by mindful
activity creators to paper over package naming differences, etc.
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
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 12:23, Peter Robinson wrote: >> On Fri, Aug 28, 2009 at 12:04, Peter Robinson wrote: > Bobby Powers wrote: >> I think having something like: >> >> example.activity >> |-arch/ >> |-arch/x86/ >> |-arch/x86/bin/ >> |-arch/x86/lib/ >> |-arch/armel/ >> ... >> >> could work. Sugar could set an environmental variable ARCH to the >> relevant value, and we could have a reference activity_startup.sh >> which adds the correct lib path to LD_LIBRARY_PATH and launches the >> appropriate executable (or maybe a flag in activty.info which has >> sugar do this). This is still somewhat kludgy, but I'm not sure of a >> better way. > > Which solution we should choose is a technical discussion that deserves > its own thread. I'm personally not enthusiastic about the "fat packages" > approach, in which binaries for many architectures are included in one .xo > bundle, because: > > 1. It wastes space, by carrying around duplicate copies. This gets even > worse for >2 architectures, and even 32-bit and 64-bit x86 might need to > be treated as separate architectures. > 2. It's not future-proof. Packages that work on ARM and x86 will be > broken again if we try to support MIPS (like the Lemote laptops, Free and > perfect for Sugar), or maybe even Sparc or Power (massively SMT chips, > perfect for LTSP). > 3. It won't happen. Cross-compiling libraries is tremendously difficult, > so Activity developers won't do it. They'll just get it working on their > platform and ship it. > 4. It's unreliable. There is no good way to produce binaries that are > guaranteed to work on both 32-bit x86 Fedora 9 and 32-bit x86 Fedora 10. > Changes between versions can break binary compatibility. Between > different distros it's even worse. The Pippy activity recently > experienced exactly this problem due to the included Box2D binary library. I don't think we should aim for the perfect solution here, rather for what can work best for our restricted use cases. Otherwise we run the risk of not moving forward because we take a much bigger challenge we can actually overcome. If fat binaries are not desired, which alternatives do we have? >>> >>> There's quite a decent fedora arm secondary architecture [1] >>> community building up. They have a koji instance and instructions on >>> how to run a arm VM in qemu [2]. RPM packages can deal with arm vs >>> i386 vs PPC or what ever. It would be easy enough to setup various >>> repos and koji build instances for building native packages for each >>> architecture so as not to have to ship multiple binaries in each >>> package and then integration of PackageKit in sugar would solve the >>> issues of installation. I don't see why the wheel needs to be >>> reinvented when there's a perfectly good working solution for this >>> already. >> >> One of the problems is that we want our users to write and share code >> without having to package it in rpm and/or submitting to koji :/ > > Well you might need to do something along the lines of if its pure > python and hence can run on any platform you can use .xo files. If you > want to include binaries you have to go the rpm route. If they can > write and compile C code they should be able to make a rpm. That way > you keep the simple .xo but have a way of ensuring less issues with > binary code. > >> As a developer, dropping .xo support would take a lot of work from my >> shoulders, but I suspect our users would kill us... > > I suspect users will kill you as well when activities don't work on > machine X but they do on Y... your damned if you do, damned if you > don't. Either way there's going to be pain, whether its the in the > short or the long term. Yeah, I guess Jonas' suggestion of promoting platform independent bundles as "first class" addresses this concern. I personally don't think we are going to be able to outdo rpms nor debs so the less binary code we have the better. That said, our users are free to do whatever they want and Sugar will be deployed in wildly different scenarios. So I think that leaving some extra flexibility is wise because if we try to anticipate all the ways in which Sugar will be used, we'll fail. And if activity authors want to get together and unify binary blob handling, that's their business. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
Selon Tomeu Vizoso : > Also, Sugar has been reported to run on the Gdium which uses a MIPS > Loongson CPU. If someone on this list has access to one of those, we > could check that activities with binaries are made to run there as > well. Sugar does run on the Yeeloong netbook, which uses the same CPU as the gdium and runs Debian, Gentoo, and pdaxrom (http://www.pdaxrom.org/). As for the porting to the gdium, this is a work in progress. Kind regards Samy > > Regards, > > Tomeu > > > - Fedora has a 'secondary arch' ARM port for F11 -- probably > > interesting to SoaS people. > > > > hth, > > > > > > 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 > > ___ > > Sugar-devel mailing list > > Sugar-devel@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/sugar-devel > > > > > > -- > «Sugar Labs is anyone who participates in improving and using Sugar. > What Sugar Labs does is determined by the participants.» - David > Farning > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] FSF attitude to xo and sugar
On 28/ago/2009, at 11.48, Bert Freudenberg wrote: > It's tragic how they undermine their allies' efforts in their blind > zealousness. Worse than that, it's complete FUD. This is something you'd expect from MSFT, but not the FSF. The number of XOs shipped with Windows is still 0. -lf ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
> On Fri, Aug 28, 2009 at 12:04, Peter Robinson wrote: Bobby Powers wrote: > I think having something like: > > example.activity > |-arch/ > |-arch/x86/ > |-arch/x86/bin/ > |-arch/x86/lib/ > |-arch/armel/ > ... > > could work. Sugar could set an environmental variable ARCH to the > relevant value, and we could have a reference activity_startup.sh > which adds the correct lib path to LD_LIBRARY_PATH and launches the > appropriate executable (or maybe a flag in activty.info which has > sugar do this). This is still somewhat kludgy, but I'm not sure of a > better way. Which solution we should choose is a technical discussion that deserves its own thread. I'm personally not enthusiastic about the "fat packages" approach, in which binaries for many architectures are included in one .xo bundle, because: 1. It wastes space, by carrying around duplicate copies. This gets even worse for >2 architectures, and even 32-bit and 64-bit x86 might need to be treated as separate architectures. 2. It's not future-proof. Packages that work on ARM and x86 will be broken again if we try to support MIPS (like the Lemote laptops, Free and perfect for Sugar), or maybe even Sparc or Power (massively SMT chips, perfect for LTSP). 3. It won't happen. Cross-compiling libraries is tremendously difficult, so Activity developers won't do it. They'll just get it working on their platform and ship it. 4. It's unreliable. There is no good way to produce binaries that are guaranteed to work on both 32-bit x86 Fedora 9 and 32-bit x86 Fedora 10. Changes between versions can break binary compatibility. Between different distros it's even worse. The Pippy activity recently experienced exactly this problem due to the included Box2D binary library. >>> >>> I don't think we should aim for the perfect solution here, rather for >>> what can work best for our restricted use cases. Otherwise we run the >>> risk of not moving forward because we take a much bigger challenge we >>> can actually overcome. >>> >>> If fat binaries are not desired, which alternatives do we have? >> >> There's quite a decent fedora arm secondary architecture [1] >> community building up. They have a koji instance and instructions on >> how to run a arm VM in qemu [2]. RPM packages can deal with arm vs >> i386 vs PPC or what ever. It would be easy enough to setup various >> repos and koji build instances for building native packages for each >> architecture so as not to have to ship multiple binaries in each >> package and then integration of PackageKit in sugar would solve the >> issues of installation. I don't see why the wheel needs to be >> reinvented when there's a perfectly good working solution for this >> already. > > One of the problems is that we want our users to write and share code > without having to package it in rpm and/or submitting to koji :/ Well you might need to do something along the lines of if its pure python and hence can run on any platform you can use .xo files. If you want to include binaries you have to go the rpm route. If they can write and compile C code they should be able to make a rpm. That way you keep the simple .xo but have a way of ensuring less issues with binary code. > As a developer, dropping .xo support would take a lot of work from my > shoulders, but I suspect our users would kill us... I suspect users will kill you as well when activities don't work on machine X but they do on Y... your damned if you do, damned if you don't. Either way there's going to be pain, whether its the in the short or the long term. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 10:56, Martin Langhoff wrote: > On Thu, Aug 27, 2009 at 9:48 PM, Benjamin M. > Schwartz wrote: >> If you have the hardware to test these features, and the interest to make > > (cc'ing de...@l.l.o -- snipped Ben's outline of why it's important to > get Sugar distros running on ARM devices) > > Some notes that might be of use > > - Marvell has some engineering samples of their ARM based boards. > Distro porters can probably get hold of them -- I landed one for XS > porting :-) and I am hoping to work on it with Bert Desmet here in > Brussels. > > - The 'Sheeva plug' can be used as a porting platform -- same chipset > as larger devices. Also, Sugar has been reported to run on the Gdium which uses a MIPS Loongson CPU. If someone on this list has access to one of those, we could check that activities with binaries are made to run there as well. Regards, Tomeu > - Fedora has a 'secondary arch' ARM port for F11 -- probably > interesting to SoaS people. > > hth, > > > 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 > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
[readding sugar-devel] On Fri, Aug 28, 2009 at 12:04, Peter Robinson wrote: >>> Bobby Powers wrote: I think having something like: example.activity |-arch/ |-arch/x86/ |-arch/x86/bin/ |-arch/x86/lib/ |-arch/armel/ ... could work. Sugar could set an environmental variable ARCH to the relevant value, and we could have a reference activity_startup.sh which adds the correct lib path to LD_LIBRARY_PATH and launches the appropriate executable (or maybe a flag in activty.info which has sugar do this). This is still somewhat kludgy, but I'm not sure of a better way. >>> >>> Which solution we should choose is a technical discussion that deserves >>> its own thread. I'm personally not enthusiastic about the "fat packages" >>> approach, in which binaries for many architectures are included in one .xo >>> bundle, because: >>> >>> 1. It wastes space, by carrying around duplicate copies. This gets even >>> worse for >2 architectures, and even 32-bit and 64-bit x86 might need to >>> be treated as separate architectures. >>> 2. It's not future-proof. Packages that work on ARM and x86 will be >>> broken again if we try to support MIPS (like the Lemote laptops, Free and >>> perfect for Sugar), or maybe even Sparc or Power (massively SMT chips, >>> perfect for LTSP). >>> 3. It won't happen. Cross-compiling libraries is tremendously difficult, >>> so Activity developers won't do it. They'll just get it working on their >>> platform and ship it. >>> 4. It's unreliable. There is no good way to produce binaries that are >>> guaranteed to work on both 32-bit x86 Fedora 9 and 32-bit x86 Fedora 10. >>> Changes between versions can break binary compatibility. Between >>> different distros it's even worse. The Pippy activity recently >>> experienced exactly this problem due to the included Box2D binary library. >> >> I don't think we should aim for the perfect solution here, rather for >> what can work best for our restricted use cases. Otherwise we run the >> risk of not moving forward because we take a much bigger challenge we >> can actually overcome. >> >> If fat binaries are not desired, which alternatives do we have? > > There's quite a decent fedora arm secondary architecture [1] > community building up. They have a koji instance and instructions on > how to run a arm VM in qemu [2]. RPM packages can deal with arm vs > i386 vs PPC or what ever. It would be easy enough to setup various > repos and koji build instances for building native packages for each > architecture so as not to have to ship multiple binaries in each > package and then integration of PackageKit in sugar would solve the > issues of installation. I don't see why the wheel needs to be > reinvented when there's a perfectly good working solution for this > already. One of the problems is that we want our users to write and share code without having to package it in rpm and/or submitting to koji :/ As a developer, dropping .xo support would take a lot of work from my shoulders, but I suspect our users would kill us... Regards, Tomeu > Peter > > [1] https://fedoraproject.org/wiki/Architectures/ARM > [2] https://fedoraproject.org/wiki/Architectures/ARM/HowToQemu > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] windows7sins
I am surprised to read: "As a result, it is expected that the main effect of the OLPC project -- if it succeeds -- will be to turn millions of children into Microsoft dependents." Some of your other criticisms of OLPC are fair, but this is pure speculation. Even though there is a Windows XP port to the XO laptop, to my knowledge, OLPC has not shipped any Windows or dual-boot XOs to customers. (Or was there a small trial that fizzled?) On the other hand, OLPC has put free software into more children's hands than any other project so far. You ought to give them credit for that, at least. Your interpretation of events seems excessively pessimistic. -- American? Vote on the National Initiative for Democracy, http://votep2.us ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 11:37, Jonas Smedegaard wrote: > On Fri, Aug 28, 2009 at 10:13:24AM +0200, Tomeu Vizoso wrote: >> >> If fat binaries are not desired, which alternatives do we have? > > 1) Include more aggressively/liberally arch-dependent stuff in Sucrose, > and include/write wrappers for popular arch-independent languages > (e.g. Python) > 2) Promote as "first class Activities" those written in arch- > independent languages and depending only on stuff included in > Sucrose. Both sound like good ideas to me, though 1) concerns more to deployers: do they want to have to install hundreds of megs of software that might or might not be used by any Sugar activities they get to use? I think that deployers should be the ones to say what can go in the platform and what not. But the more we have there, the easier it is for us developers. Regards, Tomeu > - Jonas > > -- > * Jonas Smedegaard - idealist og Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQIcBAEBCgAGBQJKl6VRAAoJECx8MUbBoAEhiJcP/jWcJq1asTFPMTvTUadxhb5+ > SCE9fZuTuZ/sYlEF4W/FDXEuxPBM0oqbuwJFfwRcoJcJOjN2aTyB5MLPpawGpRK6 > QMWGYIWS9pHDSTgo/vyE5Duw9+OTd07z95mbqeRN4b58tPDUGPPYjARIJ78zh1H4 > vZml2wJOC3PlPZaEcwxQdan0BzOMGPQ/jiOVfqwjKwx8UNCoTZPjaunrzAHX35+m > rpPAuLpXvoORE6Y8VeJg4NCaIQcqpUo6ghGQZYPi5Dle5zs3oAIjIk2EZaaOqvo6 > aaYm8FUlaFRhVKmVVUag88rDKQC/nPd5CbjEd+oe7l2XFlSDWNQ8Oubl3KrWUYBm > sD1dG+Cn1uJsv6AnyP2nCFDF3rE6L528LnnElxwhyAKghXdDWECL8H3VLkOGL7JU > O84ORtuz+3EWlH7AV2hPB8WcKZH3gjjLMg1dpztENNyPKuH4dL1aIGIDsuJ8Esm3 > tYD0mVMQ7Ie5UkB2CwO1lVfK4o+CwV61oeKnTShfGaJ1lUsBPSshTvJyLoC1sCaZ > kxANAGpSR4sRW80oFFqc1mMj36x/V9RSlYniE2wRX1nvTICNLSB0W5o4KCQ42Frv > aD2ufALGij52uwiDF2AXMqr83y6bsk1AKUd2aP3Qw5+j7uD/XlySl87hxabiziAj > c2E8xH6bPtvEUxd1a4Vq > =WB+s > -END PGP SIGNATURE- > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] FSF attitude to xo and sugar
On 28.08.2009, at 11:33, Bill Kerr wrote: > n Fri, Aug 28, 2009 at 7:20 AM, Walter Bender > wrote: >> === Sugar Digest === >> 4. The recent FSF campaign condemning the use of Windows 7 in >> education (See http://windows7sins.org/) imputes OLPC in complicity >> with Microsoft. It is disappointing that the FSF is not making any >> constructive arguments in favor of free software alternatives to >> Windows such as Sugar on GNU/Linux, which is currently shipped on >> every machine distributed by OLPC. > > http://windows7sins.org/#1 > When I first saw it I interpreted that page as contrasting the xo as > a positive alternative to Windows (and still think that is a valid > interpretation) > > When I read what walter wrote above later I was shocked to realise > that it could indeed be interpreted the way walter has, as well > > On revisiting I can't see any clarifying text there You need to click the "Learn more" link next to the XO picture. Citing from that concoction: "As a result, it is expected that the main effect of the OLPC project -- if it succeeds -- will be to turn millions of children into Microsoft dependents. That is a negative effect, to the point where the world would be better off if the OLPC project had never existed. The project tragically became yet another example of Microsoft exerting its control to ends harmful to society's freedom." It's tragic how they undermine their allies' efforts in their blind zealousness. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] FSF attitude to xo and sugar
n Fri, Aug 28, 2009 at 7:20 AM, Walter Bender wrote: > === Sugar Digest === 4. The recent FSF campaign condemning the use of Windows 7 in education (See http://windows7sins.org/) imputes OLPC in complicity with Microsoft. It is disappointing that the FSF is not making any constructive arguments in favor of free software alternatives to Windows such as Sugar on GNU/Linux, which is currently shipped on every machine distributed by OLPC. http://windows7sins.org/#1 When I first saw it I interpreted that page as contrasting the xo as a positive alternative to Windows (and still think that is a valid interpretation) When I read what walter wrote above later I was shocked to realise that it could indeed be interpreted the way walter has, as well On revisiting I can't see any clarifying text there If walter's interpretation is the correct one, which may well be true, then it's a bad choice of graphic - they should have shown windows running on the xo screen, not happy smiling children from this 2008 article RMS is supportive of sugar but ambivalent about the xo: Sugar is free software, and contributing to it is a good thing to do. But don't forget the goal: helpful contributions are those that make Sugar better on free operating systems. Porting to Windows is permitted by the license, but it isn't a good thing to do http://www.fsf.org/blogs/rms/can-we-rescue-olpc-from-windows ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 10:13:24AM +0200, Tomeu Vizoso wrote: If fat binaries are not desired, which alternatives do we have? 1) Include more aggressively/liberally arch-dependent stuff in Sucrose, and include/write wrappers for popular arch-independent languages (e.g. Python) 2) Promote as "first class Activities" those written in arch- independent languages and depending only on stuff included in Sucrose. - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Thu, Aug 27, 2009 at 9:48 PM, Benjamin M. Schwartz wrote: > If you have the hardware to test these features, and the interest to make (cc'ing de...@l.l.o -- snipped Ben's outline of why it's important to get Sugar distros running on ARM devices) Some notes that might be of use - Marvell has some engineering samples of their ARM based boards. Distro porters can probably get hold of them -- I landed one for XS porting :-) and I am hoping to work on it with Bert Desmet here in Brussels. - The 'Sheeva plug' can be used as a porting platform -- same chipset as larger devices. - Fedora has a 'secondary arch' ARM port for F11 -- probably interesting to SoaS people. hth, 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 04:58, Benjamin M. Schwartz wrote: > Bobby Powers wrote: >> I think having something like: >> >> example.activity >> |-arch/ >> |-arch/x86/ >> |-arch/x86/bin/ >> |-arch/x86/lib/ >> |-arch/armel/ >> ... >> >> could work. Sugar could set an environmental variable ARCH to the >> relevant value, and we could have a reference activity_startup.sh >> which adds the correct lib path to LD_LIBRARY_PATH and launches the >> appropriate executable (or maybe a flag in activty.info which has >> sugar do this). This is still somewhat kludgy, but I'm not sure of a >> better way. > > Which solution we should choose is a technical discussion that deserves > its own thread. I'm personally not enthusiastic about the "fat packages" > approach, in which binaries for many architectures are included in one .xo > bundle, because: > > 1. It wastes space, by carrying around duplicate copies. This gets even > worse for >2 architectures, and even 32-bit and 64-bit x86 might need to > be treated as separate architectures. > 2. It's not future-proof. Packages that work on ARM and x86 will be > broken again if we try to support MIPS (like the Lemote laptops, Free and > perfect for Sugar), or maybe even Sparc or Power (massively SMT chips, > perfect for LTSP). > 3. It won't happen. Cross-compiling libraries is tremendously difficult, > so Activity developers won't do it. They'll just get it working on their > platform and ship it. > 4. It's unreliable. There is no good way to produce binaries that are > guaranteed to work on both 32-bit x86 Fedora 9 and 32-bit x86 Fedora 10. > Changes between versions can break binary compatibility. Between > different distros it's even worse. The Pippy activity recently > experienced exactly this problem due to the included Box2D binary library. I don't think we should aim for the perfect solution here, rather for what can work best for our restricted use cases. Otherwise we run the risk of not moving forward because we take a much bigger challenge we can actually overcome. If fat binaries are not desired, which alternatives do we have? Regards, Tomeu > --Ben > > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Fri, Aug 28, 2009 at 04:36, Bobby Powers wrote: > I think having something like: > > example.activity > |-arch/ > |-arch/x86/ > |-arch/x86/bin/ > |-arch/x86/lib/ > |-arch/armel/ > ... > > could work. Sugar could set an environmental variable ARCH to the > relevant value, and we could have a reference activity_startup.sh > which adds the correct lib path to LD_LIBRARY_PATH and launches the > appropriate executable (or maybe a flag in activty.info which has > sugar do this). This is still somewhat kludgy, but I'm not sure of a > better way. I think Aleksey has been doing something similar to that with some bundles. Regards, Tomeu > Bobby > > On Thu, Aug 27, 2009 at 9:07 PM, Edward Cherlin wrote: >> >> We're going to do all of this for the XO-2 (ARM, dual haptic >> multitouch screens), and as with trees, the sooner we plant the >> better. >> >> Can we get a virtual ARM running on a Linux X86 system? It seems >> likely. QEMU has some form of ARM emulation. Also, >> >> https://wiki.cse.buffalo.edu/services/content/virtualmhz-arm-vm-arm >> The VirtualMHz for ARM (VM-arm) >> >> Virtera is shipping a free tool that can simulate a 217MHz ARM >> processor and embedded Linux system in real-time. The VirtualMHz for >> ARM (VM-arm) uses dynamic instruction compilation, rather than the >> interpretive simulation techniques used by competitors. >> >> Has anybody seen it? Tried it? Liked it? >> >> On Thu, Aug 27, 2009 at 1:11 PM, Ton van Overbeek >> wrote: >> > There have been demos to run Sugar on a Nokia N810 (ARM based) >> > starting from the Debian Armel packages. >> > Probably a good idea to check with the Debian folks. Debian supports >> > multiple architectures for their >> > distributions. >> > I do have a N810 myself, but I will be very busy the next few months >> > (relocating back to Europe), >> > so I will not have much time to contribute (and yes, touchscreen, >> > stylus, virtual keyboard, etc. are >> > problematic with Sugar). >> > ___ >> > Sugar-devel mailing list >> > Sugar-devel@lists.sugarlabs.org >> > http://lists.sugarlabs.org/listinfo/sugar-devel >> > >> >> >> >> -- >> Edward Mokurai Cherlin >> Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name, and >> Children are >> my nation. The Cosmos is my dwelling place, the Truth my destination. >> http://earthtreasury.org/ >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
