Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Mon, Apr 12, 2010 at 09:31:25PM -0400, Bernie Innocenti wrote: On Mon, 2010-04-12 at 23:54 +0100, Peter Robinson wrote: Bernie, I'm not sure the point of this point at this point in time. To copy and paste part of the response I did to the other thread on fedora-olpc for others benefit. I personally don't see the point discussing it because from where I sit I believe it will be supported well in both and continue to be so. That way people have the choice. It might well get to a stage where the newer versions of sugar won't run in RHEL/CentOS due to whatever deps at which point we get to a situation where that release becomes like 0.84 is currently and is a long term support release. I don't see why its hard to support both because its not. The package maintenance is simple and is done easily by a couple of people. There will be Fedora and it will continue to be supported in Fedora for the developers and the like that want the bleeding edge and then there will be the EL branch for those that don't like so much blood. Its called choice. There's no reason to limit it. There's not much point discussing it at the moment as RHEL-6 isn't out yet, yes its in beta but its not out. I agree on this, but it misses the point :-) I'm sure maintaining the Sugar 0.84 packages will be easy in RHEL6 as it is in F11. I've even back-ported Sugar 0.88 to Fedora 11 with minimal tweaks. Most end-user support issues lay within base OS components rather than the relatively small codebase of Sugar. That's what I'm feeling all time started from the first time of my participating in sugar when I packaged sugar for several distros. Here are some real-world examples from this development cycle: * GSM connectivity requires up-to-date versions of udev and modem-manager to support USB dongles commonly available in stores * Playing multimedia content downloaded from the Internet requires gstreamer with up-to-date codecs * activities such as Record tend to uncover obscure bugs in GStreamer * Browse depends on xulrunner for security and compatiblity with web standards. Surfing the web today with a version of Firefox from 3 years ago would be unthinkable * ...not to mention NetworkManager... I would guesstimate that 80% of my time went into fixing platform bugs and just 20% on Sugar itself. In part, this is because I could offload the actual bugfixing to helpful people such as alsroot, silbe, sayamindu, mtd and others. In short RHEL-6 isn't out yet, the associated CentOS6 release is quite a while away as a result. Also ARM isn't a supported platform there. Sugar is about options and I think having both options will be of benefit to different users. I believe the leading edge Fedora will continue to be a platform for development and then others in the know or deployments themselves can make the decision as to what's best for them. In practice, choosing the distro independently of Sugar won't be feasible on the XO until: 1) we merge (or kill) all the OLPC customizations. dsd and sdz have done a lot of work in this direction, but there are still a number of rogue packages in F11-XO1. 2) we switch to a real package system for activities with full support for dependency checking and a build cluster for multiple targets. After this is done, it remains to be seen if someone who is using RHEL-6 on the XO would be able to file a bug in Red Hat's Bugzilla and actually get it fixed for free. I have a feeling one would need to purchase an enterprise support contract of some kind in order to attract the necessary developer attention. and thats why I like 0install way - it is not tied to particular distro (packaging system) but can get benefits from all major distros (via PackageKit) and add distro agnostic packaging system. In my plans create distro agnostic sugar distribution entirely based on 0install - on most recent systems, users need only several clicks to install sugar w/o root privileges and even if sugar didn't packaged at all for this particular distro. -- Aleksey ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Tue, Apr 13, 2010 at 2:31 AM, Bernie Innocenti ber...@codewiz.org wrote: On Mon, 2010-04-12 at 23:54 +0100, Peter Robinson wrote: Bernie, I'm not sure the point of this point at this point in time. To copy and paste part of the response I did to the other thread on fedora-olpc for others benefit. I personally don't see the point discussing it because from where I sit I believe it will be supported well in both and continue to be so. That way people have the choice. It might well get to a stage where the newer versions of sugar won't run in RHEL/CentOS due to whatever deps at which point we get to a situation where that release becomes like 0.84 is currently and is a long term support release. I don't see why its hard to support both because its not. The package maintenance is simple and is done easily by a couple of people. There will be Fedora and it will continue to be supported in Fedora for the developers and the like that want the bleeding edge and then there will be the EL branch for those that don't like so much blood. Its called choice. There's no reason to limit it. There's not much point discussing it at the moment as RHEL-6 isn't out yet, yes its in beta but its not out. I agree on this, but it misses the point :-) Not exactly. I'm sure maintaining the Sugar 0.84 packages will be easy in RHEL6 as it is in F11. I've even back-ported Sugar 0.88 to Fedora 11 with minimal tweaks. Most end-user support issues lay within base OS components rather than the relatively small codebase of Sugar. Here are some real-world examples from this development cycle: Agreed. * GSM connectivity requires up-to-date versions of udev and modem-manager to support USB dongles commonly available in stores RH updates those sort of components regularly to ensure support. * Playing multimedia content downloaded from the Internet requires gstreamer with up-to-date codecs That is not due to up to date codecs but rather patent free codecs. Completely different issues. That is as valid with F-13 today as RHEL-5 * activities such as Record tend to uncover obscure bugs in GStreamer Nothing stopping these being fixed in RHEL/CentOS. * Browse depends on xulrunner for security and compatiblity with web standards. Surfing the web today with a version of Firefox from 3 years ago would be unthinkable RHEL updates this regularly as well and actively moves to the current version. I believe RHEL-5 has firefox 3.5 * ...not to mention NetworkManager... Mention what about it? We don't use any of the latest NM features, its stable and the maintainer actively assists and accepts patches. I would guesstimate that 80% of my time went into fixing platform bugs and just 20% on Sugar itself. In part, this is because I could offload the actual bugfixing to helpful people such as alsroot, silbe, sayamindu, mtd and others. You are not alone, you should see my BZ queue. In short RHEL-6 isn't out yet, the associated CentOS6 release is quite a while away as a result. Also ARM isn't a supported platform there. Sugar is about options and I think having both options will be of benefit to different users. I believe the leading edge Fedora will continue to be a platform for development and then others in the know or deployments themselves can make the decision as to what's best for them. In practice, choosing the distro independently of Sugar won't be feasible on the XO until: 1) we merge (or kill) all the OLPC customizations. dsd and sdz have done a lot of work in this direction, but there are still a number of rogue packages in F11-XO1. In fact alot of the differences in packages were merged back in by me in the F-10/F-11 timeframe. I'm well aware of those issues, I still track them closely. I just wish it was the same with the kernel :-) 2) we switch to a real package system for activities with full support for dependency checking and a build cluster for multiple targets. One word. PackageKit. Then its agnostic for all the distributions. After this is done, it remains to be seen if someone who is using RHEL-6 on the XO would be able to file a bug in Red Hat's Bugzilla and actually get it fixed for free. I have a feeling one would need to purchase an enterprise support contract of some kind in order to attract the necessary developer attention. You've obviously not dealt with them then on the RHEL side of things. I work for a company that had over 1200 RHEL systems. There are advantages to both approaches and I don't see that supporting both is going to be an issue to do so at least in the short term. I don't see that we need to rule out either option. Peter ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] OLPC deployment in Georgia? (Tbilisi not Atlanta)
http://www.civil.ge/eng/article.php?id=22153 Does anyone have some info to share about this anouncement? Is it a confirmed deployment? thanks Sean ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Weekly Infrastructure Meeting Reminder
#startmeeting #info Weekly Infrastructure meeting: #info Volunteer Infrastructure Gang (http://olpcorps.org/ ), #info Sugarlabs Infrastructure Team (http://sugarlabs.org/ ), #info and TreeHousers (http://me.etin.gs/treehouse/ ) #info Date: 2010-04-13 #info Time: 20:00 UTC (16:00 EST, 22:00 CET) #info Agenda: http://openetherpad.org/ogycAYFJtg #info Location: #treehouse on irc.oftc.net #link http://embed.mibbit.com/?server=irc.oftc.netchannel=%23treehouse cu dogi PS: Please improve the agenda ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] [SPAM]An intelligent sneakernet for the XO.
I was encouraged by some people at the RIT OLPC user's group to make a post on this mailing list about a project of mine that is in the proof of concept stage at the moment but needs a bit of polish. The idea is basically a decentralized discussion forum that automatically propagates itself amongst all XO laptops that are in range. I've created a working (but somewhat clunky) system that does exactly that using some clever Perl scripts, the innd usenet server and a web based interface to news that runs on top of lighttpd on the XO. You can see what I have done so far at http://teotwawki.steubentech.com I have a working LiveCD as well as downloads that will work on an XO. I am interested in adding polish to this system and making it a lot more user friendly. I would also like to create a streamlined version that could work on smart phones and other mobile devices. either via bluetooth or 802.11. I have propagation working through USB thumb drive exchange and do intend to make dialup transfers work in the future. The CVS version is currently more up to date and has bug fixes that the current downloads do not have. but I can re-roll the downloads if anyone is interested. I just wanted to get your comments and see how I could best turn this into something that could benefit the OLPC community as well as the general public at large. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [SPAM]An intelligent sneakernet for the XO.
William Schaub wrote: The idea is basically a decentralized discussion forum that automatically propagates itself amongst all XO laptops that are in range. That's a great project! This is definitely something that OLPC and Sugar Labs are interested in. You should mention it on sugar-devel. I just wanted to get your comments and see how I could best turn this into something that could benefit the OLPC community as well as the general public at large. It sounds like you've already started thinking about what might be the most important problem here: supporting a variety of transports. Sugar currently uses Telepathy for all peer identification and communication, but different mechanisms are appropriate in different situations. I think you'll have the most success if you can be flexible enough to play well with a variety of identity and communication systems. The other important thing is to maintain a strong abstraction between storage and display so that new GUIs may be created without rewriting the core. It sounds like you're doing that too. The other fun problems relate to retention/transfer policy and space utilization, but those can likely be adapted after the design is in place. For plain text there's hardly a problem at all, but I expect you'll want to do more than just text. By the way, Sugar probably won't integrate anything that depends on Perl, so I suggest that you minimize your reliance on it. Also, for efficiency it would be cool if you could make sure that the background memory usage is small. --Ben signature.asc Description: OpenPGP digital signature ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] [SPAM]Re: [SPAM]An intelligent sneakernet for the XO.
Benjamin M. Schwartz wrote: William Schaub wrote: The idea is basically a decentralized discussion forum that automatically propagates itself amongst all XO laptops that are in range. That's a great project! This is definitely something that OLPC and Sugar Labs are interested in. You should mention it on sugar-devel. I just wanted to get your comments and see how I could best turn this into something that could benefit the OLPC community as well as the general public at large. It sounds like you've already started thinking about what might be the most important problem here: supporting a variety of transports. Sugar currently uses Telepathy for all peer identification and communication, but different mechanisms are appropriate in different situations. I think you'll have the most success if you can be flexible enough to play well with a variety of identity and communication systems. The other important thing is to maintain a strong abstraction between storage and display so that new GUIs may be created without rewriting the core. It sounds like you're doing that too. The other fun problems relate to retention/transfer policy and space utilization, but those can likely be adapted after the design is in place. For plain text there's hardly a problem at all, but I expect you'll want to do more than just text. By the way, Sugar probably won't integrate anything that depends on Perl, so I suggest that you minimize your reliance on it. Also, for efficiency it would be cool if you could make sure that the background memory usage is small. --Ben It is basically just a private usenet over adhoc wireless (or the mesh network) and other transports. Anything that can be done with usenet can be done with this system it is implemented mainly as a collection of native Linux software (the usenet server being one of them) and some scripts that make the usenet server exchange articles with whatever machine is detected using the perl scripts. I used Perl because that is the language I have the most experience with. and its really good for throwing things like this together in a hurry. I really want to implement the thing in Java so that I can try and run it on various smart phones. I may be getting a blackberry to play with soon for that purpose. As far as managing the space the news spool takes up is concerned with inn there is a storage method called the circular news filesystem. which basically fills up with articles and when it is full the earliest articles are overwritten with new ones. so you could dedicate a fixed amount of space for article storage and not consume more than that. I would be interested in getting this integrated in sugar but right now its way too much of a mess for that. I wish they would just distribute perl with sugar and be done with it but that will likely never happen. I'm sure I could re-write the glue in python or even C if I needed to. but I figure Perl is probably Ok to stick with for the early stages of the project. Since I want to make it work on smart phones and PDAs I will need to make a streamlined version that isn't just glue around INN. That version would likely be the one to consider for Sugar. I didn't start out with the idea of making it just an OLPC project but rather a generic Linux and eventually cross-platform project. but the idea first came up at an OLPC users group meeting and the XO-1 has been a nice platform to develop/test on. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [SPAM]Re: [SPAM]An intelligent sneakernet for the XO.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/13/2010 08:16 PM, William Schaub wrote: I would be interested in getting this integrated in sugar but right now its way too much of a mess for that. I wish they would just distribute perl with sugar and be done with it but that will likely never happen. I'm sure I could re-write the glue in python or even C if I needed to. but I figure Perl is probably Ok to stick with for the early stages of the project. Perl is part of every LSB-compliant Linux distribution (IIRC), and I believe it is shipped on the XO. We would like to guide you away from Perl since most of the developers have experience with Python, and thus we will be best able to help you with problems you encounter in that language. Furthermore, we feel that we can better maintain and review code written in a common language. - -- Luke Faraone http://luke.faraone.cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkvFDlAACgkQtrC51grHAgaXUQCggcZcQCuPzstYVE0QR9j+5p0c WyQAn1iGkjBKt0ao+hJUXn3pZXOcABgR =AZf7 -END PGP SIGNATURE- ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [SPAM]Re: [SPAM]An intelligent sneakernet for the XO.
Hi, Perl is part of every LSB-compliant Linux distribution (IIRC), and I believe it is shipped on the XO. No, not shipped on the XO. (Not shipped on XO-1, currently shipped on XO-1.5 but will be removed if we can work out how to avoid breaking dependencies by doing so.) - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] OLPC deployment in Georgia? (Tbilisi not Atlanta)
Since none of our laptops are certified for sale in Georgia, this comes as a complete surprise. Hopefully it's true! Cheers, wad On Apr 13, 2010, at 2:02 PM, Sean DALY wrote: http://www.civil.ge/eng/article.php?id=22153 Does anyone have some info to share about this anouncement? Is it a confirmed deployment? thanks Sean ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
