Joyride ROCKS!
Hi. I'm an OLPC fanatic, joyride addict, intermittent support-gangster, and occasional bug-reporter. I recently had the opportunity to compare Update.1 and Joyride (I needed to reflash to a signed image to retrieve my lost developer key), and I noticed some things: 1. The UI is looking very slick in Joyride. It feels less toy-like, in a good sense -- things are easier to find, and better-organized. 2. Certain normally grumpy aspects of the operating system work remarkably better in Joyride. Power management works, to the extent where it Does The Right Thing nearly all the time, and I rarely worry about recharging my XO every day. Wireless, too, works better, and NetworkManager is much more obedient than it used to be. 3. Joyride is actually more stable -- I don't see random hangs or user-visible glitches as much. I'd guess, from my own use, that Joyride has actually surpassed Update.1 in stability, even given Joyride's bleeding-edge nature. That, combined with all the improvements and new features, makes it even better! I know you guys are trying to make the XO software great, so I thought you might want to know that, from a (relative) outsider's perspective, your work is looking amazing, and has shown tremendous improvement. Keep up the good work! Cheers, Thomas Tuttle ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Serious problems with rescan networks on wakeup feature.
Hi. I just upgraded to joyride-1738, and the new feature that rescans for networks when the laptop wakes up is causing a lot of trouble for me. I often leave long-running connections such as IMAP or IRC open. Before the change, the laptop would wake up, the card would reassociate, and there was a good chance that my connection would still be up. After the change, the connections are almost always dropped, even if I just turned the laptop off for a few seconds. What would be *great* is if it waited 5 or 10 seconds, tried the existing connection, and then restarted scanning *if* it wasn't working anymore. The lag isn't that bad, and it makes the experience where you just closed the laptop a minute ago and are still on the same network better. If there's anything I can do to help with this, please let me know! Cheers, Thomas Tuttle ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Serious problems with rescan networks on wakeup feature.
On Sun, 2 Mar 2008 22:37:22 -0500, John Watlington [EMAIL PROTECTED] said: On Mar 2, 2008, at 7:49 PM, Thomas Tuttle wrote: The problem we have is the following: A student is using the laptop away from school/infrastructure, and is in simple mesh mode. In this mode, all service discovery and collboration is multicast.The student puts their computer to sleep (by closing the lid) and goes to school. Once they arrive at school, the last thing we want is for their laptop to try to use simple mesh --- it trashes spectrum and makes the school network not work, plus they won't see any of their friends that are (properly) connected through the school presence service. If we naively followed your suggestion above, the laptop would of course discover that the previous network state (simple mesh) was fine, and it would never discover that there were centralized services available. This reply is intended to spark discussion about better fixes. For example, how about only rescan when the laptop was in simple mesh mode when put to sleep, or if an attempt to reestablish the existing connection fails ? That sounds good, actually. Basically, if there's a better connection available, use it, but if we have a known-best one (i.e., an AP), stick with it. I think this should be configurable, so deployments could decide the best way to do it based on their coverage, and G1G1 users could put their favorite (i.e. home/work/school) APs first. Ooh, there's an idea -- could there be a preferred ESSID list that is tried before mesh? My XO knows about my school network, but never uses it until it's tried a mesh first. Cheers, Thomas Tuttle ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: tcp/ip assumptions
I'm confused as to what you mean by a relay system. If you mean it's a router, then it should route the NTP packets fine. If you mean it's an HTTP proxy, then NTP simply doesn't work over an HTTP proxy. I don't understand why you expect the XO to magically figure out how you want your network to work. NTP is routed over TCP/IP. If you want it to work, you have to provide TCP/IP routing to the server! If you don't want to, you can run an NTP server on your relay system. There's nothing wrong with the XO making assumptions as to the external services available, as the school servers will have NTP servers, and if the laptop is on the mesh network, it will have access to the server. If I've made an incorrect assumption here, or made a mistake, please let me know. Thanks, Thomas Tuttle On Mon, 28 Jan 2008 20:56:46 -0500, Mikus Grinbergs [EMAIL PROTECTED] said: I have a G1G1, which communicates via a local LAN to a relay system, which communicates to the internet. The server facilities (*just* for the XO - not needed by the regular systems on my LAN) I've now set up in the relay station are minimal (e.g., for DNS). The result is that many XO requests are not fulfilled by my relay system (for instance, a separate dialog may be needed - between the relay system and a *real* server out on the internet). I was looking at a trace of the packets on my local LAN. In the case of DNS, the XO issues three Type 28 requests (which my minimal relay station does not support), before issuing a Type 01, to which it eventually does get an answer. In the case of NTP, the XO issues scattershot requests to all server addresses it was able to extract [but receives no responses, because it tries to contact them directly, rather than going through the 'proxy' function in my relay system]. My conclusion: The tcp/ip function in the XO makes a number of assumptions as to the type (and timeliness) of the external SERVICES it expects to have been provided. I would have been happier if I had known about these beforehand, rather than having to discover what does or does_not work in the environment I currently have. [Might some setups in a target country be as minimal as mine?] mikus ___ 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: Classroom tools
There's nothing preventing Johnny from doing this without a laptop. It's just easier with the laptop, but then again, so are legitimate tasks. I don't think OLPC should be getting into the business of creating anti-cheat provisions. I do think that tagging objects with the people who have worked on them might be a good idea, though, for this and for other purposes. --Thomas Tuttle On Fri, 18 Jan 2008 10:46:14 -0500, Mikus Grinbergs [EMAIL PROTECTED] said: When I showed my G1G1 to a teacher friend, just about his first thought was: this is an opportunity for surreptitious assistance. Suppose Tommy needs to do something for school, but is stumped. He contacts Johnny on the mesh, who (for a suitable future pay-off) feeds Tommy the answer. How is the teacher to know that Tommy did not do the task himself ? mikus ___ 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
