Re: Touch-screen OMAP3-based netbook as XO-2 prototype?
John - Thanks for keeping this on the radar. I have a pair on order (one with keyboard, one without) in the hopes of both doing some experimenting and trying out that USB host/host connection glue, too. I'll let the list know when we get them here at 1CC to play with - they're pre-ordered and allegedy shipping in July, but I haven't had a shipment notification nor has my credit card been charged yet. - Ed On Jul 7, 2009, at 4:53 PM, John Gilmore wrote: The new Touch Book by Always Innovating looks interesting as a possible prototype for the XO-2. It looks vaguely like an ordinary netbook, but the electronics are behind the screen as in the XO-1, as is one of the batteries. So the keyboard half can detach from the screen/electronics package. The two are connected via USB (and the keyboard provides a second battery, doubling life to 10 hrs). $299 in quantity one ($399 with keyboard). Fanless, uses TI OMAP3, internal SDHC card for storage, internal USB slots for connectivity. Open source oriented company, running Linux, XFCE, etc (Ångström Distro, which started from OpenEmbedded). They are willing to license the hardware design, or even give it away to open-source-oriented projects. Motherboard is tiny; photo below. http://www.alwaysinnovating.com/home/ http://www.alwaysinnovating.com/company/design.htm http://www.magniel.com/omaplaptop.html What it doesn't have that the XO-2 wants: * Multi-touch or all-fingers touch-screen-keyboard. * Mary Lou's screens. * Camera * Two screens (however I bet you could attach two of them to each other with a little bit of USB host/host connection glue). FYI. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New kernel branch for XO-1 and XO-1.5 development
I've spent some time merging the XO-1 and XO-1.5 kernels into a new
branch and made some tweaks to the in-kernel RPM build scripts. From
now on, all development for both XO-1 and XO-1.5 will be done on the
olpc-2.6.30 branch of the olpc-2.6 repository [1]. As Linus releases
new kernels, I will be rebasing [2] the OLPC changes on top of Linus'
releases and creating new olpc-${kernelversion} branches to make it
easier to move our code forward and upstream.
Since the kernels for the two generations of XO boards have been
merged, I've had to change the commands for building RPMs and
kernels. These are:
make xo_1_defconfig: configure kernel for OLPC XO-1
make xo_1.5_defconfig : configure kernel for OLPC XO-1.5
make xo_1-kernel-rpm : build XO-1 kernel RPM
make xo_1_5-kernel-rpm : build XO-1.5 kernel RPM
make olpc-kernel-rpm : build both XO-1 and XO-1.5 kernel RPMs
To differentiate between an XO-1 and XO-1.5 RPM, the generation
name is now inserted into the RPM name. For example:
kernel-2.6.30_xo1-20090708.1.olpc.1fd3a66.i586.rpm - XO-1 RPM
kernel-2.6.30_xo1.5-20090708.1.olpc.1fd3a66.i586.rpm - XO-1.5 RPM
Note that currently there is nothing keeping anyone from installing a
kernel meant for one gen machine on a different gen machine. Just
don't do that. :)
I've also added the ability to build RPMs from trees that have
non-commited changes. If this is done, the RPM will be tagged
as dirty:
kernel-2.6.30_xo1-20090708.1.olpc.1fd3a66_DIRTY.i586.rpm
I will update wiki with this information.
Enjoy,
~Deepak
[1] dev.laptop.org:/git/olpc-2.6
[2] http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
for manpage, http://www.eecs.harvard.edu/~cduan/technical/git/git-5.shtml
for a quick summary.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: DNS Mischief
On Sun, Jul 5, 2009 at 8:36 PM, Michael Stonemich...@laptop.org wrote: d) rewrite as an NSS module? e) rewrite in an external DNS resolver? Either of these would make it much easier to play with your patch, eliminating the whole now recompile your C library from scratch step. ;-) (d) would be the cleanest, and the code involved ought to be quite short. With (e) you could make the names available to other machines our your local network, which could be cute (or awful, as you like). Network-disconnection issues also bear thinking about -- if you use a local IPv6 address for a local resource, can you handle its migration to the real network later as it roams off the mesh? (It might be easiest to handle this as a clean disconnect/reconnect rather than going down the mobile IP path.) Thanks for running with this idea, Michael! (Although wearing my security hat I'd have to caution that MD5 has been deprecated for 13 years now, and even SHA1 is not recommended for new use . Use http://www.ouah.org/ogay/sha2/ -- it's just two files to add, tomcrypt not required.) --scott (Ob code review: I think you just want to fabricate a new link-local address entry based on the hash, rather than cloning and altering the existing LL address. Link-local addresses have the prefix fe80::/64, with the lower 64 bits constructed from the first 64 bits of SHA256(hostname). You also should probably make sure that the hostname you're hashing is the full canonical host name, ie cscott.skiffserv.dyndns.org. (note trailing dot) not cscott or cscott.skiffserv or some other abbreviation. You just need to confirm where you fit into the search domain feature of resolv.conf, esp since all of the searched domains will yield valid addresses. You really want to disable 'search-domain' for this link-local-resolution, since search-domain is really meant as a human-typing aid, not for machine use.) -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] poor man's mmap sliding window on Python 2.5.x
The process is doing a linear read through the file, and is slow enough that it appears only to grow. But if I run another process that allocates a lot of memory, then the kernel does discard pages pages. So are you saying that two identical processes that mmap large amounts of memory, (much larger than the DRAM and with no swap space), then walk sequentially through the memory, will split the memory evenly among them, and will complete in a reasonable amount of time. But one process will get very slow and never complete? Sounds like a reproducible test case like that would be worth reporting to the linux-kernel mailing list, to see if anybody recognizes the bug, or wants to go hunting it. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] poor man's mmap sliding window on Python 2.5.x
On Thu, Jul 9, 2009 at 1:45 PM, John Gilmoreg...@toad.com wrote: The process is doing a linear read through the file, and is slow enough that it appears only to grow. But if I run another process that allocates a lot of memory, then the kernel does discard pages pages. So are you saying that two identical processes that mmap large amounts of memory, (much larger than the DRAM and with no swap space), then walk sequentially through the memory, will split the memory evenly among them, and will complete in a reasonable amount of time. But one process will get very slow and never complete? No, something much simpler. No bug in the mmap implementation but in my testing. I was testing with 1 process walking the file slowly linearly. Watching `top` it _looked_ like it was exhausting memory and getting slower. The kernel did seem to discard other process' clean pages, because all other processes were idle. However, if instead of just watching top I start other processes, (a Browse.xo instance), the kernel reacts quickly, discards old pages from the test script, and Browse runs nicely. So the problem was in my procedure. mmap works as it should. 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: New kernel branch for XO-1 and XO-1.5 development
On Wed, Jul 8, 2009 at 4:43 PM, Deepak Saxenadsax...@laptop.org wrote:
I've spent some time merging the XO-1 and XO-1.5 kernels into a new
branch and made some tweaks to the in-kernel RPM build scripts. From
now on, all development for both XO-1 and XO-1.5 will be done on the
olpc-2.6.30 branch of the olpc-2.6 repository [1]. As Linus releases
new kernels, I will be rebasing [2] the OLPC changes on top of Linus'
releases and creating new olpc-${kernelversion} branches to make it
easier to move our code forward and upstream.
Since the kernels for the two generations of XO boards have been
merged, I've had to change the commands for building RPMs and
kernels. These are:
make xo_1_defconfig : configure kernel for OLPC XO-1
make xo_1.5_defconfig : configure kernel for OLPC XO-1.5
make xo_1-kernel-rpm : build XO-1 kernel RPM
make xo_1_5-kernel-rpm : build XO-1.5 kernel RPM
make olpc-kernel-rpm : build both XO-1 and XO-1.5 kernel RPMs
To differentiate between an XO-1 and XO-1.5 RPM, the generation
name is now inserted into the RPM name. For example:
kernel-2.6.30_xo1-20090708.1.olpc.1fd3a66.i586.rpm - XO-1 RPM
kernel-2.6.30_xo1.5-20090708.1.olpc.1fd3a66.i586.rpm - XO-1.5 RPM
Note that currently there is nothing keeping anyone from installing a
kernel meant for one gen machine on a different gen machine. Just
don't do that. :)
I've also added the ability to build RPMs from trees that have
non-commited changes. If this is done, the RPM will be tagged
as dirty:
kernel-2.6.30_xo1-20090708.1.olpc.1fd3a66_DIRTY.i586.rpm
I will update wiki with this information.
this is great, thanks! being able to build rpms like that again is
quite handy. I know its not under your job description Deepak, but do
you know of a similar way to build debs, or documentation on that
process?
bp
Enjoy,
~Deepak
[1] dev.laptop.org:/git/olpc-2.6
[2] http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
for manpage, http://www.eecs.harvard.edu/~cduan/technical/git/git-5.shtml
for a quick summary.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: New kernel branch for XO-1 and XO-1.5 development
On Wed, 8 Jul 2009 22:24:35 -0400 Bobby Powers bobbypow...@gmail.com wrote: [...] this is great, thanks! being able to build rpms like that again is quite handy. I know its not under your job description Deepak, but do you know of a similar way to build debs, or documentation on that process? You should just be able to do a make deb-pkg; this is a mechanism that's upstream, so it will work for any 2.6 kernel tree. Alternatively, you could use debian's 'make-kpkg', but the chances of that working has varied greatly over time. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DNS Mischief
On Sun, Jul 5, 2009 at 8:36 PM, Michael Stonemich...@laptop.org wrote: d) rewrite as an NSS module? e) rewrite in an external DNS resolver? Either of these would make it much easier to play with your patch, eliminating the whole now recompile your C library from scratch step. ;-) Pff. It got us this far. :) (d) would be the cleanest, and the code involved ought to be quite short. With (e) you could make the names available to other machines our your local network, which could be cute (or awful, as you like). The real advantage of (e) is that you can make it work on many platforms. The problem with (e) is that it seems to take more than 80 lines of code. Network-disconnection issues also bear thinking about -- if you use a local IPv6 address for a local resource, can you handle its migration to the real network later as it roams off the mesh? (It might be easiest to handle this as a clean disconnect/reconnect rather than going down the mobile IP path.) I've thought a bit about this and, for the time-being, my cost/benefit analysis (and recent professional experience) argues in favor of making apps better at tolerating address changes in preference to going down the mobility road. Thanks for running with this idea, Michael! My pleasure; thanks for taking the time to reply to me. (Although wearing my security hat I'd have to caution that MD5 has been deprecated for 13 years now, and even SHA1 is not recommended for new use. Use http://www.ouah.org/ogay/sha2/ -- it's just two files to add, tomcrypt not required.) I agree that MD5 and SHA1 are deprecated as /cryptographic/ hash functions, but I don't think that we care. Here's why: Cryptographic hash functions are characterized by three notable properties: 1. preimage resistance for a fixed result R, how hard is to it to find a message M such that H(M) == R? 2. second-preimage resistance for a fixed message M, how hard is it to find M' != M such that H(M) == H(M')? 3. collision resistance how hard is it to find two distinct messages M, M' such that H(M) == H(M')? My claim is that we only care about second-preimage resistance against a random attacker (as opposed to an optimal malicious attacker). I believe that this is true because I think that second-preimage attacks by random attackers accurately model the risk that a user types in a domain name which, /by chance, rather than by malice/, happens to hash to an address that collides with an address already being provided by a different service on the network, or, equivalently, the risk that a user randomly chooses a name the hash of which collides with the hash of an already present name. (In my present view, plain DNS was never meant to handle the threats posed by malicious adversaries and it should not be relied upon to do so. Those risks are, in my view, more adequately controlled by other tools like petnames, reputation systems, PGP, SSH, and TLS.) Am I just plain wrong? (Ob code review: I think you just want to fabricate a new link-local address entry based on the hash, rather than cloning and altering the existing LL address. Link-local addresses have the prefix fe80::/64, with the lower 64 bits constructed from the first 64 bits of SHA256(hostname). I chose to clone existing addresses because I thought it was a convenient way to get the addresses' zone ids (called sin6_scope_id in the sockaddr_in6 struct) right. Have you got a better way to do this part? You also should probably make sure that the hostname you're hashing is the full canonical host name, ie cscott.skiffserv.dyndns.org. (note trailing dot) not cscott or cscott.skiffserv or some other abbreviation. Hmm. I can see why you might want that from a network principles standpoint, but I'm not sure that I'm convinced by your argument. I guess: patches welcome. :) -- The design issue that I find myself most interested in after having gotten this far is: My current design is not in any way integrated into the recursive name resolution process. This means that people who want to bind multiple names must do so by adding an address to all their interfaces/zones for each name they want to bind. On the other hand, if I made something that were integrated into the name resolution process, they could just run a nameserver for their domain and then everything else should just work. (I think.) Thoughts? Kind regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New kernel branch for XO-1 and XO-1.5 development
Congratulations on the merge. Note that currently there is nothing keeping anyone from installing a kernel meant for one gen machine on a different gen machine. Just don't do that. :) Eventually if both machines are going to run a standard Fedora release, the same binary kernel will have to be able to run on both (and figure it out at runtime, like it does with most other x86-based systems). I'm presuming from your message that that's scheduled to happen some time ... later ... John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [Sugar-devel] GPA XS Report
On Tue, Jul 7, 2009 at 10:27 PM, Caroline Meekssolutiongr...@gmail.com wrote: On Tue, Jul 7, 2009 at 10:20 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Wed, Jul 8, 2009 at 9:46 AM, Anurag Goelagoe...@gmail.com wrote: We booted several computers with SoaS and changed the network settings from the default (jabber.sugarlabs.org) to the IP address on the XS. After doing this, the computers in the computer lab still would That is a workaround to the missing register button in SoaS, right? no, we are still just trying to get the machines in the lab to see the Jabber Server in the lab via the server setting in the control panel. I think some of your comments below may still be relevant but I don't entirely understand. I suspect that part of the problem is that you are using the IP address. Sugar will see whatever DNS or IP addr you provide there and will try to connect to jabber and create an account as follows: - machine-id@jabberservername On XO hardware, machine-id is the serialnumber. On other hw, it creates a random string on first boot. The problem with the scheme is that jabber on the XS expects a very specific jabber servername for the account: its own name (as given to domain_config) prefixed with 'schoolserver.' OK, we can workaround this two ways, Use schoolserver as the jabber server name in the settings then 1) set the IP in /etc/hosts as a quick hack to make sure things work 2) set up the SoaS to use the built in DNS on the XS. Using the DNS seems problematic, probably due to my lack on knowledge. If we do that we need to defer to the network DNS for everything except the schoolserver hostname. If kids take the stick home, what happens with the DNS if we put the XS into resolv.conf? The SoaS is not getting DHCP from the schoolserver due to the setup where the XS is just inserting into the same LAN as the clients. Dave If the name doesn't match that format, then it breaks. The workaround is to use schoolserver.mydomain in the SoaS control panel. A more proper solution is probably to bring back 'registration' :-) hth, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list sugar-de...@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-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-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [Sugar-devel] GPA XS Report
On Wed, Jul 8, 2009 at 10:39 PM, Dave Bauerdave.ba...@gmail.com wrote: OK, we can workaround this two ways, Use schoolserver as the jabber server name in the settings then 1) set the IP in /etc/hosts as a quick hack to make sure things work 2) set up the SoaS to use the built in DNS on the XS. I'd strongly recommend avoid touching /etc/hosts or /etc/resolv.conf on every SoaS. Using the DNS seems problematic, probably due to my lack on knowledge. The changes are trivial -- a list of ~8 names need to resolve to the XS's internal address. DNS can be complicated, but this is completely trivial. Get those names added to the existing DNS server, and you're sorted. If we do that we need to defer to the network DNS for everything except the schoolserver hostname. If kids take the stick home, what happens with the DNS if we put the XS into resolv.conf? resolv.conf gets re-written by NM all the time. Hardcoding it is no go. 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] [Sugar-devel] GPA XS Report
On Wed, Jul 8, 2009 at 7:32 AM, Martin Langhoff martin.langh...@gmail.comwrote: On Wed, Jul 8, 2009 at 10:39 PM, Dave Bauerdave.ba...@gmail.com wrote: OK, we can workaround this two ways, Use schoolserver as the jabber server name in the settings then 1) set the IP in /etc/hosts as a quick hack to make sure things work 2) set up the SoaS to use the built in DNS on the XS. I'd strongly recommend avoid touching /etc/hosts or /etc/resolv.conf on every SoaS. Using the DNS seems problematic, probably due to my lack on knowledge. The changes are trivial -- a list of ~8 names need to resolve to the XS's internal address. DNS can be complicated, but this is completely trivial. Get those names added to the existing DNS server, and you're sorted. I think here is the rub. What is the existing DNS server and how would we get access to it? Certainly Boston Public Schools is not going to put something in their DNS server for us. Is there a workaround? If we do that we need to defer to the network DNS for everything except the schoolserver hostname. If kids take the stick home, what happens with the DNS if we put the XS into resolv.conf? resolv.conf gets re-written by NM all the time. Hardcoding it is no go. 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 -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
