VGA external on OLPC
Hi all, after reading http://www.whyxo.com/2008/01/08/external-monitor-or-projector-for-the-xo/ I am sure, that it is possible to integrate a VGA external connector for the OLPC. On the Prototype-A motherboard layout there was such an external VGA connector, but on G1G1 version it is gone. I am a teacher and it would be very good for projection with a beamer or if your LCD is broken, to have such an external VGA connector. My problem is, that I have no schematic or a good photo of both sides of the Prototype-A motherboard. You can read in the Geode LX databook, that the Geode LX chip offers direct VGA support and connection. But some parts of the Prototype-A motherboard have gone in G1G1 version and so I cannot see, which direct lines from the processor has to be used for the direct VGA support. Pin 1,2,3 are used for the RGB signal on the G1G1 layout, and pin 13 seems to be Hsync and pin 14 Vsync. I do not know, what is the use of pin 4,9,12,15, because they are also wired on the G1G1 version. Pin 5, 6,7,8,10,11 are not connected on the G1G1 version and I think, that this was the same for the Prototype-A motherboard layout. But still there must be the lines direct to the Geode processor from the Prototype-A layout. They only have to be found (recogniced) via a good photo of the Prototype-A layout (both sides). Please send me your photos and rtell me, what you think about my idea, Dietmar PS: RGB lines of VGA ends on G1G1 layout direct in front of C51, C41, C86. If this is true, only Vsync and Hsync have to be found. Wikipedia says about the pins for VGA: Pin 1 RED Red video Pin 2 GREEN Green video Pin 3 BLUE Blue video Pin 4 N/C Not connected Pin 5 GND Ground (HSync) Pin 6 RED_RTN Red return Pin 7 GREEN_RTN Green return Pin 8 BLUE_RTN Blue return Pin 9 +5 V +5 V (DDC) Pin 10 GND Ground (VSync, DDC) Pin 11 N/C Not connected Pin 12 SDA I²C data Pin 13 HSync Horizontal sync Pin 14 VSync Vertical sync Pin 15 SCL I²C clock ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: very simple datastore reimplementation
On Sat, May 10, 2008 at 2:15 AM, Jim Gettys [EMAIL PROTECTED] wrote: FUSE is great, but... It means interoperability must be an explicit planned-in-advance action: Exactly. That's also my beef with the FUSE approach. The things we can do via FUSE we can do in the regular FS. So let's avoid FUSE, and use a *simple* convention on how to store things in the FS. Something roughly along the lines of: - Make a directory per document, name it user-picked-name-10-char-hash - Inside that directory, metadata.txt has simple metadata in a nice, human-readable format. - If there are versions for this file, perhaps they are in a .git directory, or similar (.svn anyone? ;-) ) - Otherwise, the files in the directory are whatever the activity or application considers to be the document - We use this same format on external media and on local media - Jornal can maintain a hidden documents metadata database at the root of each FS. This is merely a cached index to have faster mount times (avoiding a rebuild of said index if we can deem it safe). - We need a reasonable failsafe behaviour if we find that metadata.txt is b0rken and unreadable. and that's it. It's a trivial thing, will work on any fs, on any OS, no magic tricks needed. We can do fast searches on based on the documents metadata, and the only slow op is mounting a device where the documents metadata is stale or missing. IMO, jg is hinting towards something like this. If something like this is done in a way that it uses atomic ops most of the time (using an idiom of write to tmpfile, close and then mv instead of write-in-place) then we have something pretty much bulletproof, failsafe, and fast. Or at least as fast as the kernel-level FS implementation is. And it's bound to be a small simple thing too :-) 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
Re: very simple datastore reimplementation
and that's it. It's a trivial thing, will work on any fs, on any OS, no magic tricks needed. We can do fast searches on based on the documents metadata, and the only slow op is mounting a device where the documents metadata is stale or missing. I like along this line, too. In fact, Journal can be mostly a smarter version of recent documents feature. That can hide the hierarachical file system, and present documents in the time-based view. On a file system that doesn't support the owner/group permission, an activity could mess up the other activities data; but the user can do it from the command line even for the internal file system more or less. I would imagine that separated metadata can be optional. For Text-type documents (including Etoys), we can as well just make the tags in the document itself. For a picture, it can be EXIF and can have comments, etc. Any file can have comments, and since we are operating some limited kind of files anyway, the Journal can support them one by one. On a related note: tagging the document at a separate place wouldn't work well (http://dev.laptop.org/ticket/6128). This is another reason to make the tags just appear inside documents. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Arcade game
Hi Evgeny, 2008/5/12 Jeck Landin [EMAIL PROTECTED]: Hello, All. I would llike to develop 2D arcade/shooter multiplayer game. Planned to create multiple game modes, such as well-known Deathmatch, Capture the flag, Domination, etc. But without violence and in child-oriented setting. For example, different funny animals would jump across 2D map and fire each other with bananas, coconuts and other fruits. The game will support the connection and disconnection of players during the round, using mesh-networking technology. Perhaps I will add bots. Then I will work on the development of graphic elements and special effects. Design of the game, I wish to make in the children's style - bright colors, distinct pieces .I have some experience in the creation of images and animations of this type. Looking forward to your reply. I suggest you to check existing games in order to get ideas for both the game and its implementation. http://wiki.laptop.org/go/Activities#Fun_Games Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Need help with making flash partitions
Hi, I am trying to create an UBIFS image for OLPC and ask the community to evaluate it. But I have some troubles I need help to deal with. The basic approach I am going to use is to create 2 flash partitions - boot and root. Boot would contain /boot and have JFFS2. OF would boot the kernel from this partition. Boot would be small, just few Megs. Root partition would be large and contain everything else and would be UBIFS. Mitch kindly referred me to this web page which tells how to create 2 partitions: http://wiki.laptop.org/go/OFW_NAND_FLASH_Updater My aim is to make UBIFS installation easy - people would just copy some files to their FAT-formatted USB sticks and reboot. Just like you update your laptops with JFFS2 images. But I have troubles with security. Namely, if I change data.img, OF complains about invalid signature. I tried to remove data.sig file - it does not help. I tried to put my developer key to the USB stick - does not help as well. I use B4 prototype and security is disabled AFAIU. Any suggestion? Thanks. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Sugar in LinuxTag 2008
Hi all, some (most) members of the Sugar team is discussing having a meeting at LinuxTag in Berlin from 29th May - 1st June. For now, looks like Simon Schampijer, Jim Gettys, Marco, Bert, Bernie, Holger Levsen (from OLPC Deutschland) and me will be there. Holger will give a couple of talks about OLPC, Sugar and eToys. We'll be sharing impressions and discussing organizational and technical matters, and would be a pleasure if other members of the OLPC and Sugar communities would join us. Hope to see some of you soon, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Fri, 2008-05-09 at 21:00 -0700, [EMAIL PROTECTED] wrote: Each device maintains its own list of bound multicast addresses. Those lists are merged and purged from duplicate addresses before being sent to firmware. The maximum number of multicast addresses per virtual device has been cut in half to ensure that the merged list can be accommodated by the hardware. Also, configuration flags are ORed before being sent to firmware, which appears to be the least conflicting way of combining two virtual operating modes into one for a single physical device. Based on patches from Ashish Shukla and David Woodhouse. Signed-off-by: Javier Cardona [EMAIL PROTECTED] Tested by: Ricardo Carrano [EMAIL PROTECTED] Looks good, but please don't introduce any more of the 'u8' and 'u32' nonsense. If types are user-visible, we have to use the '__u32' form. If not, we might as well use the types that the C language provides. I've been slowly fixing that throughout the libertas driver as I've been rewriting it (which task is a bit on hold right now, I know...) On an SMP host, are you sure we can't end up setting the multicast list simultaneously on the two logical devices? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Its.an.education.project] Sugar on the EEE PC
Jaya Kumar wrote: Overall XO - Peak power consumption: ?? Typical power consumption: ?? http://wiki.laptop.org/go/XO_Power_Draw Feel free to duplicate my experiments and send me your results/questions/suggestions. On area that needs looking at again is Sleep mode. The plan in sleep mode (and other low power non-wlan modes) is to put the WLAN into reset rather than just removing the firmware. -- Richard Smith [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Tue, 2008-05-13 at 13:47 +0100, David Woodhouse wrote: On Fri, 2008-05-09 at 21:00 -0700, [EMAIL PROTECTED] wrote: Each device maintains its own list of bound multicast addresses. Those lists are merged and purged from duplicate addresses before being sent to firmware. The maximum number of multicast addresses per virtual device has been cut in half to ensure that the merged list can be accommodated by the hardware. Also, configuration flags are ORed before being sent to firmware, which appears to be the least conflicting way of combining two virtual operating modes into one for a single physical device. Based on patches from Ashish Shukla and David Woodhouse. Signed-off-by: Javier Cardona [EMAIL PROTECTED] Tested by: Ricardo Carrano [EMAIL PROTECTED] Looks good, but please don't introduce any more of the 'u8' and 'u32' nonsense. If types are user-visible, we have to use the '__u32' form. If not, we might as well use the types that the C language provides. I've been slowly fixing that throughout the libertas driver as I've been rewriting it (which task is a bit on hold right now, I know...) On an SMP host, are you sure we can't end up setting the multicast list simultaneously on the two logical devices? (A: No.) And even without that, it doesn't seem to do the right thing. Set IFF_PROMISC mode on one interface, then on the other, then clear it on the first it should remain set in hardware. And AFAICT it doesn't. I'll see if I can make it work -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: very simple datastore reimplementation
On Tue, 2008-05-13 at 18:56 +1200, Martin Langhoff wrote: On Sat, May 10, 2008 at 2:15 AM, Jim Gettys [EMAIL PROTECTED] wrote: FUSE is great, but... It means interoperability must be an explicit planned-in-advance action: Exactly. That's also my beef with the FUSE approach. The things we can do via FUSE we can do in the regular FS. So let's avoid FUSE, and use a *simple* convention on how to store things in the FS. Something roughly along the lines of: The reason for FUSE (specifically via the new Gnome replacement for the old, unloved, GnomeVFS) is to enable better interoperability with non-Sugar applications (for example, when we are able to do versioning), where relying strictly on some name munging does not get you to a good point. So a solution that only solves the debugging and interoperability to non-Sugar systems may be a step on a longer road. Please distinguish two threads here: where we need to go in the long term, and demands of the next release. Just because we can't necessarily reach our goals immediately and do something in the short term to solve the most pressing issue, doesn't mean the goals should not be defined and discussed. Often plans take time to execute and without them, you won't end up in a good end-point. And without such planning and a roadmap it is almost impossible attract contributors to the desired end-point. Jim -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: VGA external on OLPC
Note there are USB display adapters (I have one in my hand as I write this); I'd love to see someone working on X.org drivers for it. There may even be some code kicking around that just needs TLC (though it's been long enough I'd have to dig up my contacts and check). If there is anyone interested out there, let me know. - Jim On Tue, 2008-05-13 at 08:29 +0200, Dietmar Stölting wrote: Hi all, after reading http://www.whyxo.com/2008/01/08/external-monitor-or-projector-for-the-xo/ I am sure, that it is possible to integrate a VGA external connector for the OLPC. On the Prototype-A motherboard layout there was such an external VGA connector, but on G1G1 version it is gone. I am a teacher and it would be very good for projection with a beamer or if your LCD is broken, to have such an external VGA connector. My problem is, that I have no schematic or a good photo of both sides of the Prototype-A motherboard. You can read in the Geode LX databook, that the Geode LX chip offers direct VGA support and connection. But some parts of the Prototype-A motherboard have gone in G1G1 version and so I cannot see, which direct lines from the processor has to be used for the direct VGA support. Pin 1,2,3 are used for the RGB signal on the G1G1 layout, and pin 13 seems to be Hsync and pin 14 Vsync. I do not know, what is the use of pin 4,9,12,15, because they are also wired on the G1G1 version. Pin 5, 6,7,8,10,11 are not connected on the G1G1 version and I think, that this was the same for the Prototype-A motherboard layout. But still there must be the lines direct to the Geode processor from the Prototype-A layout. They only have to be found (recogniced) via a good photo of the Prototype-A layout (both sides). Please send me your photos and rtell me, what you think about my idea, Dietmar PS: RGB lines of VGA ends on G1G1 layout direct in font of C51, C41, C86. If this is true, only Vsync and Hsync have to be found. Wikipedia says about the pins for VGA: Pin 1 RED Red video Pin 2 GREEN Green video Pin 3 BLUE Blue video Pin 4 N/C Not connected Pin 5 GND Ground (HSync) Pin 6 RED_RTN Red return Pin 7 GREEN_RTN Green return Pin 8 BLUE_RTN Blue return Pin 9 +5 V +5 V (DDC) Pin 10 GND Ground (VSync, DDC) Pin 11 N/C Not connected Pin 12 SDA I²C data Pin 13 HSync Horizontal sync Pin 14 VSync Vertical sync Pin 15 SCL I²C clock ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: VGA external on OLPC
On May 13, 2008, at 2:29 AM, Dietmar Stölting wrote: Hi all, after reading http://www.whyxo.com/2008/01/08/external-monitor-or-projector-for- the-xo/ I am sure, that it is possible to integrate a VGA external connector for the OLPC. On the Prototype-A motherboard layout there was such an external VGA connector, but on G1G1 version it is gone. I am a teacher and it would be very good for projection with a beamer or if your LCD is broken, to have such an external VGA connector. My problem is, that I have no schematic or a good photo of both sides of the Prototype-A motherboard. You can read in the Geode LX databook, that the Geode LX chip offers direct VGA support and connection. But some parts of the Prototype-A motherboard have gone in G1G1 version and so I cannot see, which direct lines from the processor has to be used for the direct VGA support. Pin 1,2,3 are used for the RGB signal on the G1G1 layout, and pin 13 seems to be Hsync and pin 14 Vsync. I do not know, what is the use of pin 4,9,12,15, because they are also wired on the G1G1 version. Pin 5, 6,7,8,10,11 are not connected on the G1G1 version and I think, that this was the same for the Prototype-A motherboard layout. But still there must be the lines direct to the Geode processor from the Prototype-A layout. They only have to be found (recogniced) via a good photo of the Prototype-A layout (both sides). Please send me your photos and rtell me, what you think about my idea, Dietmar http://wiki.laptop.org/go/Remote_display You are not the first to think of this, nor will you be the first to try it. We don't recommend it. wad - [Additional information you will need if you choose to proceed] Components that were depopulated on C2 (MP machines) needed to support VGA output are: U2, U3: 74AHCT1G125GW(sync drivers) C152:0.1 uF R1, R2, R3: 75 ohm To support the VGA I2C link (UART 2 on the CS5536 southbridge): R122, R123: 10K Q7, Q8: 2N7002 R115, R116: 10K D6: CH501H-40PT (just about any schottky diode should do, this is inline in the +5V supplied to the monitor) Good luck finding that VGA connector, I don't have a part number for it. The pinout is attached. The signal/pin mapping is: Red - 1 Green - 2 Blue - 3 NC - 4,11 GND - 5,6,7,8,10 VSYNC - 14 HSYNC - 13 EDID_DATA - 12 EDID_CLK - 15 VGA Pinout.pdf Description: Adobe PDF document ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: VGA external on OLPC
Jim Gettys [EMAIL PROTECTED] writes: Note there are USB display adapters (I have one in my hand as I write this); I'd love to see someone working on X.org drivers for it. [...] The sisusb-based USB display adapters have both kernel and x.org drivers today. - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] 65-node simple mesh test (and counting... ;-)
John Watlington wrote: 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 ? If you refer to the hybrid routing protocol, it constructs a spanning tree of the whole mesh network rooted at some node. This is meant to be used in non-homogenous meshes (eg having an MPP or access point that acts as the root). So it may help in a school environment, but not in a simple mesh environment where all nodes are equal (if you attempt to build a different tree rooted at every node, you will probably face the wrath of a proactive protocol running on a mobile network - god save us from such a day ;-) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: VGA external on OLPC
On Tue, May 13, 2008 at 11:17 AM, Frank Ch. Eigler [EMAIL PROTECTED] wrote: Jim Gettys [EMAIL PROTECTED] writes: Note there are USB display adapters (I have one in my hand as I write this); I'd love to see someone working on X.org drivers for it. [...] The sisusb-based USB display adapters have both kernel and x.org drivers today. Yes, I bought one of these and tried to get it going. I couldn't find any reason why it shouldn't work with the standard drivers, but the whole process of simply trying to get the drivers from the standard tree compiled and on my XO wore out my patience. Putting the right drivers (usb2vga and a couple dependencies, iirc) in a XO kernel package would be a big help. --Tom ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Tue, 2008-05-13 at 15:38 +0100, David Woodhouse wrote: And even without that, it doesn't seem to do the right thing. Set IFF_PROMISC mode on one interface, then on the other, then clear it on the first it should remain set in hardware. And AFAICT it doesn't. I'll see if I can make it work Hm, a single cup of tea mostly achieves that; sorry :) I was missing the fact that priv-packetfilter[] is now an array. It got a bit clearer after I reformatted it to stop trying to fit in 80 columns. Sometimes the code just doesn't fit; it's painful to try to make it. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: VGA external on OLPC
On Tue, May 13, 2008 at 8:27 AM, Bert Freudenberg [EMAIL PROTECTED] wrote: Did you try the binaries? http://wiki.laptop.org/go/Remote_display#Binaries Ah, well, I guess someone has been working on this since the last time I looked at it ;-) --Tom ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: VGA external on OLPC
On May 13, 2008, at 11:27 AM, Bert Freudenberg wrote: Did you try the binaries? http://wiki.laptop.org/go/Remote_display#Binaries - Bert - Can you be more specific as to what USB video adapters this might work with ? wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: very simple datastore reimplementation
Hi Martin, I would love to see such a simple implementation if possible. Nothing gives more robustness to a component than dropping it. Some questions follow below. On Tue, May 13, 2008 at 8:56 AM, Martin Langhoff [EMAIL PROTECTED] wrote: On Sat, May 10, 2008 at 2:15 AM, Jim Gettys [EMAIL PROTECTED] wrote: FUSE is great, but... It means interoperability must be an explicit planned-in-advance action: Exactly. That's also my beef with the FUSE approach. The things we can do via FUSE we can do in the regular FS. So let's avoid FUSE, and use a *simple* convention on how to store things in the FS. Something roughly along the lines of: - Make a directory per document, name it user-picked-name-10-char-hash This is one of the issues with human readable file names: the user is not forced to pick a name. The closer we can use is the title property in the metadata, but that needs to be processed so its safe to be used as a file name across different filesystem types, and if the user doesn't set titles, we'll end up with lots of entries with very similar names (thus only distinguished by their hash). Eben has plans to suggest more strongly to set a title, so this should get better soon. - Inside that directory, metadata.txt has simple metadata in a nice, human-readable format. Fine. - If there are versions for this file, perhaps they are in a .git directory, or similar (.svn anyone? ;-) ) Which API would be used by activities and the journal to access versions? - Otherwise, the files in the directory are whatever the activity or application considers to be the document Fine. - We use this same format on external media and on local media What if the user adds a metadata property of a plain old file in an usb stick? The folder structure needs to be created? - Jornal can maintain a hidden documents metadata database at the root of each FS. This is merely a cached index to have faster mount times (avoiding a rebuild of said index if we can deem it safe). Ok. - We need a reasonable failsafe behaviour if we find that metadata.txt is b0rken and unreadable. Yup. and that's it. It's a trivial thing, will work on any fs, on any OS, no magic tricks needed. We can do fast searches on based on the documents metadata, and the only slow op is mounting a device where the documents metadata is stale or missing. IMO, jg is hinting towards something like this. If something like this is done in a way that it uses atomic ops most of the time (using an idiom of write to tmpfile, close and then mv instead of write-in-place) then we have something pretty much bulletproof, failsafe, and fast. Or at least as fast as the kernel-level FS implementation is. And it's bound to be a small simple thing too :-) Some more issues: - What about security? http://wiki.laptop.org/go/OLPC_Bitfrost#P_DOCUMENT:_file_store_service http://wiki.laptop.org/go/OLPC_Bitfrost#P_DOCUMENT_RO - What should be done if an activity stores the entry in an invalid format? If we only have guidelines, we cannot enforce any rules at write time. Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: VGA external on OLPC
On 13.05.2008, at 17:40, John Watlington wrote: On May 13, 2008, at 11:27 AM, Bert Freudenberg wrote: Did you try the binaries? http://wiki.laptop.org/go/Remote_display#Binaries - Bert - Can you be more specific as to what USB video adapters this might work with ? I have no idea. These are not my binaries. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 65-node simple mesh test (and counting... ;-)
On Tue, May 13, 2008 at 11:59 AM, John Watlington [EMAIL PROTECTED] wrote: 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 ? My definition, since I never found o good one in the literature. In a sparse mesh the number of active neighbors is smaller than your retry limit. So, in a sparse mesh your frame will never be discarded without being transmitted at least one time. In a dense mesh, there is a chance that a frame will reach the retry limit without being ever transmitted. So, 10 XOs in a room is a dense mesh (in that definition). I've done some tests in sparse topologies early in 2007. but I doubt they have any lasting values, after so many changes and fixes. Back there we were particularly interested in the hidden node problem and checked to see if RTS/CTS would help us (by the way it does not seem to help in multihop scenarios http://www.midiacom.uff.br/~schara/publications/SBrT2007.pdf) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: very simple datastore reimplementation
On 13 May 2008, at 07:56, Martin Langhoff wrote: and that's it. It's a trivial thing, will work on any fs, on any OS, no magic tricks needed. We can do fast searches on based on the documents metadata, and the only slow op is mounting a device where the documents metadata is stale or missing. IMO, jg is hinting towards something like this. If something like this is done in a way that it uses atomic ops most of the time (using an idiom of write to tmpfile, close and then mv instead of write-in-place) then we have something pretty much bulletproof, failsafe, and fast. Or at least as fast as the kernel-level FS implementation is. Yes, this sounds a much more reasonable way forward for the DS, and we know it already **works_very_well**. It's the same approach Apple has taken with OS X. The GUI showing its metaphor for applications and documents objects, while the (relatively standard) POSIX file-system actually uses bundles (directories) as containers for all the various files that make up said application, or a multi-file document (say a text document with imbedded images, or a movie composition made of many clips). The cached index database (Spotlight) is stored at the root of each file-system in a hidden dot folder and can be rebuilt as needed from the actual file content; it can even be omitted for certain mountable volumes if desired. You can happily use standard command line tools to grep, sed, awk, scp, vim, whatever – or use the high level GUI tools; and actually a fair few of those GUIs are just wrappers calling the standard command line tools. --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] 65-node simple mesh test (and counting... ;-)
On Tue, May 13, 2008 at 12:19 PM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: John Watlington wrote: 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 ? If you refer to the hybrid routing protocol, it constructs a spanning tree of the whole mesh network rooted at some node. This is meant to be used in non-homogenous meshes (eg having an MPP or access point that acts as the root). So it may help in a school environment, but not in a simple mesh environment where all nodes are equal (if you attempt to build a different tree rooted at every node, you will probably face the wrath of a proactive protocol running on a mobile network - god save us from such a day ;-) Yes. That's the point. When you put XOs in a classroom and point them to a school server you are concentrating the traffic to a single node. It makes sense, imo, to make the school server the root of a tree. But only the server. Switching to infra also makes sense if you are most interested in the services provided by the school server or the internet. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Its.an.education.project] An OLPC Development Model
On Mon, May 12, 2008 at 6:37 PM, Martin Langhoff [EMAIL PROTECTED] wrote: On Sat, May 10, 2008 at 2:03 AM, Jim Gettys [EMAIL PROTECTED] wrote: I have always believed we need Sugar. One only has to watch a child struggle with a conventional desktop (Windows, Linux or Mac) to see the need It's a lot more than that . When you contrast the current WIMP UI and generic apps with UIs built for _learning_, it's frustrating to the point of being ridiculous how what we know as conventional UIs get in the way. You and I have seen it, but we need to show it to the rest of the world. Would anybody be interested in doing videos of children at different computers, with commentary on what's happening, or not happening? What is the Constructivist way to teach grown-ups about how children learn? Having constructivist thinking behind the UI makes a huge difference when you are working with kids. It has made moodle what it is (the project lead is a fantastic programmer as well as an educationalist, and he cares a ton about the UI). I would not work in an educational project without a clear UI concept, and Sugar is - in that sense - fantastic. 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 -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Its.an.education.project] An OLPC Development Model
On Tue, May 13, 2008 at 9:14 PM, Edward Cherlin [EMAIL PROTECTED] wrote: On Mon, May 12, 2008 at 6:37 PM, Martin Langhoff [EMAIL PROTECTED] wrote: On Sat, May 10, 2008 at 2:03 AM, Jim Gettys [EMAIL PROTECTED] wrote: I have always believed we need Sugar. One only has to watch a child struggle with a conventional desktop (Windows, Linux or Mac) to see the need It's a lot more than that . When you contrast the current WIMP UI and generic apps with UIs built for _learning_, it's frustrating to the point of being ridiculous how what we know as conventional UIs get in the way. You and I have seen it, but we need to show it to the rest of the world. Would anybody be interested in doing videos of children at different computers, with commentary on what's happening, or not happening? What is the Constructivist way to teach grown-ups about how children learn? Personally I would hope it includes peer-reviewed research. Does anyone have links to how constructionist teaching methods compare to traditional ones? (sorry if people have posted this before... its been hard to keep up with all the mail) yours, Bobby Powers ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
The maximum number of multicast addresses per virtual device has been cut in half to ensure that the merged list can be accommodated by the hardware. If we allocated DRAM this way, no process could use more than 1/N of the memory, where N is the number of processes. Surely this is inappropriate. If eth0 is not in use, msh0 should be able to use all of the hardware's multicast addresses. And vice verse, and all points in between. Signal an error to the caller when both devices combined would exceed the hardware's capacity. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Mind improving tool announcement
On Mon, May 12, 2008 at 1:58 PM, qwerty [EMAIL PROTECTED] wrote: Hello, everybody. I'd like to present you our project in OLPC. Tool that we develop improves such system thinking skills as generalizing, abstracting, decomposing. The idea is to make the application as intuitive as possible with the help of ideas of mind mapping and modeling software. At first, children choose the topic of current modeling session. They can take one of existing topics or create their own one. After that, children use tool palette to create objects and relationships between them in the context of the topic. I took a look. So far, I seen an enhanced mindmapping tool with crosslinking and backlinking, and I take your word for it that there is much more. I like the graphical UI so far. Each topic is represented by ontology so relationships and objects are elements of topic ontologies. Where do these ontologies come from? Who creates them, and how? Ontologies imply various purposes, even epistemologies and ethical systems. The ontology of nations supports many political and economic purposes, while denying others, and has often been used to justify war, although it could in principle be used just as well to justify international cooperation. The ontology and epistemology of Free Software or of Constructionist education are quite different from those of proprietary software and the long tradition of Prussian-style education, with its insistence that the correct answers are those that you memorized from the textbook. Relationships can have properties (transitive, symmetric, functional, inverse functional), and object can unite into classes. When map is created in the workspace, children can ask questions about it (about existing objects and their relations with far-away ones). Ontology ideas are very close to the system thinking. Piaget and Vygotsky asked how children construct their epistemologies and ontologies out of their experience. With the ability to represent properties, classes, individual concepts etc in a simple and funny way this tool will be suitable for entertaining and educating children. We don't know yet what ontology language to use, it could be RDF or OWL. Does anybody know something about similar projects? Or may be somebody wants to join us? At the moment we are working in a group of three. I'm interested in asking questions in the hope that I and you will come to understand what your project may mean. Our UI Prototype here: http://kkv.spb.su/doku.php?id=etc:teach:diplomants:projects:2009:olpcmind:artifacts:inception:requirements:uiprototype Other artifacts are only in Russian, we will translate it, if it's necessary. Хорошо, спасибо. Yura ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Tue, 13 May 2008 12:30:53 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 13 May 2008 13:20:19 -0400
Andres Salomon [EMAIL PROTECTED] wrote:
On Tue, 13 May 2008 15:45:39 +0100
David Woodhouse [EMAIL PROTECTED] wrote:
On Tue, 2008-05-13 at 15:38 +0100, David Woodhouse wrote:
And even without that, it doesn't seem to do the right thing.
Set IFF_PROMISC mode on one interface, then on the other, then
clear it on the first it should remain set in hardware. And
AFAICT it doesn't.
I'll see if I can make it work
Hm, a single cup of tea mostly achieves that; sorry :)
I was missing the fact that priv-packetfilter[] is now an array.
It got a bit clearer after I reformatted it to stop trying to fit
in 80 columns. Sometimes the code just doesn't fit; it's painful
to try to make it.
Gosh, I sure wish you, Andrew, checkpatch.pl, and Ingo[0] were all
on the same page regarding that.. it would sure make my life easier.
David is off in his own little world on this and can be safely
ignored.
Meanwhile the rest of us are forced to stare at crocks of shit like
http://userweb.kernel.org/~akpm/x.jpg, wondering who hates us and why.
And Ingo's comments?
While I normally agree w/ breaking long lines up, when the entire line
is a string, I find it a large pain to break it up. I'm curious if
people would be against checkpatch.pl not complaining about lines 80
chars if the line contains a quoted string.
Actually, I wonder if the following patch would be acceptable (ignoring
the fact that it fails checkpatch.pl, of course :)
From: Andres Salomon [EMAIL PROTECTED]
Subject: [PATCH] checkpatch: make the 80-char-line check slightly more lax;
allow long strings
Currently, the 80-char-line check in checkpatch.pl doesn't allow the following:
+ printk(KERN_WARNING
+ one two three
fooo\n);
Instead, one must break the string up into multiple lines, like so:
+ printk(KERN_WARNING
+ one two three
+ fooo\n);
This is not really easier to read, and as Ingo has pointed out, it makes
life harder for people grepping for kernel messages. Of course, we don't
want to allow gratuitously long printk lines if they're unnecessary.
This patch allows a line to be 80 chars if it contains only a string and
some extra stuff at the end (',', ';', or ')'). Thus,
+ printk(KERN_WARNING
+ one two three
fooo\n);
and
+ printk(KERN_WARNING
+ one two three
fo\n,
+ xyz);
are allowed, but
+ printk(KERN_WARNING one two three
fooo\n);
and
+ printk(KERN_WARNING
+ one two three
foo\n, xyz);
are not.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
scripts/checkpatch.pl |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index b6bbbcd..00f3d05 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1117,7 +1117,7 @@ sub process {
ERROR(trailing whitespace\n . $herevet);
}
#80 column limit
- if ($line =~ /^\+/ !($prevrawline=~/\/\*\*/) $length
80) {
+ if ($line =~ /^\+/ !($prevrawline=~/\/\*\*/) !($line =~
/^\+\s*/ $line =~ /[);,\s]*$/) $length 80) {
WARN(line over 80 characters\n . $herecurr);
}
--
1.5.5.1
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Mind improving tool announcement
1. First of all, I mean only weak ontologies (see http://en.wikipedia.org/wiki/Ontology_%28computer_science%29 ). And I think, that all your questions related to the ontology in philosophy and fundamental science. It's true? 2. We (developers) will create some ontologies (animals, some study courses, etc) in OWL language. These ontologies will be included to the program from the first version. 2.1. When user do something - creates relations, adds object and classes - he edits ontology. When he asks something - he launch inference engine. I don't know anything about mindmapping tools, which can do something sumular. P.S. Просто из любыпытства: вы тоже русский, или лишь проявили вежливость к нашему языку? Yura. On Mon, May 12, 2008 at 1:58 PM, qwerty [EMAIL PROTECTED] wrote: Hello, everybody. I'd like to present you our project in OLPC. Tool that we develop improves such system thinking skills as generalizing, abstracting, decomposing. The idea is to make the application as intuitive as possible with the help of ideas of mind mapping and modeling software. At first, children choose the topic of current modeling session. They can take one of existing topics or create their own one. After that, children use tool palette to create objects and relationships between them in the context of the topic. I took a look. So far, I seen an enhanced mindmapping tool with crosslinking and backlinking, and I take your word for it that there is much more. I like the graphical UI so far. Each topic is represented by ontology so relationships and objects are elements of topic ontologies. Where do these ontologies come from? Who creates them, and how? Ontologies imply various purposes, even epistemologies and ethical systems. The ontology of nations supports many political and economic purposes, while denying others, and has often been used to justify war, although it could in principle be used just as well to justify international cooperation. The ontology and epistemology of Free Software or of Constructionist education are quite different from those of proprietary software and the long tradition of Prussian-style education, with its insistence that the correct answers are those that you memorized from the textbook. Relationships can have properties (transitive, symmetric, functional, inverse functional), and object can unite into classes. When map is created in the workspace, children can ask questions about it (about existing objects and their relations with far-away ones). Ontology ideas are very close to the system thinking. Piaget and Vygotsky asked how children construct their epistemologies and ontologies out of their experience. With the ability to represent properties, classes, individual concepts etc in a simple and funny way this tool will be suitable for entertaining and educating children. We don't know yet what ontology language to use, it could be RDF or OWL. Does anybody know something about similar projects? Or may be somebody wants to join us? At the moment we are working in a group of three. I'm interested in asking questions in the hope that I and you will come to understand what your project may mean. Our UI Prototype here: http://kkv.spb.su/doku.php?id=etc:teach:diplomants:projects:2009:olpcmind:artifacts:inception:requirements:uiprototype Other artifacts are only in Russian, we will translate it, if it's necessary. Хорошо, спасибо. Yura ___ 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: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Tue, 13 May 2008 13:20:19 -0400 Andres Salomon [EMAIL PROTECTED] wrote: On Tue, 13 May 2008 15:45:39 +0100 David Woodhouse [EMAIL PROTECTED] wrote: On Tue, 2008-05-13 at 15:38 +0100, David Woodhouse wrote: And even without that, it doesn't seem to do the right thing. Set IFF_PROMISC mode on one interface, then on the other, then clear it on the first it should remain set in hardware. And AFAICT it doesn't. I'll see if I can make it work Hm, a single cup of tea mostly achieves that; sorry :) I was missing the fact that priv-packetfilter[] is now an array. It got a bit clearer after I reformatted it to stop trying to fit in 80 columns. Sometimes the code just doesn't fit; it's painful to try to make it. Gosh, I sure wish you, Andrew, checkpatch.pl, and Ingo[0] were all on the same page regarding that.. it would sure make my life easier. David is off in his own little world on this and can be safely ignored. Meanwhile the rest of us are forced to stare at crocks of shit like http://userweb.kernel.org/~akpm/x.jpg, wondering who hates us and why. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Tue, 2008-05-13 at 12:30 -0700, Andrew Morton wrote: On Tue, 13 May 2008 13:20:19 -0400 Andres Salomon [EMAIL PROTECTED] wrote: On Tue, 13 May 2008 15:45:39 +0100 David Woodhouse [EMAIL PROTECTED] wrote: On Tue, 2008-05-13 at 15:38 +0100, David Woodhouse wrote: And even without that, it doesn't seem to do the right thing. Set IFF_PROMISC mode on one interface, then on the other, then clear it on the first it should remain set in hardware. And AFAICT it doesn't. I'll see if I can make it work Hm, a single cup of tea mostly achieves that; sorry :) I was missing the fact that priv-packetfilter[] is now an array. It got a bit clearer after I reformatted it to stop trying to fit in 80 columns. Sometimes the code just doesn't fit; it's painful to try to make it. Gosh, I sure wish you, Andrew, checkpatch.pl, and Ingo[0] were all on the same page regarding that.. it would sure make my life easier. David is off in his own little world on this and can be safely ignored. Meanwhile the rest of us are forced to stare at crocks of shit like http://userweb.kernel.org/~akpm/x.jpg, wondering who hates us and why. I think the large amount of whitespace in the screenshot at http://david.woodhou.se/narrow.png shows quite effectively why I think you're talking nonsense on this particular topic. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Tue, 13 May 2008 22:59:26 +0100 David Woodhouse [EMAIL PROTECTED] wrote: On Tue, 2008-05-13 at 12:30 -0700, Andrew Morton wrote: On Tue, 13 May 2008 13:20:19 -0400 Andres Salomon [EMAIL PROTECTED] wrote: On Tue, 13 May 2008 15:45:39 +0100 David Woodhouse [EMAIL PROTECTED] wrote: On Tue, 2008-05-13 at 15:38 +0100, David Woodhouse wrote: And even without that, it doesn't seem to do the right thing. Set IFF_PROMISC mode on one interface, then on the other, then clear it on the first it should remain set in hardware. And AFAICT it doesn't. I'll see if I can make it work Hm, a single cup of tea mostly achieves that; sorry :) I was missing the fact that priv-packetfilter[] is now an array. It got a bit clearer after I reformatted it to stop trying to fit in 80 columns. Sometimes the code just doesn't fit; it's painful to try to make it. Gosh, I sure wish you, Andrew, checkpatch.pl, and Ingo[0] were all on the same page regarding that.. it would sure make my life easier. David is off in his own little world on this and can be safely ignored. Meanwhile the rest of us are forced to stare at crocks of shit like http://userweb.kernel.org/~akpm/x.jpg, wondering who hates us and why. I think the large amount of whitespace in the screenshot at http://david.woodhou.se/narrow.png shows quite effectively why I think you're talking nonsense on this particular topic. That's an 80-column display. If that's the best your can do, you have nothing. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: VGA external on OLPC
On Wed, May 14, 2008 at 3:40 AM, John Watlington [EMAIL PROTECTED] wrote: http://wiki.laptop.org/go/Remote_display#Binaries Can you be more specific as to what USB video adapters this might work with ? It's packaged in most distros (F7, recent Ubuntus), so `man sisusb` or `man sisusbvga` should give an passable overview. The author keeps a good page: http://www.winischhofer.eu/linuxsisusbvga.shtml Quote: This page provides information on Net2280/SiS315 based USB2VGA dongles of various makes, usually called USB2VGA or USB-to-SVGA dongle; one of the companies marketing such a device is called Sitecom, another is Tritton This other page http://www.nslu2-linux.org/wiki/HowTo/AddVGAAdapter lists 3 devices: * Sitecom CN-105 * Sweex KB100050 * Startech.com USB2VGA I'll update the wiki 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
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Tue, 13 May 2008 15:06:23 -0700 Andrew Morton [EMAIL PROTECTED] wrote: On Tue, 13 May 2008 22:59:26 +0100 David Woodhouse [EMAIL PROTECTED] wrote: On Tue, 2008-05-13 at 12:30 -0700, Andrew Morton wrote: On Tue, 13 May 2008 13:20:19 -0400 Andres Salomon [EMAIL PROTECTED] wrote: On Tue, 13 May 2008 15:45:39 +0100 David Woodhouse [EMAIL PROTECTED] wrote: On Tue, 2008-05-13 at 15:38 +0100, David Woodhouse wrote: And even without that, it doesn't seem to do the right thing. Set IFF_PROMISC mode on one interface, then on the other, then clear it on the first it should remain set in hardware. And AFAICT it doesn't. I'll see if I can make it work Hm, a single cup of tea mostly achieves that; sorry :) I was missing the fact that priv-packetfilter[] is now an array. It got a bit clearer after I reformatted it to stop trying to fit in 80 columns. Sometimes the code just doesn't fit; it's painful to try to make it. Gosh, I sure wish you, Andrew, checkpatch.pl, and Ingo[0] were all on the same page regarding that.. it would sure make my life easier. David is off in his own little world on this and can be safely ignored. Meanwhile the rest of us are forced to stare at crocks of shit like http://userweb.kernel.org/~akpm/x.jpg, wondering who hates us and why. I think the large amount of whitespace in the screenshot at http://david.woodhou.se/narrow.png shows quite effectively why I think you're talking nonsense on this particular topic. That's an 80-column display. If that's the best your can do, you have nothing. Can we come to a consensus for the sake of outside contributors? Rather than telling the cozybit folks one thing, and having checkpatch.pl and CodingStyle claim another (Dave, surely you wouldn't argue against using checkpatch?), can we get our stories straight? Please? And FWIW, I like the 80 char limit _except_ when it comes to strings. I've wasted too much time truncating strings, changing error messages so that the printk doesn't exceed 80 chars, etc. CodingStyle gives a nice example of how unreadable that sort of thing is. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: very simple datastore reimplementation
On Wed, May 14, 2008 at 1:18 AM, Jim Gettys [EMAIL PROTECTED] wrote: The reason for FUSE (specifically via the new Gnome replacement for the old, unloved, GnomeVFS) is to enable better interoperability with non-Sugar applications (for example, when we are able to do versioning), And yet, at the exact point we start using FUSE we get in trouble with portability for Sugar apps. Can we shift the behaviour we want to put in the FUSE layer into a Sugar-level library that just uses POSIX underneath? 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
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Tue, 13 May 2008 19:12:27 -0400 Andres Salomon [EMAIL PROTECTED] wrote: And FWIW, I like the 80 char limit _except_ when it comes to strings. I don't normally bother about the strings, unless it is obvious that the surrounding code has worked to prevent them from wrapping (and if I notice that). Or if they make code particularly hard to read and alter. I've seen some which wander out to column 130, which is getting daft. The code at http://userweb.kernel.org/~akpm/x.jpg has short strings, but it has gone and stuffed the _arguments_ onto the same line too, which is just obnoxious. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: very simple datastore reimplementation
On Wed, 2008-05-14 at 11:15 +1200, Martin Langhoff wrote: On Wed, May 14, 2008 at 1:18 AM, Jim Gettys [EMAIL PROTECTED] wrote: The reason for FUSE (specifically via the new Gnome replacement for the old, unloved, GnomeVFS) is to enable better interoperability with non-Sugar applications (for example, when we are able to do versioning), And yet, at the exact point we start using FUSE we get in trouble with portability for Sugar apps. Sugar apps have datastore dependencies in the first place, whether on the current DS interface or a FUSE based one. So it doesn't change the situation there; apps talk to sugar, which talk to the DS, whether implemented via olpcfs and Fuse or not. Can we shift the behaviour we want to put in the FUSE layer into a Sugar-level library that just uses POSIX underneath? That's what olpcfs is doing: it exploits the POSIX interface as much as possible, and if you read Scott's document (as I was today), you'll see that - Jim -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: A small present. (PenTablet-support installation script for 656/703)
On Mon, May 5, 2008 at 4:41 PM, Sameer Verma [EMAIL PROTECTED] wrote: Sameer Verma wrote: Michael Stone wrote: Friends, Over a month ago, Blake and I pieced together some software to turn on PenTablet support. At Kim's and SJ's urging, I have prepared http://teach.laptop.org/~mstone/fix-tablet.sh which makes it a bit easier to install the relevant pieces. I believe it will enable the PT on both 656 and 703 and I'm not _aware_ of any side effects, but it's definitely experimental software. Enjoy, unless you prefer to help out further by testing Andres' 2.6.25 kernels. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel Hi Michael, I ran your script without a hitch, but I am unable to see it work in Paint. Which activity will support its use? Sameer Following up on my post...I upgraded my G1G1 from 656/Q2D07 to 703/Q2D14 and updated the activities using Bert's script. I re-ran Michael's pen-tablet script. I still didn't see the pen-tablet feature working in Paint, until...I applied a lot more pressure than I had anticipated. The cursor moved! So, I guess the pen-tablet script makes it work, but the amount of pressure needed is a lot more than what I would apply to my Nokia 770 or 810. Is this expected? Yep. For whatever reason, the OLPC tablet requires quite a bit of pressure to work -- much more than conventional graphics tablets. Pat -- Patrick Dubroy http://dubroy.com/blog - on programming, usability, and hci ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: A small present. (PenTablet-support installation script for 656/703)
Hi Michael, Thanks for this. I'd like to give it a try soon, but I was just wondering...do you know if there's a way to use this without the tablet controlling the core pointer in X? From a usability point of view, I think it should work as an independent device. Thanks, Pat -- Patrick Dubroy http://dubroy.com/blog - on programming, usability, and hci On Sat, May 3, 2008 at 12:32 AM, Michael Stone [EMAIL PROTECTED] wrote: Friends, Over a month ago, Blake and I pieced together some software to turn on PenTablet support. At Kim's and SJ's urging, I have prepared http://teach.laptop.org/~mstone/fix-tablet.sh which makes it a bit easier to install the relevant pieces. I believe it will enable the PT on both 656 and 703 and I'm not _aware_ of any side effects, but it's definitely experimental software. Enjoy, unless you prefer to help out further by testing Andres' 2.6.25 kernels. Michael ___ 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: very simple datastore reimplementation
On Wed, May 14, 2008 at 12:23 PM, Jim Gettys [EMAIL PROTECTED] wrote: Can we shift the behaviour we want to put in the FUSE layer into a Sugar-level library that just uses POSIX underneath? That's what olpcfs is doing: it exploits the POSIX interface as much as possible, and if you read Scott's document (as I was today), you'll see that Not sure if we are agreeing to the same thing ;-) I guess what I was meaning to say is can we put the logic in a library _instead of_ putting it in a FUSE layer?. As I read the Olpcfs document (few weeks ago now), what I understood is that Olpcfs lays out a mostly POSIX-based convention, but uses a FUSE layer to store things. Did I completely misunderstand it? 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
Re: very simple datastore reimplementation
On Wed, 14 May 2008, Martin Langhoff wrote: On Wed, May 14, 2008 at 12:23 PM, Jim Gettys [EMAIL PROTECTED] wrote: Can we shift the behaviour we want to put in the FUSE layer into a Sugar-level library that just uses POSIX underneath? That's what olpcfs is doing: it exploits the POSIX interface as much as possible, and if you read Scott's document (as I was today), you'll see that Not sure if we are agreeing to the same thing ;-) I guess what I was meaning to say is can we put the logic in a library _instead of_ putting it in a FUSE layer?. if we put everything into a library, then all tools that access the datastore need to use that library. if we put that same functionality into FUSE then normal tools do not need to be modified at all to access the files. while I can see the desire to not have to worry about having FUSE available to easily access the raw data, I think that it's far easier to do that then it is to modify every tool in the world to use the library to access the datastore instead. either way you have scenerios where it's hard to access the data (after all, if you are running on an OS that doesn't support FUSE, what makes you think that it will have all your custom tools), but in one case you have to re-write every program that accesses files, in the other you can use standard utilities. David Lang As I read the Olpcfs document (few weeks ago now), what I understood is that Olpcfs lays out a mostly POSIX-based convention, but uses a FUSE layer to store things. Did I completely misunderstand it? cheers, m ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: very simple datastore reimplementation
On Wed, 14 May 2008, Martin Langhoff wrote: On Wed, May 14, 2008 at 12:45 PM, [EMAIL PROTECTED] wrote: if we put everything into a library, then all tools that access the datastore need to use that library. All we need is to state a simple enough convention (put your files in *this* subdirectory), and handle metadata from the journal. assuming that none of the tools have any reason to do anything with the metadata if we put that same functionality into FUSE then normal tools do not need to be modified at all to access the files. If we use FUSE, we also have to get the app to put the files in a given subdirectory. And we also have to handle the metadata outside (unless we chance the app). From Olpcfs's document we do win some versioning, but with some experience in SCMs I seriously think all we need is versioning on app exit, which we can do outside. If we really want to be hanging there on each close() we can use inotify() and friends, but you don't want to see what apps do to files to _that_ granularity. Really. Ever. with the FUSE approach you have a lot more potential. since the access to the filesystem is decoupled from the actual storage of the data it becomes a very natural place to hide details such as offline file access (retreiving data from a school server transparently), etc. dealing with versioning is just the tip of the iceberg. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Half a New Planning Thoughts Draft; release management half.
Available at a wiki near you: http://wiki.laptop.org/go/Plan_of_Record-2008/Draft_3 The important changes since the last version include: * simplified prose, care of Mitch * a serious proposal for a stable release process for the next few months * separation of release management thoughts from development thoughts (which will be explained in a second essay if they compress into something sound) As promised with the last draft, Kim and I are working from both ends toward the middle to get us to an acceptable plan with help from pretty much everyone. Keep on helping; we like it! Questions? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Possible Jabber Problem on Server
I was very explicit in my instructions: 1) Remove the package. 2) Remove the database. 3) Install the package. Installing the package probably rebuilds the database. If you re-install without removing the old database, the re-install seems to re-use the old database. John On May 12, 2008, at 1:55 PM, Andrew Berkowitz wrote: Should ejabberd automatically create a new database if it does not find one? I had already tried deleting the files. But then ejabberd wouldn't start. Andrew Berkowitz [EMAIL PROTECTED] NYCBoE: 718-935-5471 cell: 917-613-3941 On May 8, 2008, at 5:15 PM, Andrew Berkowitz wrote: Or, how do I just wipe out the mnesia database and start over? I believe rm -r /var/lib/ejabberd/* ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Possible Jabber Problem on Server
John, Maybe you misinterpreted my question. I was asking if there was a way to wipe out the database and create a new one without reinstalling. Obviously reinstalling ejabberd creates a new database. Martin had suggested that we can just wipe out the database without reinstalling the package. So back to the question: Can the database be wiped out and recreated without reinstalling? Thank you Andrew Berkowitz --- I was very explicit in my instructions: 1) Remove the package. 2) Remove the database. 3) Install the package. ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Possible Jabber Problem on Server
On Wed, May 14, 2008 at 5:36 AM, Berkowitz Andrew (Project Connect) [EMAIL PROTECTED] wrote: Martin had suggested that we can just wipe out the database without reinstalling the package. So back to the question: Can the database be wiped out and recreated without reinstalling? We haven't tested it :-/ (it all depends on exactly what triggers an empty DB setup). OTOH, we know that uninstalling/reinstalling the rpm does the trick reliably (so it is better than my earlier suggestion). It will remove the xs-pkgs package, but that won't cause any short-term problem. Reinstall it as well just in case for better long term behaviour ;-) 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 ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
