Re: [sugar] SMS messaging
Allow me to rephrase in simpler terms: When someone is sending an SMS to a particular laptop in a school, how do they address it ? Currently, the only ID which is unique school-wise is the hash of the UUID used by the presence service. Nicknames are not unique across a school. wad On Jul 22, 2008, at 9:29 AM, Guillaume Desmottes wrote: Le mardi 22 juillet 2008 à 09:11 -0300, John Watlington a écrit : As I mentioned earlier to Ankur in a separate email, I believe the real problem here isn't technically how to connect to the presence service, but rather that the presence service offers no human-usable ID which is guaranteed to be unique within a school. This application won't run on the XO so it doesn't have to use presence-service at all. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Record-55 issue was B4 hardware failure (Was: Design Question)
Take a look at: http://wiki.laptop.org/go/ XO_Troubleshooting_AV#Errors_communicating_with_the_camera The majority of these problems are due to a latch on the flex cable connector coming loose. If you disassemble the laptop, and find that it was due to another source, pleased either add it to the guide or let me know. Cheers, wad On Jul 20, 2008, at 5:40 PM, Gary C Martin wrote: On 20 Jul 2008, at 13:40, Bobby Powers wrote: On Sat, Jul 19, 2008 at 7:19 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Works quite well here in a MP with last joyride. Just did some light testing, though. I've also tested it (lightly) on 3 machines running Joyride ~2170. Tomeu On Sat, Jul 19, 2008 at 1:06 PM, Walter Bender [EMAIL PROTECTED] wrote: Not good news. I don't recall that anything should have changed between B4 and the C series that would have impacted Record. I'll have to check it out on more machines... -walter On Sat, Jul 19, 2008 at 1:14 AM, Gary C Martin [EMAIL PROTECTED] wrote: On 19 Jul 2008, at 00:18, Walter Bender wrote: (Now that we have a reasonably stable joyride-with a working Record activity again-I'll try to get a quick user study pulled together in Peru on this topic by someone less bias than myself.) Hmmm, not convinced Record-55 is working well enough yet (Joyride-2174), unless it's just failing on my B4 hardware. I get everything from a black feed, to a green/purple stripy feed. Not managed to actually record anything with it yet. Doesn't seem to help launching Record first after a reboot and with no other activities (think that was one of the open bugs). just did that (boot then launch record) and it worked alright for me (on a MP machine). bobby Thanks for all the feedback. OK, after a lot of testing and looking through logs I finally accidently stumbled on the problem. It seems to be a HW fault on my B4. Perhaps a dry solder joint, cracked pcb or camera component not seated correctly. If I squeeze the right side of the screen, just below the camera lense, Record-55 starts displaying the video image, sometimes blank, sometimes green/purple, sometimes back to normal. Managed to successfully recorded a video clip while the image was good. I'm reasonably handy with a soldering iron so I'll open up the unit and see if I can see the specific cause. Is there a specific place I should report this HW issue incase it is more than single an unlucky occurrence? --Gary ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] sugar-control-panel
What are the acceptable arguments to sugar-control-panel when changing colors ? Does this list change when the language of the user interface changes ? I am specifically looking for the list of colors for Spanish laptops. Thanks, wad ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Firmware change (Re: Microsoft)
On May 15, 2008, at 10:39 PM, Korakurider wrote: On 5/16/08, Nicholas Negroponte [EMAIL PROTECTED] wrote: Open Firmware V2, the free and open source BIOS, is now capable of running Linux, Microsoft Windows XP and other operating systems, and was developed by Firmworks with support from OLPC. This will enable dual boot of OLPC XO laptops with Microsoft Windows XP in addition to the existing Fedora-based system and will become the standard BIOS/bootloader for all XO systems when completed. With this free BIOS, the XO-1 continues to be the most open laptop hardware currently available. I am not firmware-savvy but: what prevent windows from booting with V1 Firmware and how do they resolved it? (that is Ivan mentioned in his blog article?) Unlike Linux, Windows requires a BIOS to perform certain operations for it (ACPI, for example). OFW v1 didn't support those operations. What I would like to understand is security risk the change will give users of our linux stack. Don't we really need to be worry about that? We want to run on top of OFW v2 (or v1) because it supports our security model, whereas a plain BIOS doesn't. wad ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 65-node simple mesh test (and counting... ;-)
On May 12, 2008, at 3:31 PM, Ricardo Carrano wrote: How does the collision model/scheme change between AP mode and ad-hoc/mesh modes? As far as I can tell, it doesn't. 802.11s is interoperable with 802.11abg, which means that the same media access algorithms are used. At least part of our problem might be in the synchronized transmits occurring in our present 802.11s implementation of broadcast, which are probably killing whatever CA scheme 802.11abg dictate. See: http://wiki.laptop.org/go/ Path_Discovery_Mechanism:Sanity#Question_.232_- _Does_PDM_traffic_self-interfere.3F which is trying to deal with low-level path discovery requests, which also use the broadcast mechanism. --scott Yes, it is the same 802.11 DCF for both scenarios (infra and mesh). I would like to add to this discussion that sparse and dense mesh are too completely different animals. Most of the problems that we are trying to address now, are associated to the latter. Certainly an interesting question. But is your answer really true ? I'd argue that very little, if any, testing has been done of the large, yet sparse mesh. Certainly none by OLPC. Our problems certainly come from large meshes (more than 10-15 laptops in the mesh). What is your definition of sparse ? The more we dig into this, the more clear it gets that we need to adapt. Everything we do to increase coverage in a sparse mesh hurt us in a dense cloud. One example: broadcasting or multicasting at 1 or 2Mbps. Likewise, what we do to increase reliability, might actually decrease it. One example: the verbosity or redundancy of some of our protocols. And that's one of the strengths of Cerebro (less is more). So, as a side note: Treating the two animals as different will avoid some bites and scratches. ;-) One interesting note is that the suggested routing algorithm for 802.11s is a combination of reactive and proactive routing (unlike our current one, which is solely reactive). Perhaps that provides the adaptation necessary for the mesh to work ? wad ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Ad-hoc Networking
On Apr 23, 2008, at 5:26 PM, Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Gilmore wrote: | The presence implementation only works on access points and on meshes -- | but not on non-meshed, ad-hoc 802.11. The vast majority of computers | with 802.11 don't have mesh, but they would benefit from being able to | see nearby laptops and share applications with them (whether or not | a local access point, or global Internet access, is working). For full | integration, this probably requires some driver work, but most of the work | is probably at a daemon and library level. There is explicitly support for this idea in 802.11s. It is called a Mesh Access Point, or MAP, and it is the inverse of a Mesh Portal (MPP). A Mesh Portal is a 802.11s device (e.g. an XO) that is acting as a client to 802.11b/g Access Point and is then sharing that connection (perhaps an internet connection) into the 802.11s mesh. A Mesh Access Point is connected to an 802.11s network, and also acts as an 802.11b Access Point whose clients can essentially join the mesh. With both of these things it is possible to have: Satellite internet -- Standard 802.11b access point -- XO acting as MPP -- XO -- XO -- XO acting as MAP -- Standard 802.11b laptop and thus provide a relatively distant internet connection to a standard laptop, which also sees all the XOs on its local network. MPP support is in place, but it does not play well with the School Server (and possibly DHCP), so it has been disabled. MAP support has not been a high priority, and I do not know anything about its current status. The laptop as an MPP is an interesting idea, but the problem is the havoc it can wreck when a number of XOs are together in a school. Satellite Internet - XS - 802.11b AP - XO can support around 50 laptops per channel. But all it takes is one kid running in MPP mode near the AP to eat up the spectrum with mesh routing packets. This is why it no longer enters MPP mode by default when connected to an AP. I would certainly love if the XOs and Active Antennas could be made to run in MPP and MAP mode. I do not know to what degree the Marvell device is capable of this The hardware is capable of being both. We are working with Cozybit to get soft AP code for the hardware that will support both. wad ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
