Re: mechanisms tied to mesh: under a tree collab
On Wed, Sep 17, 2008 at 20:33, John Watlington [EMAIL PROTECTED] wrote: I had already filed #8354 on the default presence server, and #8353 included misnaming that field in the control panel. As #8353 was marked a duplicate of another ticket which didn't include the misnaming, I fear a new ticket will have to be issued... Thankfully Eben already volunteered. Renaming mesh server to collaboration server is #8623. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
Hi, i need to point out that ethernet dongles don't seem to play at all well with suspend/resume, so the scenarios that you describe may have worked well in the past, and may work well on first boot, or first device insertion, but will stop working immediately if you close/open your lid, or otherwise suspend. :-/ Yeah, the USB bus is entirely unpowered during suspend. If there's a software bug or regression here (rather than a failure of physics), we should file it. - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
chris wrote: Hi, i need to point out that ethernet dongles don't seem to play at all well with suspend/resume, so the scenarios that you describe may have worked well in the past, and may work well on first boot, or first device insertion, but will stop working immediately if you close/open your lid, or otherwise suspend. :-/ Yeah, the USB bus is entirely unpowered during suspend. If there's a software bug or regression here (rather than a failure of physics), we should file it. old bug. #5990 paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
Hi Stephen, quote who=Stephen Thorne This means two laptops from neighbouring schools who each have their 'own' schoolserver set up as their jabber server will not be able to share any content if they are close enough to receive wireless signal to the internet. Unless they join each others school server for collaboration activities :) that is how I'm planning on linkin gup a few schools here who are hundreds of kilometers apart, but having the teachers know how to connect to the other schoolserver for short activities, and then back to the local server. Cheers, Pia -- OLPC Australia http://olpc.org.au/ Linux Australia http://linux.org.au/ Open Source Industry Australia http://osia.net.au/ Software Freedom Day http://softwarefreedomday.org/ If you have any trouble sounding condescending, find a Unix user to show you how it's done. - Scott Adams ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
Am 17.09.2008 um 07:26 schrieb John Gilmore: The decision to tie application sharing to Mesh and Sugar was a bad design idea, one which I've been intending to explore fixing. As Benjamin pointed out, the sharing is *not* tied to the mesh. It works just as well if both machines can receive broadcasts (for discovery) and make TCP connections (for actual collaboration). This works in a LAN or between two Qemu instances or even on the same machine running sugar-jhbuild twice (useful for debugging). My naive understanding was that zeroconf works, so you can run TCP/IP, but something about our non-mesh sharing protocol requires a server somewhere. Otherwise what's that setting in Network in the Control Panel: Mesh Server: olpc.collabora.co.um? Don't we switch between two different wire protocols (theoretically seamlessly), one of which requires a server? Yes we do. I think that's just bad UI design - as far as I know the school server is independent of the mesh, so it should not be labeled mesh. The problem comes from the OLPC marketing that equates mesh with collaboration which in fact are two independent concepts. What the UI displays as Mesh Server should be Collaboration Server - it's only needed to mediate if the laptops who want to collaborate cannot talk to each other directly. (and btw. you should *not* use olpc.collabora.co.uk anymore which has been switched to a new protocol so you won't see anyone while connected to that server) - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
The problem comes from the OLPC marketing that equates mesh with collaboration which in fact are two independent concepts. What the UI displays as Mesh Server should be Collaboration Server - it's only needed to mediate if the laptops who want to collaborate cannot talk to each other directly. (and btw. you should *not* use olpc.collabora.co.uk anymore which has been switched to a new protocol so you won't see anyone while connected to that server) Sounds like two TRAC bugs -- the name, and the domain name. Both are straight out of 8.2-759. Will you file them? As Benjamin pointed out, the sharing is *not* tied to the mesh. It works just as well if both machines can receive broadcasts (for discovery) and make TCP connections (for actual collaboration). This works in a LAN or between two Qemu instances or even on the same machine running sugar-jhbuild twice (useful for debugging). Then why can't my two XO's running 8.2-759, both connected to the same access point, see each other to collaborate? Neither one shows up in the other's Network screen. When I run Write on one, and enable sharing with My Neighborhood, that copy of Write pops up on its own Neighborhood screen, but never on the Neighborhood screen (nor in the Frame) of its neighboring XO. Is this a third TRAC bug? (I can never tell whether I really know how to run the GUI for collaboration, since most of the time it fails, and I don't know if it's my fault for not following the instructions (do we have some of those now?), or the fault of bugs in the implementation.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
Am 17.09.2008 um 11:28 schrieb John Gilmore: The problem comes from the OLPC marketing that equates mesh with collaboration which in fact are two independent concepts. What the UI displays as Mesh Server should be Collaboration Server - it's only needed to mediate if the laptops who want to collaborate cannot talk to each other directly. (and btw. you should *not* use olpc.collabora.co.uk anymore which has been switched to a new protocol so you won't see anyone while connected to that server) Sounds like two TRAC bugs -- the name, and the domain name. The server name comes from a previous installation (I think). Both are straight out of 8.2-759. Will you file them? You're welcome to do that :) As Benjamin pointed out, the sharing is *not* tied to the mesh. It works just as well if both machines can receive broadcasts (for discovery) and make TCP connections (for actual collaboration). This works in a LAN or between two Qemu instances or even on the same machine running sugar-jhbuild twice (useful for debugging). Then why can't my two XO's running 8.2-759, both connected to the same access point, see each other to collaborate? Because you might have olpc.collabora.co.uk as server? Just enter a non-existing one. (and no, I can't do anything about that, I just happened to run into the same problem and that was the suggested solution) - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
On Wed, Sep 17, 2008 at 5:05 AM, Bert Freudenberg [EMAIL PROTECTED] wrote: Yes we do. I think that's just bad UI design - as far as I know the school server is independent of the mesh, so it should not be labeled mesh. +1 I'll open a ticket on this now so it's not lost. Collaboration server seems to be the best phrasing to me as well. - Eben The problem comes from the OLPC marketing that equates mesh with collaboration which in fact are two independent concepts. What the UI displays as Mesh Server should be Collaboration Server - it's only needed to mediate if the laptops who want to collaborate cannot talk to each other directly. (and btw. you should *not* use olpc.collabora.co.uk anymore which has been switched to a new protocol so you won't see anyone while connected to that server) - Bert - ___ 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: mechanisms tied to mesh: under a tree collab
Hi All, Very interesting thread on the wireless, mesh and collaboration technologies. I think part of the discussion is a debate about what is the best technology to achieve our goals. In terms of what the goals are, I wrote a definition of what I think our collaboration needs to do at: http://wiki.laptop.org/go/9.1.0_Collaboration_Requirements The requirements are focused mostly on scale but also touching on ways people collaborate. See also: http://wiki.laptop.org/go/9.1.0#Collaboration_2 and http://wiki.laptop.org/go/9.1.0#Collaboration This will be an important focus of 9.1. Any additions, comments or edits on the requirements are welcome. e.g. RF environment could use more details and power consumption is not covered. John's bulleted list may also be a valuable addition to the requirements if its not covered already. Feel free to edit the page and sign your edits or leave a suggestion on the talk page. My questions for this thread are: 1 - Which technology can address all of these requirements? 2 - Which technology can get us closest in the next few months based on the available engineering time and existing code? I'm interested to know what people think is the right solution given unlimited time and resources. I'm more interested to get agreement on what we can nail down and promise as a working set of features usable in schools when 9.1 becomes available in ~6 months from now. We don't want to do a lot of work that we throw away later but we need to settle on a usable set of features and capabilities that we can prove work reliably. Thanks, Greg S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
On 17 Sep 2008, at 10:28, John Gilmore wrote: Then why can't my two XO's running 8.2-759, both connected to the same access point, see each other to collaborate? Neither one shows up in the other's Network screen. When I run Write on one, and enable sharing with My Neighborhood, that copy of Write pops up on its own Neighborhood screen, but never on the Neighborhood screen (nor in the Frame) of its neighboring XO. Is this a third TRAC bug? I have a feeling this is a bug/omission but don't have 2 XOs to test it and give a detailed trac report (please do if you have 2 XOs to test!). I notice that in 711 and back, I see my Mac (with z-conf/ Bonjour enabled) appears as a buddy on the Neighborhood view when the XO is set to an unreachable jabber server and both Mac and XO are connected to the same AP. This is NOT the case for the 8.2 release or joyride stream for weeks, perhaps a month or four. Rumour: I'm sure saw some low level tec references/chatter at some point about broken multicast, or broadcast, or some such shenanigans, perhaps related to network power suspend wake ups. Any one vaguely remember any of this, or am I generating false memories? --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
benjamin m. schwartz wrote: The wired-ethernet case is already working, and has been for a year or more. Drop Sugar onto two Thinkpads connected to the same subnet, and they will instantly find each other over Avahi, etc. If it's a wireless network, or if you have XOs with ethernet dongles, they'll also see any XO's that are also connected to that AP. (Actually, Sugar will also find any nearby Macs running Avahi, but doesn't quite know what to do with them.) i need to point out that ethernet dongles don't seem to play at all well with suspend/resume, so the scenarios that you describe may have worked well in the past, and may work well on first boot, or first device insertion, but will stop working immediately if you close/open your lid, or otherwise suspend. :-/ paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
Then why can't my two XO's running 8.2-759, both connected to the same access point, see each other to collaborate? Neither one shows up in the other's Network screen. When I run Write on one, and enable sharing with My Neighborhood, that copy of Write pops up on its own Neighborhood screen, but never on the Neighborhood screen (nor in the Frame) of its neighboring XO. My experience is different. I do not have wireless at home; at home the XO software doesn't connect to any jabber server. The wired LAN supplies the only access point for the two XOs attached to it. Each XO sees the other in Neighborhood View. I __am__ able (without any problem) to collaborate (e.g., in Write) between these two XOs. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
On Wed, Sep 17, 2008 at 18:52, Gary C Martin [EMAIL PROTECTED] wrote: On 17 Sep 2008, at 10:28, John Gilmore wrote: Then why can't my two XO's running 8.2-759, both connected to the same access point, see each other to collaborate? Neither one shows up in the other's Network screen. When I run Write on one, and enable sharing with My Neighborhood, that copy of Write pops up on its own Neighborhood screen, but never on the Neighborhood screen (nor in the Frame) of its neighboring XO. Is this a third TRAC bug? I have a feeling this is a bug/omission but don't have 2 XOs to test it and give a detailed trac report (please do if you have 2 XOs to test!). I notice that in 711 and back, I see my Mac (with z-conf/ Bonjour enabled) appears as a buddy on the Neighborhood view when the XO is set to an unreachable jabber server and both Mac and XO are connected to the same AP. This is NOT the case for the 8.2 release or joyride stream for weeks, perhaps a month or four. Rumour: I'm sure saw some low level tec references/chatter at some point about broken multicast, or broadcast, or some such shenanigans, perhaps related to network power suspend wake ups. Any one vaguely remember any of this, or am I generating false memories? This dropped out when we fixed something in Presence Service a while back. We had to stop showing buddies without a key (which means non-Sugar avahi/bonjour clients). #7581 tracks reenabling this for 9.1.0, and links to the original bug. Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
On Sep 17, 2008, at 5:28 AM, John Gilmore wrote: The problem comes from the OLPC marketing that equates mesh with collaboration which in fact are two independent concepts. What the UI displays as Mesh Server should be Collaboration Server - it's only needed to mediate if the laptops who want to collaborate cannot talk to each other directly. (and btw. you should *not* use olpc.collabora.co.uk anymore which has been switched to a new protocol so you won't see anyone while connected to that server) Sounds like two TRAC bugs -- the name, and the domain name. Both are straight out of 8.2-759. Will you file them? I had already filed #8354 on the default presence server, and #8353 included misnaming that field in the control panel. As #8353 was marked a duplicate of another ticket which didn't include the misnaming, I fear a new ticket will have to be issued... Thankfully Eben already volunteered. As Benjamin pointed out, the sharing is *not* tied to the mesh. It works just as well if both machines can receive broadcasts (for discovery) and make TCP connections (for actual collaboration). This works in a LAN or between two Qemu instances or even on the same machine running sugar-jhbuild twice (useful for debugging). Then why can't my two XO's running 8.2-759, both connected to the same access point, see each other to collaborate? Neither one shows up in the other's Network screen. When I run Write on one, and enable sharing with My Neighborhood, that copy of Write pops up on its own Neighborhood screen, but never on the Neighborhood screen (nor in the Frame) of its neighboring XO. Is this a third TRAC bug? No, that problem is #8354. If the access point has a connection to the internet, they were going to olpc.collabora.co.uk, which was running a broken presence service. If you manually edit /home/olpc/.sugar/default/config to remove the default presence (ejabber) service, you should start seeing local (simple WiFi) collaboration again. wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
John, dlo#8354 is believed to be fixed in 8.2-760. Can you confirm or deny this? Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
On Wed, Sep 17, 2008 at 1:26 AM, John Gilmore [EMAIL PROTECTED] wrote: Ricardo Carrano said: There are technical challenges in the way, but OLPC should keep pushing this for the benefits it will bring. It seems a perfect fit with the Mission. Mesh and the Marvell WiFi chip have been two of the big disappointments of the OLPC. The mesh implementation simply doesn't scale. We've had to require people to turn it off to just get basic TCP/IP to work in classrooms. We've stopped designing mesh wireless into school servers. Maybe it will work someday -- in fact I'm sure it will work *better* someday. And the Marvell chip, as delivered, burned something like twice the power it was spec'd to burn, reducing the laptop's suspend time so it does not even survive one night, even when not actively forwarding packets. Its promised open source firmware ended up proprietary and endlessly buggy. Its USB interface was almost incompatible with the laptop's power management implementation, which is forced to turn off the USB bus, and still requires great amounts of dancing on the head of a pin for CPU power-off suspends to work at all (they were designed to resume invisibly in 0.1 seconds, but cannot resume in less than 1.0 seconds). The mesh protocol implemented is still only compatible with itself and no other vendor; it's not a standard. In short, among the promised miracles of the OLPC project, the mesh was a failure. We got a great screen, we got a low power fanless flash-based laptop, we got cute and kidproof packaging, we got a low price (almost), we got a promise of long battery life (someday), but we didn't get automatic wireless networking that works all day in the school and extends throughout the village all night without infrastructure. I don't mean to rub it in, Ricardo, but it's a fact that anyone can see if they merely open their eyes. To keep pushing on something that did not deliver the goods for three years is not always the best option. If a small amount of software work would give OLPC the option to drop mesh support in future products, I think OLPC should *definitely* do that small amount of work. Which is not to say they should drop the mesh -- just that they should keep their options open. Martin Langhoff said (quoting me): Another mechanism that only works on Mesh is sharing under a tree. Ah, this is a bit of a misunderstanding :-) Well, whether or not you asked the question (What would we have to change to delete Mesh from our product, since we aren't using it much?), you inspired me to try to answer it. So far it looks like only lease activation, sharing under trees, and long-distance but thinly populated villages require mesh. I filed bugs #8524 and #8525 for two possible enhancements (make leases and tree-sharing work without mesh). The decision to tie application sharing to Mesh and Sugar was a bad design idea, one which I've been intending to explore fixing. It should work over any working network, which includes 802.11 adhoc without access points, and in any GUI. Breaking those ties would allow anybody who runs AbiWord to do OLPC-like sharing. And once that's working on ordinary network hardware, in ordinary Linux distros, for the 99.99% of Linux users who don't run Sugar, then lots of other shareable apps would quickly follow. The Linux programmer community that works on Sugar activities is less than 1% of the total Linux application programmer community. By telling them this shared collaboration stuff only works if you blow away your user interface and replace it with this extremely clunky one -- and set up a custom school server in your house or office, they think, I'll add shared collab to *my* software when they have put a bit of polish on this 'feature'. My understanding is that it works automagically between XOs on the same AP -- but may have limitations and possibly bugs as it's not something we push (and it's not something we test much formally ... My naive understanding was that zeroconf works, so you can run TCP/IP, but something about our non-mesh sharing protocol requires a server somewhere. Otherwise what's that setting in Network in the Control Panel: Mesh Server: olpc.collabora.co.um? Don't we switch between two different wire protocols (theoretically seamlessly), one of which requires a server? Yep: http://wiki.laptop.org/go/Collaboration_Tutorial says we use gabble to talk to a server, and salut for link-local serverless sharing. btw, the assumption you make that laptops just can see eachother via RF is not quite right when it comes to 802.11a/b/g. It's a misconception I had too until I sat down and read the o'reilly 802.11 book (Thick But Worthwhile). Yep, many radio protocols use repeaters for many good reasons, including hidden nodes and other channel allocation problems. But the ability to talk node-to-node -- without
Re: mechanisms tied to mesh: under a tree collab
[I posted bug #8524 re lease activation not working on AP's.] Another mechanism that only works on Mesh is sharing under a tree. It's perfectly feasible for four or five kids with laptops, all sitting under a tree, to share over ad-hoc 802.11 mode. They don't need a mesh that forwards packets; they can all hear each other on the radio just fine. Mac laptops do this, for example, using the standard Zeroconf protocols to assign IP addresses to themselves, and find each other by name with mdns. OLPC's collaboration infrastructure doesn't support this -- or if some underlying layer does, there's no UI for it. There's no way for the user to tell the laptop, Talk to other nearby laptops -- without the mesh, without an access point. Future hardware might well want to discard the complicated and power-hungry mesh option, since we really aren't using it anyway, except for lease activation and this under a tree scenario. That would give us lots more choices on future WiFi hardware. If we fix collab to work in ad-hoc mode under a tree, and when two or more machines are plugged-together via Ethernet without a server, then not only will our future products have that choice, but also, our collab stuff will be MUCH easier to drop into ordinary Linux distros and applications. It seems to me that this would achieve a big piece of OLPC's original software goals -- to spawn a revolution in free software applications that support and encourage online collaboration. (Divorcing the collab support from the OLPC-unique Sugar GUI is also a prerequisite for making that happen.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Gilmore wrote: | [I posted bug #8524 re lease activation not working on AP's.] | | Another mechanism that only works on Mesh is sharing under a tree. | | It's perfectly feasible for four or five kids with laptops, all | sitting under a tree, to share over ad-hoc 802.11 mode. They don't | need a mesh that forwards packets; they can all hear each other on the | radio just fine. I'm not quite so certain. I wouldn't venture to predict how TCP behaves over a pure ad-hoc 802.11b network in the face of congestion, signal nulls, etc. I think an experiment is in order... | OLPC's collaboration infrastructure doesn't support this -- or if some | underlying layer does, there's no UI for it. There's no way for the | user to tell the laptop, Talk to other nearby laptops -- without the | mesh, without an access point. I think there is, somewhere in the command line, a way to set TTL=0 or similar, but that's certainly far from a nice GUI toggle. | Future hardware might well want to discard the complicated and | power-hungry mesh option, since we really aren't using it anyway, | except for lease activation and this under a tree scenario. That | would give us lots more choices on future WiFi hardware. It's a little more complex than that. My sense is that many OLPC developers would ideally like a relatively thin, generic 802.11 chip and a relatively generic, low-power processor to go with it, so that the main CPU can shut down, and critical network services can run on the coprocessor. The best architecture I can imagine is to run the Cerebro mesh routing and presence algorithms on that coprocessor. Cerebro's performance in tests on XO's has been amazing to me, so far. | If we fix | collab to work in ad-hoc mode under a tree, and when two or more | machines are plugged-together via Ethernet without a server, The wired-ethernet case is already working, and has been for a year or more. Drop Sugar onto two Thinkpads connected to the same subnet, and they will instantly find each other over Avahi, etc. If it's a wireless network, or if you have XOs with ethernet dongles, they'll also see any XO's that are also connected to that AP. (Actually, Sugar will also find any nearby Macs running Avahi, but doesn't quite know what to do with them.) | then not | only will our future products have that choice, but also, our collab | stuff will be MUCH easier to drop into ordinary Linux distros and | applications. Our collab stuff is essentially Telepathy, which is a freedesktop.org project that originated separately from OLPC. The Telepathy gtk chat client Empathy may soon be Gnome's default IM client. Sugar is already available as a package for Fedora, Debian, and Ubuntu, with working collab out of the box over the internet, ethernet, or wireless AP. I don't know what happens if you configure Network Manager for ad-hoc mode before launching Sugar. Also, open80211s is now in the mainline linux kernel (as of 2.6.26). This is a pure-software implementation that will work on a wide variety of existing hardware, and should interoperate cleanly with the XO mesh. In short, I'm not convinced that the mesh network approach is a real liability for Sugar on non-XO hardware. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjQZnoACgkQUJT6e6HFtqTcRgCgmn+gKH41hb975ONAFI32VHHL lkUAoIid7WgmyrGW3FriIUY2mDRvKbt5 =ulyx -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
John, On Tue, Sep 16, 2008 at 9:46 PM, John Gilmore [EMAIL PROTECTED] wrote: [I posted bug #8524 re lease activation not working on AP's.] Another mechanism that only works on Mesh is sharing under a tree. It's perfectly feasible for four or five kids with laptops, all sitting under a tree, to share over ad-hoc 802.11 mode. They don't need a mesh that forwards packets; they can all hear each other on the radio just fine. Mac laptops do this, for example, using the standard Zeroconf protocols to assign IP addresses to themselves, and find each other by name with mdns. OLPC's collaboration infrastructure doesn't support this -- or if some underlying layer does, there's no UI for it. There's no way for the user to tell the laptop, Talk to other nearby laptops -- without the mesh, without an access point. Future hardware might well want to discard the complicated and power-hungry mesh option, since we really aren't using it anyway, except for lease activation and this under a tree scenario. That would give us lots more choices on future WiFi hardware. If we fix collab to work in ad-hoc mode under a tree, and when two or more machines are plugged-together via Ethernet without a server, then not only will our future products have that choice, but also, our collab stuff will be MUCH easier to drop into ordinary Linux distros and applications. It seems to me that this would achieve a big piece of OLPC's original software goals -- to spawn a revolution in free software applications that support and encourage online collaboration. (Divorcing the collab support from the OLPC-unique Sugar GUI is also a prerequisite for making that happen.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel It's true that multi hoping comes with extra complexity. But it is also true that you can achieve much more with multi hoping than with a 802.11 IBSS. If we really want to encourage freedom and empower people, a multihop wirless network is the only foreseeable communication technology that frees people from the dependency of infra-structure (meaning entities that run that infra and associated costs) and is usable not only under a tree, but in a larger context and coverage area. There are technical challenges in the way, but OLPC should keep pushing this for the benefits it will bring. It seems a perfect fit with the Mission. Also, please note that the scenario you describe: 5 kids under the tree, works for some time now with XOs. Cheers! Ricardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
(Actually, Sugar will also find any nearby Macs running Avahi, but doesn't quite know what to do with them.) Chat between Bonjour clients works today. So the XOs know some things to do with a MAC. -walter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
On Wed, Sep 17, 2008 at 11:28 AM, Martin Langhoff [EMAIL PROTECTED] wrote: - under a tree using mesh+avahi, and - G1G1 users at a cafe with wifi using AP and avahi When at a cafe with wifi, the laptops should be able to contact their jabber server, which will mean they will be using telepathy-gabble (xmpp + central server), not telepathy-salut (xmpp + avahi). These two ways of seeing other laptops do not coexist. This essentially means that as soon as your laptop is talking to the jabber server, you are 'on the internet' and all peer-to-peer collaboration disappears, you are only able to see those on your jabber server. There is currently no UI for forcing 'salut' vs. 'gabble', the only way to modeswitch is to be unable to contact the jabber server. This means two laptops from neighbouring schools who each have their 'own' schoolserver set up as their jabber server will not be able to share any content if they are close enough to receive wireless signal to the internet. -- Stephen Thorne Give me enough bandwidth and a place to sit and I will move the world. --Jonathan Lange ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
On Wed, Sep 17, 2008 at 03:07:35PM +1000, Stephen Thorne wrote: This means two laptops from neighbouring schools who each have their 'own' schoolserver set up as their jabber server will not be able to share any content if they are close enough to receive wireless signal to the internet. Three kids under a tree. Sharing fine. One climbs the tree. Sharing stops. They'll soon learn to stop climbing trees. Is this really what we want? Tree climbing is a very useful skill. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mechanisms tied to mesh: under a tree collab
Ricardo Carrano said: There are technical challenges in the way, but OLPC should keep pushing this for the benefits it will bring. It seems a perfect fit with the Mission. Mesh and the Marvell WiFi chip have been two of the big disappointments of the OLPC. The mesh implementation simply doesn't scale. We've had to require people to turn it off to just get basic TCP/IP to work in classrooms. We've stopped designing mesh wireless into school servers. Maybe it will work someday -- in fact I'm sure it will work *better* someday. And the Marvell chip, as delivered, burned something like twice the power it was spec'd to burn, reducing the laptop's suspend time so it does not even survive one night, even when not actively forwarding packets. Its promised open source firmware ended up proprietary and endlessly buggy. Its USB interface was almost incompatible with the laptop's power management implementation, which is forced to turn off the USB bus, and still requires great amounts of dancing on the head of a pin for CPU power-off suspends to work at all (they were designed to resume invisibly in 0.1 seconds, but cannot resume in less than 1.0 seconds). The mesh protocol implemented is still only compatible with itself and no other vendor; it's not a standard. In short, among the promised miracles of the OLPC project, the mesh was a failure. We got a great screen, we got a low power fanless flash-based laptop, we got cute and kidproof packaging, we got a low price (almost), we got a promise of long battery life (someday), but we didn't get automatic wireless networking that works all day in the school and extends throughout the village all night without infrastructure. I don't mean to rub it in, Ricardo, but it's a fact that anyone can see if they merely open their eyes. To keep pushing on something that did not deliver the goods for three years is not always the best option. If a small amount of software work would give OLPC the option to drop mesh support in future products, I think OLPC should *definitely* do that small amount of work. Which is not to say they should drop the mesh -- just that they should keep their options open. Martin Langhoff said (quoting me): Another mechanism that only works on Mesh is sharing under a tree. Ah, this is a bit of a misunderstanding :-) Well, whether or not you asked the question (What would we have to change to delete Mesh from our product, since we aren't using it much?), you inspired me to try to answer it. So far it looks like only lease activation, sharing under trees, and long-distance but thinly populated villages require mesh. I filed bugs #8524 and #8525 for two possible enhancements (make leases and tree-sharing work without mesh). The decision to tie application sharing to Mesh and Sugar was a bad design idea, one which I've been intending to explore fixing. It should work over any working network, which includes 802.11 adhoc without access points, and in any GUI. Breaking those ties would allow anybody who runs AbiWord to do OLPC-like sharing. And once that's working on ordinary network hardware, in ordinary Linux distros, for the 99.99% of Linux users who don't run Sugar, then lots of other shareable apps would quickly follow. The Linux programmer community that works on Sugar activities is less than 1% of the total Linux application programmer community. By telling them this shared collaboration stuff only works if you blow away your user interface and replace it with this extremely clunky one -- and set up a custom school server in your house or office, they think, I'll add shared collab to *my* software when they have put a bit of polish on this 'feature'. My understanding is that it works automagically between XOs on the same AP -- but may have limitations and possibly bugs as it's not something we push (and it's not something we test much formally ... My naive understanding was that zeroconf works, so you can run TCP/IP, but something about our non-mesh sharing protocol requires a server somewhere. Otherwise what's that setting in Network in the Control Panel: Mesh Server: olpc.collabora.co.um? Don't we switch between two different wire protocols (theoretically seamlessly), one of which requires a server? Yep: http://wiki.laptop.org/go/Collaboration_Tutorial says we use gabble to talk to a server, and salut for link-local serverless sharing. btw, the assumption you make that laptops just can see eachother via RF is not quite right when it comes to 802.11a/b/g. It's a misconception I had too until I sat down and read the o'reilly 802.11 book (Thick But Worthwhile). Yep, many radio protocols use repeaters for many good reasons, including hidden nodes and other channel allocation problems. But the ability to talk node-to-node -- without repeaters -- is a key feature of many radio protocols. Both capabilities are built into 802.11. Note that when five kids are sitting under
Re: mechanisms tied to mesh: under a tree collab
On Wed, Sep 17, 2008 at 5:26 PM, John Gilmore [EMAIL PROTECTED] wrote: My understanding is that it works automagically between XOs on the same AP -- but may have limitations and possibly bugs as it's not something we push (and it's not something we test much formally ... My naive understanding was that zeroconf works, so you can run TCP/IP, but something about our non-mesh sharing protocol requires a server somewhere. I think you are right there. I've been reading up on a bit of the avahi infra, and thought for a moment it was all avahi-based. I think it actually was at a time, many moons ago. Note that when five kids are sitting under a tree using 802.11s Mesh, their radios are talking directly node-to-node. Definitely. That's why I pointed out a/b/g. 's' definitely is node-to-node. For a/b/g to work in ad-hoc mode with more than 2 nodes you need something like Cerebro. You say you don't like it; I say it works quite well, but if you have something better (different sw or patches to Cerebro) we'll want to see it. It's hip to complain about the low-level collaboration layers these days. But it doesn't help much. What we need are a thousand litle steps towards something better. Poly has been very active in supporting Cerebro, he's probably interested in hearing about patches and/or well defined bugs you may have. Now, to bring this thread back to course... old-timers and people that work in areas of the XO software I rarely travel, do you know about any XO/XS or XO/Internet interaction that depends on an active antenna / 802.11s ? cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- 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
