Re: Problems with soas
[cc'ing to sugar-devel] On Mon, Apr 20, 2009 at 01:51, Aaron Konstam akons...@sbcglobal.net wrote: What is wrong? Does the usb stick have to be formatted ext2, for example or can it be NTFS? I think it can be either FAT or ext2, but I guess the safest bet is making it FAT16. Others more knowledgeable may be able to comment. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #9307 NORM Not Tri: 100% reliable way to test a DCON creates the wrong colors bug
I am not sure if anybody reads the OLPC trac anymore but this demo can show us a DCON bug which probably should be fixed in the gen 1.5 version. Since the program reproduces the bug in 100% of the time, I wish you good debugging. (If it turns out to be just an X bug then I do not know whether it will be fixed ever so never mind.) Zarro Boogs per Child wrote: #9307: 100% reliable way to test a DCON creates the wrong colors bug -+-- Reporter: NoiseEHC | Owner: jg Type: defect |Status: new Priority: normal | Milestone: Not Triaged Component: x window system | Version: Mass Production Hardware Keywords: | Next_action: never set Verified: 0| Deployment_affected: Blockedby: | Blocking: -+-- Run the attached program from the Terminal activity on an XO which has 801 and has power saving activated and wait until first the screen dims and then until the animation stops. After you wake the machine the colors will be wrong. Repeat 3 times to get back the good colors. Now if it a DCON bug then you should probably fix it before gen 1.5 comes out. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Notes on service discovery XS/XO
(Cross posted to the Sugar list, I am hoping to discuss this stuff with the Sugar folks in Paris as well.) I've reviewed the XS 0.6 / 0.7 development plans, and one area that I have to address is service discovery: how does an XO figure out cheaply (in network RF terms) what services are available on this network. More importantly, how do 5K XOs in a crowded school (and crowded RF) accomplish the same with minimal network use? When ths issue was mentioned in the past there were some suggestions of mdns/dns-sd. Last week I worked my way through the specs, avahi docs and any information I could find of mdns/dns-sd in server-centric and crowded wireless environments. The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. Square peg, meet roundness. So my plan (targetting 0.7-ish, perhaps 0.6) is to use old, unexciting, tried-and-true DNS. Oh the horror, I am so uncool, I don't have a twitter channel either :-) My plan looks as follows ... On the XS side: - The XS serves DNS names for services -- so we will continue expanding the list of services. I'll put together a wikipage with the domain names associated to each service. - DNS allows the server to additional data to clients on a request, data that the server things that the client will need soon. If possible, I'd like to configure whatever DNS server we use to proactively feed the whole list of local names, with long TTLs, to the clients when they ask about 'schoolserver'. If you know how to configure BIND, dnsmasq or djbdns (tinydns) to do this, I'm all ears. - The XS will publish a CJSON-encoded (and perhaps SSH-cert-signed) list of services and protocol versions offered at http://schoolserver/services - the server-side implementation will appropriate http cache-headers, so for smart http client that knows how to say if-modified-since or Etag can save significant traffic. On the XO side: - On the NM ifup hook (which triggers when we associate to a new network), if the network looks like the network we registered on (the DNS search path matches the base domain of the schoolserver it is registered against) then request http://schoolserver/services - The service list retrieved can be checked cheaply via a local cli tool and/or a Sugar library call. This cli / Sugar library call also answers cheaply are we in an XS network? question. - Tools can completely ignore these sugar/xo specific things and just perform a dns lookup for the servicename, if it fails, the service isn't offered :-) This is less network efficient but it is a valid behaviour, and accepted for compatibility. Any tools that we expect to be in use in dense environments should avoid these pointless lookups, perhaps by using a wrapper that performs the local (cheap) checks. - For under a tree or home use scenarios, dns-sd/mdns are fantastic. Unfortunately, in dense wireless scenarios they cause a complete meltdown, so we want to ensure that XO/SoaS builds avoid, stop and kill kill kill! any mdns/dns-sd activity when there's a School Server. If you've read this far - congrats! - this is all very wordy, but it boils down to: - I'll use good old DNS plus an HTTP-served cheat-sheet. This keeps the chatter down. - Using the cheat-sheet, the XO/SoaS client side tools can know easily and cheaply whether they are in an XS network and what services are offered. and it's not that much work. But it is a key point on how we structure the XO-XS interactions. Comments? Suggestions? Hands ready to help implement? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Notes on service discovery XS/XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Langhoff wrote: The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. mDNS assumes all of the above things. DNS-SD does not. DNS-SD is perfectly happy to work on a standard DNS server. From the spec This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery. (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) I'm not particularly knowledgeable about the XS service discovery requirements, nor about DNS, so I can't reasonably tell you to use DNS-SD. What I can say is that it seems like it should be workable. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknsW+UACgkQUJT6e6HFtqSx5QCglzpN+96F9aTAH05KnsQszg3E vy4An0lCtq/z04OKiFVvv5TvXUcNnkZ5 =TRBq -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Problems with soas
Given Mitch's advice, I would recommend trying a factory-fresh 1-2G stick and not formatting at all. -walter On Mon, Apr 20, 2009 at 3:14 AM, Tomeu Vizoso to...@sugarlabs.org wrote: [cc'ing to sugar-devel] On Mon, Apr 20, 2009 at 01:51, Aaron Konstam akons...@sbcglobal.net wrote: What is wrong? Does the usb stick have to be formatted ext2, for example or can it be NTFS? I think it can be either FAT or ext2, but I guess the safest bet is making it FAT16. Others more knowledgeable may be able to comment. Regards, Tomeu ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #9307 NORM Not Tri: 100% reliable way to test a DCON creates the wrong colors bug
noiseehc wrote: I am not sure if anybody reads the OLPC trac anymore but this demo can show us a DCON bug which probably should be fixed in the gen 1.5 version. Since the program reproduces the bug in 100% of the time, I wish you good debugging. (If it turns out to be just an X bug then I do not know whether it will be fixed ever so never mind.) i've tried this, and you're right, the colors for your program are wrong after the resume. but they're only wrong for your program -- neither my xfce desktop nor a full color image displayed by xv exhibit the problem. i'm not sure what this suggests, but my feeling is that it's not a DCON problem. paul Zarro Boogs per Child wrote: #9307: 100% reliable way to test a DCON creates the wrong colors bug -+-- Reporter: NoiseEHC | Owner: jg Type: defect |Status: new Priority: normal | Milestone: Not Triaged Component: x window system | Version: Mass Production Hardware Keywords: | Next_action: never set Verified: 0| Deployment_affected: Blockedby: | Blocking: -+-- Run the attached program from the Terminal activity on an XO which has 801 and has power saving activated and wait until first the screen dims and then until the animation stops. After you wake the machine the colors will be wrong. Repeat 3 times to get back the good colors. Now if it a DCON bug then you should probably fix it before gen 1.5 comes out. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Notes on service discovery XS/XO
benjamin m. schwartz wrote: Martin Langhoff wrote: The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. mDNS assumes all of the above things. DNS-SD does not. DNS-SD is perfectly happy to work on a standard DNS server. From the spec This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery. (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) the last i looked at (and actually used) dns-sd to solve the discovery problem, it seemed that dns-sd development had stalled. (and i haven't had a reason to look since.) i believe we used code from Sun, which was all i could find at the time, and it wasn't what you'd call production ready. on the other hand, we were using it in a somewhat non-standard way -- in fact, we switched to mdns soon after because it fit our deployment model better, since we didn't really have a central server. the XS model may be a better fit. (this was all 3 or 4 years ago, btw.) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [Sugar-devel] Notes on service discovery XS/XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 20, 2009 at 07:26:30AM -0400, Benjamin M. Schwartz wrote: Martin Langhoff wrote: The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. mDNS assumes all of the above things. DNS-SD does not. DNS-SD is perfectly happy to work on a standard DNS server. From the spec This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery. (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) I'm not particularly knowledgeable about the XS service discovery requirements, nor about DNS, so I can't reasonably tell you to use DNS-SD. What I can say is that it seems like it should be workable. DNS-SD using unicast DNS seems reasonable to me too. Looking closer at the RFC, the initial service queries do have an added overhead in that a layer of indirection is used (not SRV - A, but instead PTR - SRV + TXT - A). But standard DNS optimizations apply, so SOA record should allow clients to preserve bandwidth through caching. In other words: Install dnsmasq on the XOs, use plain standard DNS internally and on the wire, setup DNS-SD entries in a standard nameserver on the XS, and extend Sugar to support DNS-SD. I'd be happy to help compose standard BIND9 files, if that is what will be used on the XS. - 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) iEYEARECAAYFAknsflUACgkQn7DbMsAkQLiL2wCfV/HuaLPQ0kv/mvYH4fdImsIs ookAnAu5ir3uxxKNjCdTwu4gfNxdE4hZ =7Jde -END PGP SIGNATURE- ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Sugar-devel] Notes on service discovery XS/XO
On Mon, Apr 20, 2009 at 3:53 PM, Jonas Smedegaard d...@jones.dk wrote: DNS-SD using unicast DNS seems reasonable to me too. If we can do without the avahi gunk, and use it in a way that is not optimised for user driven browsing but for automated selection of services, then it might work. Looking closer at the RFC, the initial service queries do have an added overhead in that a layer of indirection is used (not SRV - A, but instead PTR - SRV + TXT - A). But standard DNS optimizations apply, so SOA record should allow clients to preserve bandwidth through caching. Can we teach dnsmasq to push all the relevant records with the SOA record? In other words: Install dnsmasq on the XOs, use plain standard DNS internally and on the wire, setup DNS-SD entries in a standard nameserver on the XS, and extend Sugar to support DNS-SD. I'd be happy to help compose standard BIND9 files, if that is what will be used on the XS. If we have a dnsmasq resident expert, I rather use your help transitioning to dnsmasq (note - with several bits of weird dhcp rules). There is no upside to BIND and plenty of downsides, starting with the 25MB memory footprint. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Server-devel] Fwd: [Sugar-devel] testing backup and restore on SoaS
Forwarded from sugar-devel, Are the backup scripts available? We have a script that allows us to register SoaS and we want to try the backup scripts with that. Thanks! Dave -- Forwarded message -- From: Hamilton Chua hamilton.c...@gmail.com Date: Fri, Apr 17, 2009 at 7:43 AM Subject: [Sugar-devel] testing backup and restore on SoaS To: sugar-de...@lists.sugarlabs.org Hello, I would like to try out testing backup and restore on SoaS but I can't seem to find the scripts or folders mentioned at http://wiki.laptop.org/go/XS_Blueprints:Datastore_Simple_Backup_and_Restore Are the backup scripts included in the SoaS build ? If they're not, any reason why we can't include them ? Thanks, Hamilton ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Sugar-devel] Notes on service discovery XS/XO
martin wrote: On Mon, Apr 20, 2009 at 3:53 PM, Jonas Smedegaard d...@jones.dk wrote: DNS-SD using unicast DNS seems reasonable to me too. If we can do without the avahi gunk, and use it in a way that is not optimised for user driven browsing but for automated selection of services, then it might work. Looking closer at the RFC, the initial service queries do have an added overhead in that a layer of indirection is used (not SRV - A, but instead PTR - SRV + TXT - A). But standard DNS optimizations apply, so SOA record should allow clients to preserve bandwidth through caching. Can we teach dnsmasq to push all the relevant records with the SOA record? In other words: Install dnsmasq on the XOs, use plain standard DNS internally and on the wire, setup DNS-SD entries in a standard nameserver on the XS, and extend Sugar to support DNS-SD. I'd be happy to help compose standard BIND9 files, if that is what will be used on the XS. If we have a dnsmasq resident expert, I rather use your help transitioning to dnsmasq (note - with several bits of weird dhcp rules). There is no upside to BIND and plenty of downsides, starting with the 25MB memory footprint. i'm a big fan of dnsmasq, but be sure it will fulfill all your needs before doing too much work on it -- it's not quite a full-fledged DNS server -- as an example, dnsmasq doesn't support CNAME: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2006q1/000583.html - ask interesting questions simon kelley (dnsmasq author) is extremely helpful on the dnsmasq list, btw, so it shouldn't be too hard to get interesting answers, as well. :-) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Fwd: [Sugar-devel] testing backup and restore on SoaS
On Mon, Apr 20, 2009 at 4:13 PM, Dave Bauer dave.ba...@gmail.com wrote: Forwarded from sugar-devel, Are the backup scripts available? We have a script that allows us to register SoaS and we want to try the backup scripts with that. Grab them from the same place where you found the ejabberd pkg ;-) -- you're looking for ds-backup-client. Note that you'll need to get in motion to teach SoaS about registering to the School Server, something that Sugar knows how to do, or used to know.. Give the scripts a read so you'll see how they work, and what bits of Sugar we need (somehow, sugar profile needs to know about a backup server, etc). cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Fwd: [Sugar-devel] testing backup and restore on SoaS
On Mon, Apr 20, 2009 at 10:30 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Mon, Apr 20, 2009 at 4:13 PM, Dave Bauer dave.ba...@gmail.com wrote: Forwarded from sugar-devel, Are the backup scripts available? We have a script that allows us to register SoaS and we want to try the backup scripts with that. Grab them from the same place where you found the ejabberd pkg ;-) -- you're looking for ds-backup-client. Hmmm, I got the ejabberd from olpcxs-testing repository. I don't see ds-backup-client there. I guess I am looking in the wrong place. Dave Note that you'll need to get in motion to teach SoaS about registering to the School Server, something that Sugar knows how to do, or used to know.. Give the scripts a read so you'll see how they work, and what bits of Sugar we need (somehow, sugar profile needs to know about a backup server, etc). 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-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Sugar-devel] Notes on service discovery XS/XO
On Mon, Apr 20, 2009 at 6:56 PM, Jonas Smedegaard d...@jones.dk wrote: I don't understand your question. Sounds like prefetching that isn't part of dns (id you perhaps think of DHCP here?) I don't have my well-worn DNS and BIND book with me right now but I am positive that the server side can decide to give the client additional entries. It's colloquially known as the additional section. Been doing BIND and djbdns admin for 10+ years. If we have - for example - 10 services, it is an excellent bw saving strategy to push the 10 services in the additional section, so that the client caches it in the first request, rather than issuing 10 separate requests. You are right that BIND9 is a bastard with memory consumption, and it makes sense to use dnsmasq on the XS. I just didn't think of that - I Well, right now we have BIND + DHCP. BIND is a serious mismatch for the XS. We are doing quite a bit of advanced dhcpd configuration which we will want to replicate. For a quick summary: - We just have a small handful of important local names to serve via DNS (but we may want to push them in the 'additional section' as oulined above). - For the DHCP svc we listen on various network interfaces and assign addresses in _different netblocks_ according to the network interface that received the request. Tricky! See http://dev.laptop.org/git/projects/xs-config/tree/altfiles/etc/sysconfig/olpc-scripts/dhcpd.conf.1 - To make matters more complex, my plan is to evolve towards assigning different addresses once the user registered -- to cordon-off internet access, a bit like pay-to-play internet-cafe routers do. That requires a bit of poking at the dhcp daemon to whitelist specific MAC addresses and forcing the user to re-request the lease. - It would be nice to resolve dhcp-assigned hostname-addresses and PTRs suggested it as a caching-only on the XOs. ISC DHCPd has a complex macro language, however, which might be the upsight you cannot live without. Beware that it is DHCP, not DNS ;-) dnsmasq offers dhcp. If we put in the effort to switch from BIND, and get consolidate on a single daemon, we win big time. Remember: this is an embedded platform and each meg we free up is a bit more scale we eke out of low-spec'd servers. Tell me more specifically what you fear can be tricky to handle in dnsmasq, either DHCP or DNS parts, and I shall have a look if I am any good at helping out. Well, I've fleshed it out as much as I could. I don't think it's easy, and it probably means discussing it in the dnsmasq list (pfg says the author is really nice), trying out alternatives, seeing what works, whether any of the weird configs we want works but gobbles up RAM, segfaults on Wednesdays, etc. But if you can give me a hand taking control of this, it will be hugely welcome, and you got guaranteed free beers in all the conferences we meet at. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Check this out
Aaron Konstam writes: Unfortunately, currently it seems to be only able to translate whole pages not words or paragraphs. The more you have, the better you can translate: I offered several different types of foods. They liked a banana more than onions, roast beef, garlic, or beets. In general, fruit flies like a banana. We tested numerous items in our trebuchet. A flower didn't fly very far. A lead sinker went really far. A banana went a medium distance. In general, fruit flies like a banana. (and this is why text-to-speech is a very hard problem) Look up run or set in a dictionary if you still have hope of single-word translation. Now add idioms and bad grammar: I threw my mother from the train a kiss goodbye. Ouch! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Notes on service discovery XS/XO
jonas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 20, 2009 at 09:45:28AM -0400, p...@laptop.org wrote: benjamin m. schwartz wrote: Martin Langhoff wrote: The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. mDNS assumes all of the above things. DNS-SD does not. DNS-SD is perfectly happy to work on a standard DNS server. From the spec This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery. (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) the last i looked at (and actually used) dns-sd to solve the discovery problem, it seemed that dns-sd development had stalled. (and i haven't had a reason to look since.) i believe we used code from Sun, which was all i could find at the time, and it wasn't what you'd call production ready. on the other hand, we were using it in a somewhat non-standard way -- in fact, we switched to mdns soon after because it fit our deployment model better, since we didn't really have a central server. the XS model may be a better fit. (this was all 3 or 4 years ago, btw.) Here's my understanding: * DNS-SD is a formalized use of DNS records to store services (rather than hosts, the most popular use of DNS records). * mDNS is DNS over multicast (using DNS-SD to resolve services). sigh. please disregard everything i wrote in the paragraph above. i was mistakenly referring to DNS-SD when i should have been referring to SLP (service location protocol). we migrated from SLP to mDNS. this has nothing to do with anything martin has proposed for the XS. sorry! :-) paul So it seems to me that if you've switched from DNS-SD to mDNS, then in fact you are still relying on DNS-SD, just using an additional layer on top of it. A good introduction (assumably more reliable than Wikipedia) is http://www.dns-sd.org/ - Jonas =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO Gen 1.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Watlington wrote: The enabling chipset is hot off the fab line, the VX855 [2]. This single chip provides ... a 3D graphics engine, an HD video decoder It's worth remembering that the only existing driver that supports either of these features is a pure binary blob. The Openchrome drivers have no 3D support, never mind video decode support. Even their Xv support is glitchy. In other words, this GPU represents a regression, compared to the Geode LX, unless you're willing to run with (famously unreliable, unsupported) binary-only drivers. So don't get too excited. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkns6IoACgkQUJT6e6HFtqSCTQCfacYu5ZvaF1mqPga0vwiNvvUZ u5YAnRNSmM+0FtuaRL2TTCGhjU/Pk4ly =5D6T -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO Gen 1.5
John Watlington wrote: The enabling chipset is hot off the fab line, the VX855 [2]. This single chip provides ... a 3D graphics engine, an HD video decoder It's worth remembering that the only existing driver that supports either of these features is a pure binary blob. The Openchrome drivers have no 3D support, never mind video decode support. Even their Xv support is glitchy. In other words, this GPU represents a regression, compared to the Geode LX, unless you're willing to run with (famously unreliable, unsupported) binary-only drivers. So don't get too excited. But this should improve with VIA now having employed Harald Welte of gnuviolations.org fame to help them move forward in the open source world. They have released their drivers and some manuals for their GPUs now. So no 3D just yet, but then that's not exactly a regression compared to the geeode video either. Details of Harald's VIA related OSS releases can be seen at the link below including links to various HW programming manuals. Peter http://laforge.gnumonks.org/weblog/linux/via/index.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [Sugar-devel] Notes on service discovery XS/XO
On Mon, Apr 20, 2009 at 9:46 PM, Jonas Smedegaard d...@jones.dk wrote: Here's my understanding: I've read the damned specs, don't worry. I need help getting sh*t done because there's a lot of stuff to do. any takers? m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Sugar-devel] Notes on service discovery XS/XO
On Mon, 20 Apr 2009, Martin Langhoff wrote: On Mon, Apr 20, 2009 at 6:56 PM, Jonas Smedegaard d...@jones.dk wrote: I don't understand your question. Sounds like prefetching that isn't part of dns (id you perhaps think of DHCP here?) I don't have my well-worn DNS and BIND book with me right now but I am positive that the server side can decide to give the client additional entries. It's colloquially known as the additional section. Been doing BIND and djbdns admin for 10+ years. If we have - for example - 10 services, it is an excellent bw saving strategy to push the 10 services in the additional section, so that the client caches it in the first request, rather than issuing 10 separate requests. my initial reaction to this is that it's going to look to the client exactly the same as a bad guy trying to poison DNS by sending unasked for responses, how do the clients tell the difference? also note that this will require that you run some sort of DNS cache on the client, otherwise the particular app that did the DNS request will go on with life and make the exact same request again. You are right that BIND9 is a bastard with memory consumption, and it makes sense to use dnsmasq on the XS. I just didn't think of that - I Well, right now we have BIND + DHCP. BIND is a serious mismatch for the XS. We are doing quite a bit of advanced dhcpd configuration which we will want to replicate. For a quick summary: - We just have a small handful of important local names to serve via DNS (but we may want to push them in the 'additional section' as oulined above). - For the DHCP svc we listen on various network interfaces and assign addresses in _different netblocks_ according to the network interface that received the request. Tricky! See http://dev.laptop.org/git/projects/xs-config/tree/altfiles/etc/sysconfig/olpc-scripts/dhcpd.conf.1 - To make matters more complex, my plan is to evolve towards assigning different addresses once the user registered -- to cordon-off internet access, a bit like pay-to-play internet-cafe routers do. That requires a bit of poking at the dhcp daemon to whitelist specific MAC addresses and forcing the user to re-request the lease. take a look at packetfence. it does exactly that job today, for free, on linux (among other platforms) I think it even handles the multiple interfaces/netblocks problem, but I could be wrong. David Lang___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO Gen 1.5
But this should improve with VIA now having employed Harald Welte of gnuviolations.org fame to help them move forward in the open source world. They have released their drivers and some manuals for their GPUs now. So no 3D just yet, but then that's not exactly a regression compared to the geeode video either. Details of Harald's VIA related OSS releases can be seen at the link below including links to various HW programming manuals. I do not know. I tried to download the specification to their processor and gave up after seeing the massive registration and request forms required. It is clearly ridiculous. If somebody has the spec please put it onto the wiki, please. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Collaboration Bugs in today's Olin Play Session
On Mon, Apr 20, 2009 at 4:33 AM, Dave Bauer dave.ba...@gmail.com wrote: Its jabber.sugarlabs.org aka schoolserver.solutiongrove.com ejabberd-xs-2.0.3 Should be XS 0.5.2 Can you post the complete version string as reported by `rpm -qa ejabberd-xs` ? I published various 2.0.3's, the early ones had a broken @online@ with exactly the symptoms that Caroline reported. IIRC, you want an ejabberd-xs at least 2.0.3-4 - see http://xs-dev.laptop.org/xsrepos/testing/olpc/9/i386/ 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] Notes on service discovery XS/XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Langhoff wrote: The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. mDNS assumes all of the above things. DNS-SD does not. DNS-SD is perfectly happy to work on a standard DNS server. From the spec This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery. (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) I'm not particularly knowledgeable about the XS service discovery requirements, nor about DNS, so I can't reasonably tell you to use DNS-SD. What I can say is that it seems like it should be workable. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknsW+UACgkQUJT6e6HFtqSx5QCglzpN+96F9aTAH05KnsQszg3E vy4An0lCtq/z04OKiFVvv5TvXUcNnkZ5 =TRBq -END PGP SIGNATURE- ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [Sugar-devel] Notes on service discovery XS/XO
On Mon, Apr 20, 2009 at 3:53 PM, Jonas Smedegaard d...@jones.dk wrote: DNS-SD using unicast DNS seems reasonable to me too. If we can do without the avahi gunk, and use it in a way that is not optimised for user driven browsing but for automated selection of services, then it might work. Looking closer at the RFC, the initial service queries do have an added overhead in that a layer of indirection is used (not SRV - A, but instead PTR - SRV + TXT - A). But standard DNS optimizations apply, so SOA record should allow clients to preserve bandwidth through caching. Can we teach dnsmasq to push all the relevant records with the SOA record? In other words: Install dnsmasq on the XOs, use plain standard DNS internally and on the wire, setup DNS-SD entries in a standard nameserver on the XS, and extend Sugar to support DNS-SD. I'd be happy to help compose standard BIND9 files, if that is what will be used on the XS. If we have a dnsmasq resident expert, I rather use your help transitioning to dnsmasq (note - with several bits of weird dhcp rules). There is no upside to BIND and plenty of downsides, starting with the 25MB memory footprint. 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] Collaboration Bugs in today's Olin Play Session
On Mon, Apr 20, 2009 at 3:38 PM, Dave Bauer dave.ba...@gmail.com wrote: I have an online group that contains @all@ Good move on the upgrade -- you should also change @all@ to @online. @all@ is known not to work with that release, and even if it did work... you really want @online@ instead of @a...@. 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
[Server-devel] livecd patch - creator: -d opt and matching setdebug() method that gets rpm in debug mode
Useful to diagnose problems with %post scripts during the build. This patch adds the method to the ImageCreator class, and the corresponding options to image-creator and livecd-creator -- Actually, quite a handy trick when my dodgy %post scripts mess up during initial/anaconda installs. 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 0001-creator-d-opt-and-matching-setdebug-method-tha.patch Description: Binary data ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [Sugar-devel] Notes on service discovery XS/XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 20, 2009 at 09:45:28AM -0400, p...@laptop.org wrote: benjamin m. schwartz wrote: Martin Langhoff wrote: The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. mDNS assumes all of the above things. DNS-SD does not. DNS-SD is perfectly happy to work on a standard DNS server. From the spec This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery. (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) the last i looked at (and actually used) dns-sd to solve the discovery problem, it seemed that dns-sd development had stalled. (and i haven't had a reason to look since.) i believe we used code from Sun, which was all i could find at the time, and it wasn't what you'd call production ready. on the other hand, we were using it in a somewhat non-standard way -- in fact, we switched to mdns soon after because it fit our deployment model better, since we didn't really have a central server. the XS model may be a better fit. (this was all 3 or 4 years ago, btw.) Here's my understanding: * DNS-SD is a formalized use of DNS records to store services (rather than hosts, the most popular use of DNS records). * mDNS is DNS over multicast (using DNS-SD to resolve services). So it seems to me that if you've switched from DNS-SD to mDNS, then in fact you are still relying on DNS-SD, just using an additional layer on top of it. A good introduction (assumably more reliable than Wikipedia) is http://www.dns-sd.org/ - 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) iEYEARECAAYFAkns0S8ACgkQn7DbMsAkQLipkACfW9CWHqtdtytFZuNrCzm0Jmrd jIkAn3zqgu6B6Ic7sFeINPjVGpmjmKCA =J4B8 -END PGP SIGNATURE- ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [Sugar-devel] Notes on service discovery XS/XO
On Mon, 20 Apr 2009, Martin Langhoff wrote: On Mon, Apr 20, 2009 at 6:56 PM, Jonas Smedegaard d...@jones.dk wrote: I don't understand your question. Sounds like prefetching that isn't part of dns (id you perhaps think of DHCP here?) I don't have my well-worn DNS and BIND book with me right now but I am positive that the server side can decide to give the client additional entries. It's colloquially known as the additional section. Been doing BIND and djbdns admin for 10+ years. If we have - for example - 10 services, it is an excellent bw saving strategy to push the 10 services in the additional section, so that the client caches it in the first request, rather than issuing 10 separate requests. my initial reaction to this is that it's going to look to the client exactly the same as a bad guy trying to poison DNS by sending unasked for responses, how do the clients tell the difference? also note that this will require that you run some sort of DNS cache on the client, otherwise the particular app that did the DNS request will go on with life and make the exact same request again. You are right that BIND9 is a bastard with memory consumption, and it makes sense to use dnsmasq on the XS. I just didn't think of that - I Well, right now we have BIND + DHCP. BIND is a serious mismatch for the XS. We are doing quite a bit of advanced dhcpd configuration which we will want to replicate. For a quick summary: - We just have a small handful of important local names to serve via DNS (but we may want to push them in the 'additional section' as oulined above). - For the DHCP svc we listen on various network interfaces and assign addresses in _different netblocks_ according to the network interface that received the request. Tricky! See http://dev.laptop.org/git/projects/xs-config/tree/altfiles/etc/sysconfig/olpc-scripts/dhcpd.conf.1 - To make matters more complex, my plan is to evolve towards assigning different addresses once the user registered -- to cordon-off internet access, a bit like pay-to-play internet-cafe routers do. That requires a bit of poking at the dhcp daemon to whitelist specific MAC addresses and forcing the user to re-request the lease. take a look at packetfence. it does exactly that job today, for free, on linux (among other platforms) I think it even handles the multiple interfaces/netblocks problem, but I could be wrong. David Lang___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
