[Sugar-devel] FSF attitude to xo and sugar
n Fri, Aug 28, 2009 at 7:20 AM, Walter Bender walter.ben...@gmail.comwrote: === 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] [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 walter.ben...@gmail.com 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
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
[readding sugar-devel] On Fri, Aug 28, 2009 at 12:04, Peter Robinsonpbrobin...@gmail.com 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] The ARM is near
On Fri, Aug 28, 2009 at 12:23, Peter Robinsonpbrobin...@gmail.com wrote: On Fri, Aug 28, 2009 at 12:04, Peter Robinsonpbrobin...@gmail.com 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
[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] [IAEP] FSF attitude to xo and sugar
On Fri, Aug 28, 2009 at 8:57 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Fri, Aug 28, 2009 at 14:08, Bill Kerrbillk...@gmail.com wrote: On Fri, Aug 28, 2009 at 7:18 PM, Bert Freudenberg b...@freudenbergs.de wrote: On 28.08.2009, at 11:33, Bill Kerr wrote: n Fri, Aug 28, 2009 at 7:20 AM, Walter Bender walter.ben...@gmail.com 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] The ARM is near
Martin Langhoff wrote: On Fri, Aug 28, 2009 at 12:33 PM, Tomeu Vizosoto...@sugarlabs.org 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
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 walter.ben...@gmail.comwrote: On Fri, Aug 28, 2009 at 8:57 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Fri, Aug 28, 2009 at 14:08, Bill Kerrbillk...@gmail.com wrote: On Fri, Aug 28, 2009 at 7:18 PM, Bert Freudenberg b...@freudenbergs.de wrote: On 28.08.2009, at 11:33, Bill Kerr wrote: n Fri, Aug 28, 2009 at 7:20 AM, Walter Bender walter.ben...@gmail.com 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
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
On Fri, Aug 28, 2009 at 9:07 AM, Caroline Meekssolutiongr...@gmail.com 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 walter.ben...@gmail.com wrote: On Fri, Aug 28, 2009 at 8:57 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Fri, Aug 28, 2009 at 14:08, Bill Kerrbillk...@gmail.com wrote: On Fri, Aug 28, 2009 at 7:18 PM, Bert Freudenberg b...@freudenbergs.de wrote: On 28.08.2009, at 11:33, Bill Kerr wrote: n Fri, Aug 28, 2009 at 7:20 AM, Walter Bender walter.ben...@gmail.com 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
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 writtenupdated 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:07 PM, jpriti...@pobox.com 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
On Fri, Aug 28, 2009 at 4:26 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Martin Langhoff wrote: On Fri, Aug 28, 2009 at 3:41 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu 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
[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 28 Aug 2009, at 11:57, Tomeu Vizoso wrote: On Fri, Aug 28, 2009 at 12:51, Peter Robinsonpbrobin...@gmail.com 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
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 Fri, Aug 28, 2009 at 12:02:44PM +0200, Tomeu Vizoso wrote: On Fri, Aug 28, 2009 at 11:37, Jonas Smedegaardd...@jones.dk 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] The ARM is near
On Fri, Aug 28, 2009 at 18:55, Jonas Smedegaardd...@jones.dk wrote: On Fri, Aug 28, 2009 at 12:02:44PM +0200, Tomeu Vizoso wrote: On Fri, Aug 28, 2009 at 11:37, Jonas Smedegaardd...@jones.dk 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] 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 07:11:54AM -0400, Walter Bender wrote: On Fri, Aug 28, 2009 at 6:57 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Fri, Aug 28, 2009 at 12:51, Peter Robinsonpbrobin...@gmail.com 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] 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] 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 Smedegaardd...@jones.dk 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] 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] 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 Smedegaardd...@jones.dk wrote: On Fri, Aug 28, 2009 at 12:02:44PM +0200, Tomeu Vizoso wrote: On Fri, Aug 28, 2009 at 11:37, Jonas Smedegaardd...@jones.dk 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] 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 Smedegaardd...@jones.dk 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] 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 Smedegaardd...@jones.dk 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] [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 Cherlinecher...@gmail.com 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] 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 Marting...@garycmartin.com 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? inline: version3_1.pnginline: version3_2.pnginline: version3_3.pnginline: version3_4.png 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] 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] [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] [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 bastiengue...@googlemail.comwrote: 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] windows7sins
On Fri, Aug 28, 2009 at 3:08 AM, Joshua N Pritikinjpriti...@pobox.com 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
On Fri, Aug 28, 2009 at 4:35 PM, Bastien bastiengue...@googlemail.comwrote: 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
[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] 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 Simmonsnices...@gmail.com 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
Re: [Sugar-devel] Ad-hoc network identification badge
On Fri, Aug 28, 2009 at 5:41 PM, Gary C Marting...@garycmartin.com wrote: On 28 Aug 2009, at 21:51, Eben Eliason wrote: On Fri, Aug 28, 2009 at 4:16 PM, Gary C Marting...@garycmartin.com 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] 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 Marting...@garycmartin.com wrote: On 28 Aug 2009, at 21:51, Eben Eliason wrote: On Fri, Aug 28, 2009 at 4:16 PM, Gary C Marting...@garycmartin.com 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] 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
[Sugar-devel] Fwd: SarynPaint: a Java program packaged for the OLPC
Rafael Ortiz -- Forwarded message -- From: Ben Wiley Sittler bsitt...@gmail.com Date: Sat, Aug 29, 2009 at 12:29 AM Subject: SarynPaint: a Java program packaged for the OLPC To: OLPC Developer's List de...@laptop.org 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
