What is cooking on the XS pot?
A couple of interesting things - The restore UI for ds-backup is complete. Go test it -- following this recipe to track the latest and greatest moodle code... http://lists.laptop.org/pipermail/server-devel/2009-March/003126.html - User aliasing for ds-backup and login is what I am working on today. It applies to the use case scenario of my laptop has been replaced, and I want the XS to know my old identity. - The httpd-crcsync thing is on fire. Toby said it's ready for testing, Alex found some bugs in 64 bits, Rusty fixed them, and the crowd went c-r-a-z-y [0]. Mozilla's Gerv said that implementing the client smarts in Mozilla is the most popular gsoc project evah [1]. [1] http://lists.laptop.org/pipermail/http-crcsync/2009-March/thread.html [2] https://wiki.mozilla.org/Community:SummerOfCode09:WebPagesOverRsync cheers, martin -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: What is cooking on the XS pot?
On Tue, Mar 31, 2009 at 3:29 PM, Martin Langhoff martin.langh...@gmail.com wrote: - User aliasing for ds-backup and login is what I am working on today. It applies to the use case scenario of my laptop has been replaced, and I want the XS to know my old identity. Fleshed out here http://wiki.laptop.org/go/XS_Blueprints:User_account_aliasing cheers, martin -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] I hear you
On 03/29/09 23:42, qu...@laptop.org wrote: I've tested twinkle and it worked quite well for point to point calls. Both it and ihu could probably be modified to accept appropriate parameters to operate within the Sugar context if needed. I'm also aware of someone working again on the point-multipoint audio idea that I tried out a couple of years ago ... a press-to-talk (PTT) multicast portable radio emulation. Some time ago I made linphone work on my XO. It was fully functional and reliable, but the GUI is really ugly also by the standards of a traditional desktop. The reason why linphone is interesting at all is that the engine is well isolated from the UI so it's easy to replace it with a Sugar UI, perhaps written in Python, without breaking everything in the core. They have already implemented GTK, console and test UIs. Oh, and it also does video with H263, MPEG4, theora and H264 codecs! http://www.linphone.org/index.php/eng/features -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] I hear you
On Tue, Mar 31, 2009 at 8:24 PM, Bernie Innocenti ber...@codewiz.org wrote: On 03/29/09 23:42, qu...@laptop.org wrote: I've tested twinkle and it worked quite well for point to point calls. Both it and ihu could probably be modified to accept appropriate parameters to operate within the Sugar context if needed. I'm also aware of someone working again on the point-multipoint audio idea that I tried out a couple of years ago ... a press-to-talk (PTT) multicast portable radio emulation. Some time ago I made linphone work on my XO. It was fully functional and reliable, but the GUI is really ugly also by the standards of a traditional desktop. FWIW, Asterisk is interesting in working with Sugar Labs:) If someone is able to champion this, it is likely that we could turn this into a partnership with digum. david The reason why linphone is interesting at all is that the engine is well isolated from the UI so it's easy to replace it with a Sugar UI, perhaps written in Python, without breaking everything in the core. They have already implemented GTK, console and test UIs. Oh, and it also does video with H263, MPEG4, theora and H264 codecs! http://www.linphone.org/index.php/eng/features -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ - Show quoted text - ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Apache proxy CRCsync mozilla gsoc project?
One thing we need to do is think about the headers carefully, as this is the aspect of the project we could promote as a web standard. There is a large amount of flexibility we could put in to this, but as Rusty has said, if there is a way someone can implement a protocol wrong they will. So we need to keep it as simple as possible. At the moment we append the block size and hashes for the blocks to the request. The response has a content encoding set, and will need a strong hash added. The number of blocks is fixed at 20 for the moment, with a hash size of 30 bits, which felt like a nice balance between overhead and performance. This keeps our header at around the 128 byte mark when you have base64 encoded the hashes (we dont pad the base64 encoding, so 30bits-5bytes). The other aspect we need to standardise is the encoding of the response. Again at the moment this is a very simplistic binary encoding. The response is encoded in sections, each beginning with either a 'L' to indicate a literal section or a 'B' to indicate a matched block (actually we could make one a default and save a few bytes here). A literal section then has a 4 byte int in network byte order for the size of the literal section, followed by the data. a block section has a single byte indicating the block number. There is no error checking in the encoding itself, this is assumed to be taken care in other layers, and we through in a strong hash on the whole file to make sure this is correct. There is a risk if we get a corruption of the literal length byte that we could try read a very large amount of data, not sure if this is acceptable. Toby 2009/3/31 Gervase Markham g...@mozilla.org On 25/03/09 18:20, Toby Collett wrote: Not a GSoC project, just a project(crcsync is the name at the moment). Initial target is a double proxy server, one each end of the slow link, with dreams of web standards and browser integration following. Seems to me that both projects need the same upstream server extension to be able to send the deltas down. Current state of the apache modules is that all the major pieces are in place but not a lot testing and no optimisation has been carried out yet. OK. So maybe the browser integration for this, or at least the groundwork for it, is what our SoC project should be. Particularly if you have Apache modules that work already. See https://wiki.mozilla.org/Community:SummerOfCode09:WebPagesOverRsync for where we are at the moment. We are getting incredible amounts of interest in this project - more than all the others combined. It seems like an idea whose time has come. Gerv -- This email is intended for the addressee only and may contain privileged and/or confidential information ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] What is cooking on the XS pot?
On Tue, Mar 31, 2009 at 3:29 PM, Martin Langhoff martin.langh...@gmail.com wrote: - User aliasing for ds-backup and login is what I am working on today. It applies to the use case scenario of my laptop has been replaced, and I want the XS to know my old identity. Fleshed out here http://wiki.laptop.org/go/XS_Blueprints:User_account_aliasing cheers, martin -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] Gadget on XS
Hi, I am trying to get gadget working on my XS at schoolserver.solutiongrove.com First I downloaded the source and built it, but I could not find any indication that gadget was installed. How can I tell if it is working? Next I tried the gadget package http://koji.fedoraproject.org/koji/taskinfo?taskID=1261886 RPM but it required ejabberd package. RPM says this is not installed. (I did install python-twisted which was another requirement of the RPM). Does anyoe have any advice on getting gadget working? Thanks! Dave -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Gadget on XS
2009/3/31 Dave Bauer d...@solutiongrove.com: Next I tried the gadget package http://koji.fedoraproject.org/koji/taskinfo?taskID=1261886 RPM but it required ejabberd package. RPM says this is not installed. (I did install python-twisted which was another requirement of the RPM). What version of the XS have you got? If you are running 0.5.2, you should have ejabberd-xs-2.0.3-2.fc9.olpc.i386 . The problem is that the ejabberd-xs package should say it 'provides:ejabberd' but it doesn't. That's a bug on my side. Does anyoe have any advice on getting gadget working? Options - Lie to rpm about the dependency (for now) while I fix the ejabberd-xs pkg...? - Replace ejabberd-xs with a vanilla fedora ejabberd that is at least 2.0.3 If you post about your adventures with Gadget, I'll sure be following your notes. As most people know, I am a bit hesitant about whether Gadget is the right thing for the XS. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Gadget on XS
On Tue, Mar 31, 2009 at 2:06 PM, Martin Langhoff martin.langh...@gmail.comwrote: 2009/3/31 Dave Bauer d...@solutiongrove.com: Next I tried the gadget package http://koji.fedoraproject.org/koji/taskinfo?taskID=1261886 RPM but it required ejabberd package. RPM says this is not installed. (I did install python-twisted which was another requirement of the RPM). What version of the XS have you got? If you are running 0.5.2, you should have ejabberd-xs-2.0.3-2.fc9.olpc.i386 . The problem is that the ejabberd-xs package should say it 'provides:ejabberd' but it doesn't. That's a bug on my side. Does anyoe have any advice on getting gadget working? Options - Lie to rpm about the dependency (for now) while I fix the ejabberd-xs pkg...? Ah I see, yeah I can try this and let you know. Conceivable gadget can coexist with the Moodle/Ejabberd integration you are working on. We are also contemplating using this as a public collaboration server, so we are not following the XS recommendations completely. Dave - Replace ejabberd-xs with a vanilla fedora ejabberd that is at least 2.0.3 If you post about your adventures with Gadget, I'll sure be following your notes. As most people know, I am a bit hesitant about whether Gadget is the right thing for the XS. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Gadget on XS
Ok I have the gadget RPM installed. What should I see in the admin interface? I looked at virtual hosts - nodes - modules and I don't see anything likely. How can I tell if gadget is doing anything interesting? Thanks Dave -- Dave Bauer d...@solutiongrove.com http://solutiongrove.com ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Apache proxy CRCsync mozilla gsoc project?
On Tue, Mar 31, 2009 at 8:32 PM, Toby Collett t...@plan9.net.nz wrote: We are only using 30 bit hashes, so even if it was a perfect hash it is possible you could get a collision. Having said that our collision space is only the single web request, so should reduce chances of error. IIRC, if rsync thinks there was a collision on the weak hash, it rolls again through the file with the weak hash and a different seed. Maybe we could include a differently seeded fingerprint? Is that what you were thinking? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Apache proxy CRCsync mozilla gsoc project?
We are only using 30 bit hashes, so even if it was a perfect hash it is possible you could get a collision. Having said that our collision space is only the single web request, so should reduce chances of error. Toby 2009/4/1 Martin Langhoff martin.langh...@gmail.com On Mon, Mar 30, 2009 at 8:26 PM, Toby Collett t...@plan9.net.nz wrote: There is no error checking in the encoding itself, this is assumed to be taken care in other layers, and we through in a strong hash on the whole file to make sure this is correct. Is that right? I thought what Rusty was saying re crcsync is that crc is strong, even when rolling? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- This email is intended for the addressee only and may contain privileged and/or confidential information ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Apache proxy CRCsync mozilla gsoc project?
The plan was to include something like an sha1 hash of the original file in the response headers. Then once the file has been decoded you can check to make sure it matches. If not you can resend the request without the black hash header and get the file the oldfashioned way. Toby 2009/4/1 Martin Langhoff martin.langh...@gmail.com On Tue, Mar 31, 2009 at 8:32 PM, Toby Collett t...@plan9.net.nz wrote: We are only using 30 bit hashes, so even if it was a perfect hash it is possible you could get a collision. Having said that our collision space is only the single web request, so should reduce chances of error. IIRC, if rsync thinks there was a collision on the weak hash, it rolls again through the file with the weak hash and a different seed. Maybe we could include a differently seeded fingerprint? Is that what you were thinking? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- This email is intended for the addressee only and may contain privileged and/or confidential information ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Apache proxy CRCsync mozilla gsoc project?
Hi Toby, The plan was to include something like an sha1 hash of the original file in the response headers. Then once the file has been decoded you can check to make sure it matches. If not you can resend the request without the black hash header and get the file the oldfashioned way. re-sending http requests can be dangerous. The request might have triggered an action like delete the last person from the list. When you resend it could delete two users rather than one. Remember that one of the aims of this work is to allow cacheing of dynamic requests, so you can't just assume the pages are marked as cacheable (which usually implies that a 2nd request won't do any harm). Certainly including a strong whole-page hash is a good idea, but if the strong hash doesn't match, then I think you need to return an error, just like if you got a network outage. The per-block rolling hash should also be randomly seeded as Martin mentioned. That way if the user does ask for the page again then the hashing will be different. You need to send that seed along with the request. In practice hashing errors will be extremely rare. It is extremely rare for rsync to need a 2nd pass, and it uses a much weaker rolling hash (I think I used 16 bits by default for the per block hashes). The ability to do multiple passes is what allows rsync to get away with such a small hash, but I remember that when I was testing the multiple-pass code I needed to weaken it even more to get any reasonable chance of a 2nd pass so I could be sure the code worked. Cheers, Tridge ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Apache proxy CRCsync mozilla gsoc project?
On Tuesday 31 March 2009 23:29:23 Martin Langhoff wrote: On Mon, Mar 30, 2009 at 8:26 PM, Toby Collett t...@plan9.net.nz wrote: There is no error checking in the encoding itself, this is assumed to be taken care in other layers, and we through in a strong hash on the whole file to make sure this is correct. Is that right? I thought what Rusty was saying re crcsync is that crc is strong, even when rolling? Well, 'strong' here is relative. In order to keep the checksum length finite and hence encode more blocks we only use a portion of the bits; it's a tradeoff. And so an overall checksum is important, just to verify that the final result is correct. Cheers, Rusty. ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Apache proxy CRCsync mozilla gsoc project?
On Wed, Apr 1, 2009 at 12:48 AM, Rusty Russell ru...@rustcorp.com.au wrote: Well, 'strong' here is relative. In order to keep the checksum length finite and hence encode more blocks we only use a portion of the bits; it's a tradeoff. And so an overall checksum is important, just to verify that the final result is correct. Hmmm, if we need an overall checksum... - The server cannot stream data to the client because it has to wait until it has all of it. Even if our current implementation doesn't have this, having a protocol that allows streaming is high in my list. - Aren't we back to the 2-hashes-will-get-us-sued square? frankly, a hash collision that has the same content length and over the same syntax format (html/xml) is so rare as to be... well, not really something I would expect :-) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
