Re: OLPC upgrades
Bobby Powers writes: 2009/2/2 Tiago Marques tiagomnm at gmail.com: Python is killing the XO, what's being done in that regard? The $100 laptop will always be hardware limited, how can python be a benefit and not a *huge* burden? I for one can't get my head around that. The idea is to give kids as much transparency into the software stack as possible, AND make it easy to hack on and easy to create new activities for. Python is much more forgiving than C. Python is less forgiving if you want performance on the XO. :-) For teaching, remember that Knuth uses assembly. C is an awful lot closer to that than Python, and isn't the XO about teaching? Its killing the XO? A personal pygtk based project launches in a few seconds on my debXO install on an XO, but much much longer on 8.2. It is a completely loaded statement to say that Python is killing the XO, and didn't really deserve a response :) I'm assuming that personal [...] project means small. The fact that you consider a few seconds to be acceptable shows just how much people have lost touch with the concept of performance. IIRC, that's about how long it took my old Pentium 200 MMX with 64 MB of RAM (a quarter of what the XO has) to launch Netscape. Today on an XO, I can write code that pops up a window far faster than it needs to. Xlib can do the job in what looks like a few tenths of a second or better -- it's really too fast for me to tell. Even with a feature-rich monster like Tux Paint, I can at least pop up a window much much faster than a Python activity ever does. The stupid generic splash screen causes a very noticeable slowdown for any activity that wasn't horrifically slow by itself. Current usage of Python can be mostly explained as follows: http://en.wikipedia.org/wiki/Sunk_cost_fallacy http://en.wikipedia.org/wiki/Sunk_cost http://en.wikipedia.org/wiki/Irrational_escalation http://en.wikipedia.org/wiki/Cognitive_bias http://en.wikipedia.org/wiki/Point_of_no_return http://en.wikipedia.org/wiki/Psychology_of_previous_investment http://en.wikipedia.org/wiki/Foot_in_the_door The remaining bit of the explanation is that the developer pool is now full of Python people. Nearly all others have run away. One can't expect to attract non-Python talent when Python gets a non-negotiable privileged position. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Which wikipage lists activities for 8.2.1 ('staging') ?
2009/2/4 Mikus Grinbergs mi...@bga.com: I'm confused as to which Activities are mated to 8.2.1. The subject came up before, when it was pointed out that wikipage Activities/G1G1 lists some newer activity versions than wikipage Activities/G1G1/8.2. Correct. G1G1 lists activities that have been ported (incompatibly) in preparation for Sugar 0.84 and/or what we were working on as 9.1.0. Does that mean that wikipage Activities/G1G1 officially applies to the latest 8.2 (i.e. 8.2.1), whereas wikipage Activities/G1G1/8.2 applies only to the earlier 8.2.0 ? No - 8.2.1 still contains sugar 0.82 and contains relatively few changes on top of 8.2.0, and (hopefully) nothing that would affect activity performance or reliability. 8.2.1 is not considered unstable. G1G1/8.2 applies for 8.2.0 and 8.2.1. The naming of the page is chosen in agreement with the activity updater. Because the final version of 8.2.1 will be built in the existing stream named 8.2, the activity updater will look for Activities/G1G1/8.2. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Life in an insecure world
2009/2/4 John Watlington w...@laptop.org: I insist on b) in order to prevent inadvertent bricking of laptops by typing enable-security, Are you concerned that there is a realistic and common use case when a particular type of user would want or need to run enable-security? Or is your concern simply that there is such a command (regardless of what it actually does internally) that will break your XO? Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Treatise on Formatting FLASH Storage Devices
On Wed, Feb 04, 2009 at 12:40:38AM -1000, Mitch Bradley wrote: http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device Read it and weep. +1 Fixed a couple of typos in the last section. Also, re: Conversely, if the layout is bad, every cluster write might split two pages, forcing the FTL to perform four internal I/O operations instead of one. Is it therefore four times slower? -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Treatise on Formatting FLASH Storage Devices
On Wed, 4 Feb 2009, Mitch Bradley wrote: http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device Read it and weep. this completely ignores wear leveling, which is very nessasary for just about any filesystem, but especially for FAT (which appear to be the only filesystems this author is familiar with) all in all this doesn't seem like a very useful page. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Treatise on Formatting FLASH Storage Devices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 da...@lang.hm wrote: On Wed, 4 Feb 2009, Mitch Bradley wrote: http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device Read it and weep. this completely ignores wear leveling, which is very nessasary for just about any filesystem, but especially for FAT (which appear to be the only filesystems this author is familiar with) Umm, what? To alleviate the wear out problems, the FTL must move data around so that repeated writes to a given sector don't cause too many writes to the same NAND page. Mitch is describing FLASH devices like SD cards. All such devices have a built-in microcontroller (the FTL) that performs wear-leveling. Layering additional wear-leveling filesystems like JFFS2 or UBIFS on top of the FTL requires a reverse translation (block device-MTD) and is not recommended. e.g. From http://www.linux-mtd.infradead.org/doc/ubifs.html : UBIFS was designed to work on top of raw flash, which has nothing to do with block devices. This is why UBIFS does not work on MMC cards and the like - they look like block devices to the outside world because they implement FTL (Flash Translation Layer) support in hardware, which simply speaking emulates a block device As for the author only being familiar with FAT, that is hilarious. Mitch implemented JFFS2 support in OFW, and wrote this page to explain how he produced optimal ext2 formatting of FTL FLASH. Indeed, that is the subject of http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device#Screwed-Up_Formatting - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmJq7wACgkQUJT6e6HFtqT4sACdH/YR07Eq+l+i2M53HuWlZbF3 6bYAn3Aw3X7+k+cThHg9elaI/Jjiokp/ =6lfi -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Life in an insecure world
On 4 Feb 2009, at 12:14, Daniel Drake wrote: 2009/2/4 John Watlington w...@laptop.org: I insist on b) in order to prevent inadvertent bricking of laptops by typing enable-security, Are you concerned that there is a realistic and common use case when a particular type of user would want or need to run enable-security? FWIW, I vaguely remember a deployment last year(Uruguay maybe?) needing to do some maintenance steps (on borked XOs) where they would disable security to get into OF (I think) and then re-enable security again before sending it back. --Gary Or is your concern simply that there is such a command (regardless of what it actually does internally) that will break your XO? Daniel ___ 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: Life in an insecure world
2009/2/4 Reuben K. Caron reu...@laptop.org: Yes, I was particularly thinking of you and your experience in Ethiopia and the difficulties you faced to re-secure the laptops. I prefer to think of it as: Is there a realistic and common use case for when a *deployment* would want or need to run enable-security. Well, that doesn't apply to wad's concerns. At the same time as using a developer key to enable security, they flashed a customised build (where the signed parts had not been modified, so booting would work anyway). With the manufacturing process changes, such a deployment need not change their practices. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Life in an insecure world
On Feb 4, 2009, at 7:14 AM, Daniel Drake wrote: 2009/2/4 John Watlington w...@laptop.org: I insist on b) in order to prevent inadvertent bricking of laptops by typing enable-security, Are you concerned that there is a realistic and common use case when a particular type of user would want or need to run enable-security? Or is your concern simply that there is such a command (regardless of what it actually does internally) that will break your XO? Tthere are valid reasons in repair and manufacturing to have such a command. And there might even be a reason why a deployment might decide to turn on security. My concern is that with security disabled, kids are now free to explore OFW (this is a good thing) and that command is relatively easy to discover and might break your machine. Mitch is going to make the syntax a little more onerous. One current proposal is to require the serial number of the laptop as an argument.How about refusing to perform the command unless a valid signed image is present in the NAND ? In the same way we protect the flash command... Regarding Reuben's original concern: If you are going to enable security on a large number of laptops, you are probably going to be setting a few tags (such as providing your own signing keys) at the same time, and using a forth script on boot to perform it. Having to remove the ak tag at that point shouldn't be any extra hassle. wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Life in an insecure world
On Wed, Feb 4, 2009 at 12:22 AM, John Watlington w...@laptop.org wrote: Should we care ? I just proved that it is possible for any kid in Peru to slag their laptop by simply typing sudo rm -rf /* in a terminal window, a similar feat of child-like naivete. Alt-boot could recover from most cases like this -- although it will always be possible to do something similar. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Invitation] XOLPC gathering Cosi Sat Feb 7, 2009 no on-2pm @ Wed Feb 4 12pm – 2pm (de...@laptop.org)
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART:20090204T17Z DTEND:20090204T19Z DTSTAMP:20090204T140358Z ORGANIZER;CN=Henry Hardy:mailto:hhard...@gmail.com UID:6qh3tleihqljn7tqh9kunmf...@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;cn=xo...@void.printf.net;X-NUM-GUESTS=0:mailto:xo...@void.printf.net ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;cn=cambridge-soc...@laptop.org;X-NUM-GUESTS=0:mailto:cambridge-social@ laptop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;cn=fran...@laptop.org;X-NUM-GUESTS=0:mailto:fran...@laptop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;cn=de...@laptop.org;X-NUM-GUESTS=0:mailto:de...@laptop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=Henry Hardy;X-NUM-GUESTS=0:mailto:hhard...@gmail.com CLASS:PRIVATE CREATED:20090204T140355Z DESCRIPTION:XOLPC gathering Cosi Sat Feb 7\, 2009 noon-2pmbrbrThere wil l be a gathering for ex-OLPC employees and contractors at Cosi across from 1cc this Saturday from noon to 2pm. If it is available we will gather in th e back room around behind the counter and kitchen area. We can play with our XO's\, hang out and see our friends again. Also think about mentioning any job leads which might be of interest to others. Please pass this on to other X-OLPC'ers.brbrcheers\,brbr--HH.br clear=allbr-- brHe nry Edward Hardybrhhard...@gmail.combrhttp://www.linkedin.com/in/henryh ardybr+1-734-474-7215brbr\n\nView your event at http://www.google.com /calendar/event?action=VIEWeid=NnFoM3RsZWlocWxqbjd0cWg5a3VubWYyMTAgZGV2ZWx AbGFwdG9wLm9yZwtok=MTgjaGhhcmR5MDFAZ21haWwuY29tZDA5Y2YzZjljM2IwOTE2MGM2ZjZ iMTQ0OGRhYjA1ZDJiNTVjNWMxYwctz=America%2FNew_Yorkhl=en. LAST-MODIFIED:20090204T140356Z LOCATION:Cosi at Kendall SEQUENCE:0 STATUS:CONFIRMED SUMMARY:XOLPC gathering Cosi Sat Feb 7\, 2009 noon-2pm TRANSP:OPAQUE END:VEVENT END:VCALENDAR invite.ics Description: application/ics ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Treatise on Formatting FLASH Storage Devices
On Wed, 2009-02-04 at 00:40 -1000, Mitch Bradley wrote: http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device Read it and weep. It's a great article, but people that aren't very familiar with filesystems and the filesystem tools are going to read the article, look at their tools, scratch their heads, decide the whole thing is too hard, and go on making the same mistakes. It would be useful if actual command arguments could be given for various sane defaults. -- Ignacio Vazquez-Abrams ivazquez...@gmail.com PLEASE don't CC me; I'm already subscribed signature.asc Description: This is a digitally signed message part ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
XOLPC gathering Cosi Sat Feb 7, 2009 noon-2pm
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART:20090204T17Z DTEND:20090204T19Z DTSTAMP:20090204T140358Z ORGANIZER;CN=Henry Hardy:mailto:hhard...@gmail.com UID:6qh3tleihqljn7tqh9kunmf...@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;cn=xo...@void.printf.net;X-NUM-GUESTS=0:mailto:xo...@void.printf.net ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;cn=cambridge-soc...@laptop.org;X-NUM-GUESTS=0:mailto:cambridge-social@ laptop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;cn=fran...@laptop.org;X-NUM-GUESTS=0:mailto:fran...@laptop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;cn=de...@laptop.org;X-NUM-GUESTS=0:mailto:de...@laptop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=Henry Hardy;X-NUM-GUESTS=0:mailto:hhard...@gmail.com CLASS:PRIVATE CREATED:20090204T140355Z DESCRIPTION:XOLPC gathering Cosi Sat Feb 7\, 2009 noon-2pmbrbrThere wil l be a gathering for ex-OLPC employees and contractors at Cosi across from 1cc this Saturday from noon to 2pm. If it is available we will gather in th e back room around behind the counter and kitchen area. We can play with our XO's\, hang out and see our friends again. Also think about mentioning any job leads which might be of interest to others. Please pass this on to other X-OLPC'ers.brbrcheers\,brbr--HH.br clear=allbr-- brHe nry Edward Hardybrhhard...@gmail.combrhttp://www.linkedin.com/in/henryh ardybr+1-734-474-7215brbr\n\nView your event at http://www.google.com /calendar/event?action=VIEWueid=6qh3tleihqljn7tqh9kunmf210. LAST-MODIFIED:20090204T140356Z LOCATION:Cosi at Kendall SEQUENCE:0 STATUS:CONFIRMED SUMMARY:XOLPC gathering Cosi Sat Feb 7\, 2009 noon-2pm TRANSP:OPAQUE END:VEVENT END:VCALENDAR invite20090204T12.ics Description: application/ics ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Treatise on Formatting FLASH Storage Devices
da...@lang.hm wrote: On Wed, 4 Feb 2009, Mitch Bradley wrote: http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device Read it and weep. this completely ignores wear leveling, which is very nessasary for just about any filesystem, but especially for FAT (which appear to be the only filesystems this author is familiar with) all in all this doesn't seem like a very useful page. since i'm 99% sure that mitch wrote that page, let me be the first to disagree. :-) i believe that everything he's said is completely spot on. i confess i wasn't conscious of the partition vs. erase block alignment issue until a couple of months ago when i first heard mitch mention it, but i'm absolutely sure the effect is real. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
8.2.1 wireless testing results #2
Comparing staging-25 against 8.2-767, I have 2 more APs to play with: 1. D-Link DWL-7100AP Open and WEP work fine. I also confirmed that connection is automatically reestablished on reboot. WPA(TKIP): 8.2.0 connects every time. 8.2.1 always fails to connect, bringing up the password request dialog. Here are the NM logs, showing that association completes but it fails before DHCP (very likely during WPA handshake): NetworkManager: info Activation (eth0) New wireless user key for network '821testwpa' received. NetworkManager: info Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled... NetworkManager: info Activation (eth0) Stage 1 of 5 (Device Prepare) started... NetworkManager: info Activation (eth0) Stage 2 of 5 (Device Configure) scheduled... NetworkManager: info Activation (eth0) Stage 1 of 5 (Device Prepare) complete. NetworkManager: info Activation (eth0) Stage 2 of 5 (Device Configure) starting... NetworkManager: info Activation (eth0/wireless): access point '821testwpa' is encrypted, and a key exists. No new key needed. NetworkManager: info SUP: sending command 'INTERFACE_ADD eth0#011#011wext#011/var/run/wpa_supplicant#011' NetworkManager: info SUP: response was 'OK' NetworkManager: info SUP: sending command 'AP_SCAN 1' NetworkManager: info SUP: response was 'OK' NetworkManager: info SUP: sending command 'ADD_NETWORK' NetworkManager: info SUP: response was '0' NetworkManager: info SUP: sending command 'SET_NETWORK 0 ssid 38323174657374777061' NetworkManager: info SUP: response was 'OK' NetworkManager: info SUP: sending command 'SET_NETWORK 0 proto WPA' NetworkManager: info SUP: response was 'OK' NetworkManager: info SUP: sending command 'SET_NETWORK 0 key_mgmt WPA-PSK' NetworkManager: info SUP: response was 'OK' NetworkManager: info SUP: sending command 'SET_NETWORK 0 psk key' NetworkManager: info SUP: response was 'OK' NetworkManager: info SUP: sending command 'ENABLE_NETWORK 0' NetworkManager: info SUP: response was 'OK' NetworkManager: info Activation (eth0) Stage 2 of 5 (Device Configure) complete. avahi-daemon[1122]: Withdrawing address record for fe80::217:c4ff:fe3c:c8a1 on eth0. NetworkManager: info msh0: Got association; scheduling association handler NetworkManager: info msh0: got association event from driver. NetworkManager: info Activation (eth0/wireless): disconnected during association, asking for new key. I had limited success connecting by disabling NM, writing a wpa_supplicant config file, and connecting with wpa_supplicant spewing debug messages onto the console. WPA2: not supported by AP (wtf? not a cheap AP!!) 2. D-Link DWL-2100AP Open and WEP work fine. I also confirmed that connection is automatically reestablished on reboot. WPA: works fine on 8.2.0 Generally works the first time you try and connect on 8.2.1, but not after you disconnect and reconnect. On reboot, it also fails, bringing up the password input dialog. WPA2: works fine on 8.2.0 Also works well on 8.2.1. However, upon reboot, connection is not automatically reestablished. NM logs indicate the same bug that Hal Murray reported, which is a very strange one. It seems that association and handshake completes, but it receives no response to DHCP requests. Manually clicking on the AP icon soon after boot works around this problem. NM logs: NetworkManager: info Will activate connection 'eth0/dlinkwpa2'. NetworkManager: info Device eth0 activation scheduled... NetworkManager: info Activation (eth0) started... NetworkManager: info Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled... NetworkManager: info Activation (eth0) Stage 1 of 5 (Device Prepare) started... NetworkManager: info Activation (eth0) Stage 2 of 5 (Device Configure) scheduled... NetworkManager: info Activation (eth0) Stage 1 of 5 (Device Prepare) complete. NetworkManager: info Activation (eth0) Stage 2 of 5 (Device Configure) starting... NetworkManager: info Activation (eth0/wireless): access point 'dlinkwpa2' is encrypted, and a key exists. No new key needed. NetworkManager: info SUP: sending command 'INTERFACE_ADD eth0#011#011wext#011/var/run/wpa_supplicant#011' NetworkManager: info SUP: response was 'OK' NetworkManager: info SUP: sending command 'AP_SCAN 1' NetworkManager: info SUP: response was 'OK' NetworkManager: info SUP: sending command 'ADD_NETWORK' NetworkManager: info SUP: response was '0' NetworkManager: info SUP: sending command 'SET_NETWORK 0 ssid 646c696e6b77706132' NetworkManager: info SUP: response was 'OK' NetworkManager: info SUP: sending command 'SET_NETWORK 0 proto WPA2' NetworkManager: info SUP: response was 'OK' NetworkManager: info SUP: sending command 'SET_NETWORK 0 key_mgmt WPA-PSK' NetworkManager: info SUP: response was 'OK' NetworkManager: info SUP: sending command 'SET_NETWORK 0 psk key' NetworkManager: info SUP: response was 'OK' NetworkManager: info SUP: sending command 'ENABLE_NETWORK 0' NetworkManager: info SUP: response was 'OK' NetworkManager:
Re: Treatise on Formatting FLASH Storage Devices
On Wed, 4 Feb 2009, Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 da...@lang.hm wrote: On Wed, 4 Feb 2009, Mitch Bradley wrote: http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device Read it and weep. this completely ignores wear leveling, which is very nessasary for just about any filesystem, but especially for FAT (which appear to be the only filesystems this author is familiar with) Umm, what? To alleviate the wear out problems, the FTL must move data around so that repeated writes to a given sector don't cause too many writes to the same NAND page. Mitch is describing FLASH devices like SD cards. All such devices have a built-in microcontroller (the FTL) that performs wear-leveling. Layering additional wear-leveling filesystems like JFFS2 or UBIFS on top of the FTL requires a reverse translation (block device-MTD) and is not recommended. e.g. From http://www.linux-mtd.infradead.org/doc/ubifs.html : UBIFS was designed to work on top of raw flash, which has nothing to do with block devices. This is why UBIFS does not work on MMC cards and the like - they look like block devices to the outside world because they implement FTL (Flash Translation Layer) support in hardware, which simply speaking emulates a block device so if the device is performing wear leveling, then the fact that your FAT is on the same eraseblock as your partition table should not matter in the least, since the wear leveling will avoid stressing any particlar part of the flash. as such I see no point in worrying about the partition table being on the same eraseblock as a frequently written item. as for the block boundry not being an eraseblock boundry if the partition starts at block 1 if you use 1k blocks and have 256k eraseblocks, then 1 out of every 256 writes will generate two erases instead of one worst case is you use 4k blocks and have 128k eraseblocks, at which point 1 out of every 32 writes will generate two erases instead of one. to use the intel terminology, these result in write amplification factors of approximatly 1.005 and 1.03 respectivly. neither of these qualify as a 'flash killer' in my mind. now, if a FAT or superblock happens to span an eraseblock, then you will have a much more significant issue, but nothing that is said in this document refers to this problem (and in fact, it indicates that things like this follow the start of the partition very closely, which implies that unless the partition starts very close to the end of an eraseblock it's highly unlikely that these will span eraseblocks) so I still see this as crying wolf. as for ubifs, that is designed for when you have access to the raw flash, which is not the case for any device where you have a flash translation layer in place, so it is really only useful on embedded system, not on commercially available flash drives of any type. As for the author only being familiar with FAT, that is hilarious. Mitch implemented JFFS2 support in OFW, and wrote this page to explain how he produced optimal ext2 formatting of FTL FLASH. Indeed, that is the subject of http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device#Screwed-Up_Formatting I didn't read carefully enough before I made that comment. my apologies. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Testing] Notes from an impromptu 8.2.1 Release Mtg.
2009/1/31 Hal Murray hmur...@megapathdsl.net: Probably best to upload somewhere and put a link here. http://www.megapathdsl.net/~hmurray/tmp/messages.11 It also contains the info from when I poked my icon and it worked. That starts at 08:49. I inserted a few blank lines at that point to separate it from the booting stuff. Thanks. This is very odd -- it appears that association and WPA handshake completes, but it receives no response to DHCP. I have finally got my hands on some APs which work reliably with WPA/WPA2 and reproduced this bug. I posted my results in a new thread titled 8.2.1 wireless testing results #2 Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Treatise on Formatting FLASH Storage Devices
http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device Read it and weep. Mitch ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Treatise on Formatting FLASH Storage Devices
On Wed, 4 Feb 2009, da...@lang.hm wrote: On Wed, 4 Feb 2009, Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Umm, what? To alleviate the wear out problems, the FTL must move data around so that repeated writes to a given sector don't cause too many writes to the same NAND page. UBIFS was designed to work on top of raw flash, which has nothing to do with block devices. This is why UBIFS does not work on MMC cards and the like - they look like block devices to the outside world because they implement FTL (Flash Translation Layer) support in hardware, which simply speaking emulates a block device so if the device is performing wear leveling, then the fact that your FAT is on the same eraseblock as your partition table should not matter in the least, since the wear leveling will avoid stressing any particlar part of the flash. as such I see no point in worrying about the partition table being on the same eraseblock as a frequently written item. as for the block boundry not being an eraseblock boundry if the partition starts at block 1 if you use 1k blocks and have 256k eraseblocks, then 1 out of every 256 writes will generate two erases instead of one worst case is you use 4k blocks and have 128k eraseblocks, at which point 1 out of every 32 writes will generate two erases instead of one. to use the intel terminology, these result in write amplification factors of approximatly 1.005 and 1.03 respectivly. neither of these qualify as a 'flash killer' in my mind. now, if a FAT or superblock happens to span an eraseblock, then you will have a much more significant issue, but nothing that is said in this document refers to this problem (and in fact, it indicates that things like this follow the start of the partition very closely, which implies that unless the partition starts very close to the end of an eraseblock it's highly unlikely that these will span eraseblocks) so I still see this as crying wolf. A far more significant problem would be the use of a journal on flash. since there are generally two writes to the journal for every write to the storage (one write to put the data in the journal and one write to mark the journal entry as completed), and frequently each write to the journal gets pushed out immediatly (rather than waiting to consolodate writes) for safety, the journal gets _far_ more writes than anything else on the storage device. so using a full journaling filesystem (ext3 with data=journaled for example) would produce a write amplification factor of at least 3. David Lang as for ubifs, that is designed for when you have access to the raw flash, which is not the case for any device where you have a flash translation layer in place, so it is really only useful on embedded system, not on commercially available flash drives of any type. As for the author only being familiar with FAT, that is hilarious. Mitch implemented JFFS2 support in OFW, and wrote this page to explain how he produced optimal ext2 formatting of FTL FLASH. Indeed, that is the subject of http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device#Screwed-Up_Formatting I didn't read carefully enough before I made that comment. my apologies. David Lang ___ 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: Life in an insecure world
Daniel Drake wrote: 2009/2/4 John Watlington w...@laptop.org: I insist on b) in order to prevent inadvertent bricking of laptops by typing enable-security, Are you concerned that there is a realistic and common use case when a particular type of user would want or need to run enable-security? Yes, I was particularly thinking of you and your experience in Ethiopia and the difficulties you faced to re-secure the laptops. I prefer to think of it as: Is there a realistic and common use case for when a *deployment* would want or need to run enable-security. Regards, Reuben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Please update etoys in 8.2.1
Dear Release Manager, as we discussed on IRC today (and which I had not realized until today) the 8.2.1 release will be pre-installed on XOs for much longer than anticipated, since the 9.1 release has been canceled, and no replacement is in sight. We have had fixed Etoys / Squeak-VM packages ready for many months now, they just did not make it into 8.2 by a few days, and 8.2.1 was scheduled to be only a major-bugs fixing release, so we were holding out for 9.1. Since that is not going to happen we would very much appreciate if the updated RPMs would get included in 8.2.1. The most severe bugs that are fixed there are #8351 (Composite characters not displayed correctly), #8608 (Mic LED stays on after quitting Etoys), #8700 (View-source key broken) and #8536 (Page up / page down / home / end not working). More bugs have been fixed since, but no features added. We did update the major version number (4.0 now) in the mean time because the latest release is now completely license clean, but from a user's point of view the features are identical to the 3.0 series. The latest release is in Joyride: etoys-4.0.2205-2.noarch.rpm squeak-vm-3.10-3olpc11.i386.rpm Please consider these to replace the ones in 8.2. Thanks, - Bert, for the Etoys team - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
No ActivityTeam meeting this Friday
We didn't schedule one, but in case anyone thought there would be, there is no ActivityTeam meeting this Friday. I'm out of town this week, and I'm leaning towards bi-weekly anyway. I'll send out another email when we set the next time. Cheers, Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC upgrades
Regarding Gentoo, don't miss http://www.gentooxo.org/. That project combined with the Sugar overlay might be a good start for a tiny XO Sugar distribution. Wade On Tue, Feb 3, 2009 at 1:08 PM, Nirbheek Chauhan nirbheek.chau...@gmail.com wrote: On Wed, Feb 4, 2009 at 2:12 AM, S Page i...@skierpage.com wrote: Nirbheek Chauhan wrote: Since you're looking at making a gentoo-based sugar distro, you might find http://gitorious.org/projects/sugar-gentoo useful :) Please update http://sugarlabs.org/go/Community/Distributions/Gentoo , which lists a similar overlay project http://git.overlays.gentoo.org/gitweb/?p=proj/sugar.git by Aleksey Lim. Maybe you could mention differences or work together. I've talked with Aleksey, and _some_ code sharing is doable. However, the approach of the two overlays is completely perpendicular (automagic ebuilds using jhconvert vs manual ebuilds), and so one cannot replace the other. Also, my overlay currently consists of only live git ebuilds (ie, they fetch and install from git instead of releases), and release ebuilds are blocking on a number of things including http://dev.sugarlabs.org/ticket/120 . Once these problems are handled, I'll update the aforementioned page. -- Sent from my mobile device ... with its patented top-post and include the entire message thread with no changes so every reader must scroll through it to see if you made other comments UI 8-/ Yeah, it sucks. gmail for mobile doesn't show the rest of the thread, and top-posts without mercy _ -- ~Nirbheek Chauhan ___ 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: OLPC upgrades
On Wed, Feb 4, 2009 at 1:38 AM, Albert Cahalan acaha...@gmail.com wrote: Bobby Powers writes: 2009/2/2 Tiago Marques tiagomnm at gmail.com: Python is killing the XO, what's being done in that regard? The $100 laptop will always be hardware limited, how can python be a benefit and not a *huge* burden? I for one can't get my head around that. The idea is to give kids as much transparency into the software stack as possible, AND make it easy to hack on and easy to create new activities for. Python is much more forgiving than C. Python is less forgiving if you want performance on the XO. :-) For teaching, remember that Knuth uses assembly. C is an awful lot closer to that than Python, and isn't the XO about teaching? Ha, ahat age group is Knuth teaching assembly to?? What level of math and science skills are they expected to have? Its killing the XO? A personal pygtk based project launches in a few seconds on my debXO install on an XO, but much much longer on 8.2. It is a completely loaded statement to say that Python is killing the XO, and didn't really deserve a response :) I'm assuming that personal [...] project means small. The fact that you consider a few seconds to be acceptable shows just how much people have lost touch with the concept of performance. Python is not the problem. Just strace the activity startup process to see everything that goeson. A lot of it appears to be erelated to a) Rainbow b) Journal instance creation Also I agree that the huge animated loating icon is probably not helping on XO. Could'nt it be replaced by a large non-animated icon in the center of the screen, and then smoe dots that appear around the icon in a circle, adding one dot per second, like a clock? That would take no overhead and would even give an informal way to measure startup time by counting the dots. Current usage of Python can be mostly explained as follows: http://en.wikipedia.org/wiki/Sunk_cost_fallacy http://en.wikipedia.org/wiki/Sunk_cost http://en.wikipedia.org/wiki/Irrational_escalation http://en.wikipedia.org/wiki/Cognitive_bias http://en.wikipedia.org/wiki/Point_of_no_return http://en.wikipedia.org/wiki/Psychology_of_previous_investment http://en.wikipedia.org/wiki/Foot_in_the_door The remaining bit of the explanation is that the developer pool is now full of Python people. Nearly all others have run away. One can't expect to attract non-Python talent when Python gets a non-negotiable privileged position. Please don't try to hijack a technical discussion into a political one. Use of the Python language is not the cause of the performance problems on the XO or in Sugar in general. Every system must be optimized no matter what language it is written in. It just takes a little effort. Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Life in an insecure world
Is this really true ? If you've removed /versions, how does alt-boot find the other image ? On Feb 4, 2009, at 10:33 AM, C. Scott Ananian wrote: On Wed, Feb 4, 2009 at 12:22 AM, John Watlington w...@laptop.org wrote: Should we care ? I just proved that it is possible for any kid in Peru to slag their laptop by simply typing sudo rm -rf /* in a terminal window, a similar feat of child-like naivete. Alt-boot could recover from most cases like this -- although it will always be possible to do something similar. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Joyide on Fedora 11/rawhide
Hi All, I wanted to put it to the lists and get some feedback, with the plans on basing the 9.1.0 release on Fedora 11 I think we need to have a testing stream based on rawhide so that we can start testing core OS related bits and dealing with them sooner rather than later. My thoughts are that we should setup a new stream (joyhide/rawjoy/rawride?? ) at least initially which would give the OS people something to test and play with while giving Activity and sugar developers the option of either a more stable platform for developing and/or the bleading edge. With the F-11 alpha release out in the next couple of days rawhide should start (or maybe not) to stabilise so it might be a good time to start. Most of the major stuff that will affect OLPC (read python 2.6) is already in. There's a few other bits that will come but should have minimal impact. I'm quite happy to step up and sort out the build and poke repos and the like if people are happy to give me access to pilgrim and associated bits to get this moving. I have a reasonable amount of time next week that I can dedicate to getting this moving as well so I thought I'd poke now so as to get things moving if its decided to be a reasonable proposal. Thoughts? Cheers, Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyide on Fedora 11/rawhide
Hi Peter, I wanted to put it to the lists and get some feedback, with the plans on basing the 9.1.0 release on Fedora 11 I think we need to have a testing stream based on rawhide so that we can start testing core OS related bits and dealing with them sooner rather than later. Totally agreed. The reason I haven't pushed to set up nightly builds is that right now Rawhide *doesn't boot* on the XO. I think energy should probably be aimed at fixing that before we start setting up nightlies. I pinged Jeremy earlier in the week, he didn't have any strong ideas about what's wrong. I should retry with latest Rawhide in case something's been fixed recently.. Thanks! - Chris. -- Chris Ball c...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyide on Fedora 11/rawhide
Hi Chris, I wanted to put it to the lists and get some feedback, with the plans on basing the 9.1.0 release on Fedora 11 I think we need to have a testing stream based on rawhide so that we can start testing core OS related bits and dealing with them sooner rather than later. Totally agreed. The reason I haven't pushed to set up nightly builds is that right now Rawhide *doesn't boot* on the XO. I think energy should probably be aimed at fixing that before we start setting up nightlies. I pinged Jeremy earlier in the week, he didn't have any strong ideas about what's wrong. I should retry with latest Rawhide in case something's been fixed recently.. Oh! I wasn't aware of that as I don't currently have an XO to test (although that should be sorted soon) not that I know enough about the boot/kernel of the XO to be of much help fixing it. I wonder if any of the 50 odd people on fedora-devel that got an XO in the lead up to the F-10 release could help with that? Greg, do you know of someone that isn't as busy as Jeremy that could help shed some light on XO boot issues? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyide on Fedora 11/rawhide
Hi Jerry, I've been playing with booting fedora on the XO, mostly with anaconda (F9/F10) to be able to run an install on the XO itself for the XS. I'll try to boot the F11 kernel/installer when one is available, it looks like there are issues building anaconda atm, there is no isolinux directory on the mirrors... Perhaps someone could shed some light on the issues with rawhide that were uncovered thus far. Is there a tracker somewhere? F10 boots, but here's what happens when I try to boot Rawhide: http://dev.laptop.org/~cjb/f11-boot Thanks, - Chris. -- Chris Ball c...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Mesh support very likely to miss Sugar 0.84
In Sugar 0.84, will mesh at least be disabled, from the point of view of Ohm and the kernel, so that the WiFi chip can be powered down when it's not in use for WiFi? To me, one of the most attractive points about the OLPC is the capability to use it collaboratively far from civilization. This capability is customarily described as two kids under a tree. The language in the above quote implies that 'mesh' is disposable. With help from this list, I've been successful in using a (manually initiated) mesh between XOs running Joyride 2633. PLEASE do not take away my ability to do this !! My own long-term proposal for powering down the radio chip is to have *two* checkboxes in Control Panel - Network -- one for 'Mesh' and one for 'Wifi'. The user who wanted to power down the chip would uncheck both. [In the meantime, for powering down the chip, please document (or adapt the 'Radio checkbox' for) a bypass action such as 'echo 0 /sys/power/wlan-enabled'. Please don't disable mesh altogether.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Treatise on Formatting FLASH Storage Devices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mitch Bradley wrote: It has been my experience that USB sticks and SD cards with intact factory formatting tend to last longer and run faster than ones that have been reformatted with random layouts. This gives us Linux users a bit of a dilemma if we want to use FTL flash for primary storage. FAT does not provide the file access permissions, symlinks, hardlinks, or even case sensitivity, that we desire for most filesystems on unixy systems. However, FTL devices behave as a sort of FAT-oriented black box, full of secret proprietary firmware that loves FAT. One obvious proposal, therefore, would be to use FAT for storage, but wrap it with a layer that implements all our favorite POSIX stuff. This has been done before for Linux, in the guise of UMSDOS/UVFAT [1][2]. Although that work has fallen out of date, I suspect one could reimplement it quickly using new linux features such as FUSE. The question is: would such an approach be worthwhile? - --Ben [1] http://linux.voyager.hr/umsdos/ [2] http://en.wikipedia.org/wiki/UMSDOS -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmKBJ0ACgkQUJT6e6HFtqR8kwCfc9MlcbGv1yaSEog6lNJoqmey kE0AmwRxwXtORZSITzyDUW5gqu9xBpoq =Kxa1 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Treatise on Formatting FLASH Storage Devices
http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device Read it and weep. It's a great article, but people that aren't very familiar with filesystems and the filesystem tools are going to read the article, look at their tools, scratch their heads, decide the whole thing is too hard, and go on making the same mistakes. It would be useful if actual command arguments could be given for various sane defaults. Indeed, I'd like to do that as time permits. It's sort of an open-ended proposition though, because there are so many possibilities. Deciding where to draw the line is tricky. And for each example, to do it right, I'll have to write a mini-treatise on the pertinent assumptions and limitations. For me, the hard thing about writing is finding an appropriate stopping point - i.e. there is always more that could be said. So I tend to avoid starting, because I know that the task will grow to fill all available time and then some. For starters, I wanted to lay out the issues and the theory, so at least people start to realize that there is a possible problem. From what I've seen, most people are currently totally unaware of it. At least I did give one concrete recommendation - avoid reformatting if you can. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Server-devel] Cooking around ejabberd - Fwd: mod_ctrlextra, shared roster groups and more pubsub fun...
Just to keep people in the look as to what I'm working on... - using mod_ctlextra to control shared rosters from moodle enrol/unenrol hooks - testing ejabberd to 2.0.3 - which claims to fix some pubsub issues, and has the ssl/tls memory consumption bug fixed... -- martin -- Forwarded message -- From: Martin Langhoff martin.langh...@gmail.com Date: Wed, Feb 4, 2009 at 8:16 PM Subject: mod_ctrlextra, shared roster groups and more pubsub fun... To: ejabb...@jabber.ru ejabberd 2.0.1 plus mod_ctlextra (r814 from SVN). Playing around with 2 clients... $ ejabberdctl srg-create group1 localhost G1 G1 G1 $ ejabberdctl srg-user-add user1 localhost G1 localhost $ ejabberdctl srg-user-add user2 localhost G1 localhost at this point, user1 sees user2, but user2 cannot see user1. This is similar to the issues seen before with shared rosters and pubsub events. Do I need to patch mod_ctlextra? Retry with 2.0.2? 2.0.3? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: Joyide on Fedora 11/rawhide
On Wed, 2009-02-04 at 20:47 +0100, Peter Robinson wrote: Hi Chris, I wanted to put it to the lists and get some feedback, with the plans on basing the 9.1.0 release on Fedora 11 I think we need to have a testing stream based on rawhide so that we can start testing core OS related bits and dealing with them sooner rather than later. Totally agreed. The reason I haven't pushed to set up nightly builds is that right now Rawhide *doesn't boot* on the XO. I think energy should probably be aimed at fixing that before we start setting up nightlies. I pinged Jeremy earlier in the week, he didn't have any strong ideas about what's wrong. I should retry with latest Rawhide in case something's been fixed recently.. Oh! I wasn't aware of that as I don't currently have an XO to test (although that should be sorted soon) not that I know enough about the boot/kernel of the XO to be of much help fixing it. I wonder if any of the 50 odd people on fedora-devel that got an XO in the lead up to the F-10 release could help with that? Greg, do you know of someone that isn't as busy as Jeremy that could help shed some light on XO boot issues? Peter I've been playing with booting fedora on the XO, mostly with anaconda (F9/F10) to be able to run an install on the XO itself for the XS. I'll try to boot the F11 kernel/installer when one is available, it looks like there are issues building anaconda atm, there is no isolinux directory on the mirrors... Perhaps someone could shed some light on the issues with rawhide that were uncovered thus far. Is there a tracker somewhere? Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyide on Fedora 11/rawhide
On Wed, 2009-02-04 at 15:05 -0500, Chris Ball wrote: Hi Jerry, I've been playing with booting fedora on the XO, mostly with anaconda (F9/F10) to be able to run an install on the XO itself for the XS. I'll try to boot the F11 kernel/installer when one is available, it looks like there are issues building anaconda atm, there is no isolinux directory on the mirrors... Perhaps someone could shed some light on the issues with rawhide that were uncovered thus far. Is there a tracker somewhere? F10 boots, but here's what happens when I try to boot Rawhide: http://dev.laptop.org/~cjb/f11-boot Thanks, - Chris. kernel commandline: root=mtd0 rootfstype=jffs2 liveimg console=tty0 console=tty2 If your booting the live image shouldn't the root= line be something like: root=LABEL=device label... You could use the device name also: root=/dev/mtd0 Have a look at the mkliveinitrd part of mkinitrd at: http://git.fedoraproject.org/git/?p=mkinitrd;a=blob;f=mkliveinitrd;hb=24d6d9779ca5bacc0c649e9d783263661ceb81f0 Without the /dev part the init script will not have anything to match the root= against, in the case $root in part of the init file, resulting in the udev rules not getting created for the /dev/root symlink. Hoping that is the fix, Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyide on Fedora 11/rawhide
After a brief discussion with Jeremy, it appears that Fedora 11 in rawhide has had many boot issues on many platforms, and they're tackling them one by one. He promises to have a look at OLPC specifically on Friday. --g -- Got an XO that you're not using? Loan it to a needy developer! [[ http://wiki.laptop.org/go/XO_Exchange_Registry ]] On Wed, 4 Feb 2009, Jerry Vonau wrote: On Wed, 2009-02-04 at 20:47 +0100, Peter Robinson wrote: Hi Chris, I wanted to put it to the lists and get some feedback, with the plans on basing the 9.1.0 release on Fedora 11 I think we need to have a testing stream based on rawhide so that we can start testing core OS related bits and dealing with them sooner rather than later. Totally agreed. The reason I haven't pushed to set up nightly builds is that right now Rawhide *doesn't boot* on the XO. I think energy should probably be aimed at fixing that before we start setting up nightlies. I pinged Jeremy earlier in the week, he didn't have any strong ideas about what's wrong. I should retry with latest Rawhide in case something's been fixed recently.. Oh! I wasn't aware of that as I don't currently have an XO to test (although that should be sorted soon) not that I know enough about the boot/kernel of the XO to be of much help fixing it. I wonder if any of the 50 odd people on fedora-devel that got an XO in the lead up to the F-10 release could help with that? Greg, do you know of someone that isn't as busy as Jeremy that could help shed some light on XO boot issues? Peter I've been playing with booting fedora on the XO, mostly with anaconda (F9/F10) to be able to run an install on the XO itself for the XS. I'll try to boot the F11 kernel/installer when one is available, it looks like there are issues building anaconda atm, there is no isolinux directory on the mirrors... Perhaps someone could shed some light on the issues with rawhide that were uncovered thus far. Is there a tracker somewhere? Jerry ___ 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: Treatise on Formatting FLASH Storage Devices
Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mitch Bradley wrote: It has been my experience that USB sticks and SD cards with intact factory formatting tend to last longer and run faster than ones that have been reformatted with random layouts. This gives us Linux users a bit of a dilemma if we want to use FTL flash for primary storage. FAT does not provide the file access permissions, symlinks, hardlinks, or even case sensitivity, that we desire for most filesystems on unixy systems. However, FTL devices behave as a sort of FAT-oriented black box, full of secret proprietary firmware that loves FAT. I think that FTLs are getting better over time, so maybe the FAT-specific optimizations are starting to be replaced by more generic algorithms. The rapidly growing market for FLASH-based storage is certainly attracting lots of development dollars. In the absence of FAT-specific optimizations, perhaps properly-aligned ext2 layouts will work well. Another solution is to choose high-quality devices. I've had good results with some models from SanDisk and Transcend. But sometimes it comes at a cost penalty - the really good SanDisk Extreme III SD cards cost 2.5x the going rate for commodity cards of the same capacity. The good cards appear to be rather more tolerant of abuse than the El Cheapo's. But even with the tough ones, I think its prudent to treat them gently. One obvious proposal, therefore, would be to use FAT for storage, but wrap it with a layer that implements all our favorite POSIX stuff. Puppy Linux does something like that, using a (FAT, ISO9660, or whatever) file as a container for an ext2 filesystem image. The practice is also rather common in the world of virtualization. My primary Linux system is actually a colinux vm running under Windows with the ext2 filesystem image inside an NTFS file (actually three files, one for root, one for home, and one for miscellaneous big wads of client-specific stuff) . That's proven itself very convenient over time; I've transported and mixed-and-matched those filesystem images to several different host machines. Based on that and other pleasant experiences with VM filesystem snapshots, I'm of the opinion that a quiet revolution is brewing in the way that people deal with filesystems inside files. You could treat an existing FAT filesystem as a very flexible partitioning scheme. You can make any number of partitions, of any size, with a hierarchical namespace, with a good collection of tools for manipulating them. This has been done before for Linux, in the guise of UMSDOS/UVFAT [1][2]. Although that work has fallen out of date, I suspect one could reimplement it quickly using new linux features such as FUSE. The question is: would such an approach be worthwhile? I think that the wrapped-metadata approach has largely run its course. There used to be a lot of activity in that area, but I haven't seen much of interest lately. I think that containerization is likely to be the happening thing for the near term. - --Ben [1] http://linux.voyager.hr/umsdos/ [2] http://en.wikipedia.org/wiki/UMSDOS -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmKBJ0ACgkQUJT6e6HFtqR8kwCfc9MlcbGv1yaSEog6lNJoqmey kE0AmwRxwXtORZSITzyDUW5gqu9xBpoq =Kxa1 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Server-devel] Network addressing for activation-over-IBSS
Hi,
I have modified the XO activation initramfs to attempt to locate a
lease server on an XS on each open infrastructure network that can be
found (early patch attached).
The XS does not bind the server to the IPv6 address correctly (perhaps
we can work on that)., so it currently runs over IPv4
But assuming we want a working IPv4 implementation... we need to
figure out a way of getting the XOs to address themselves in a way
compatible with the school server. The current IPv4 code picks an
address (randomly) at 172.18.16.xx and this does not work with the XS.
I also am quite confused by the XS network interface setting.
We need to choose an appropriate address range which the XOs can
suitably randomly assign themselves in, not covered by DHCP leases,
and make sure that an appropriate interface is listening (at least
acting as a gateway) on the XS. At the moment I am using 172.18.1.x
which seems to be free of dhcp assignments.
Thoughts?
Daniel
From: Daniel Drake d...@laptop.org
diff --git a/src-olpc/activate.py b/src-olpc/activate.py
index f21b30d..f9b27e7 100644
--- a/src-olpc/activate.py
+++ b/src-olpc/activate.py
@@ -6,10 +6,14 @@ from initutil import blk_mounted, SD_DEV, SD_MNT, USB_DEV, USB_MNT
from initutil import sd_init, usb_init, net_init
from socket import *
from ipv6util import if_nametoindex
+import subprocess
from subprocess import check_call, call
sys.path += [ '/act-gui' ] # gui_client is in a subdir
from gui_client import send
+#def send(foo):
+#print would send:, foo
+
def try_blk(device, mnt, fstype='msdos'):
Try to mount a block device and read keylist from it.
try:
@@ -19,25 +23,60 @@ def try_blk(device, mnt, fstype='msdos'):
except:
return None
-def select_network_channel (channel):
-check_call(['/sbin/iwconfig','eth0','mode','ad-hoc','essid','dontcare'])
-check_call(['/sbin/iwconfig','msh0','channel',str(channel)])
-check_call(['/bin/ip','link','set','dev','msh0','up']) # rely on ipv6 autoconfig
+def set_addresses (iface):
# set up link-local address
-mac = open('/sys/class/net/msh0/address').read().strip().split(':')
+mac = open('/sys/class/net/%s/address' % iface).read().strip().split(':')
top = int(mac[0], 16) ^ 2 # universal/local bit complemented
ll = 'fe80::%02x%s:%sff:fe%s:%s%s' % \
(top, mac[1], mac[2], mac[3], mac[4], mac[5])
-call(['/bin/ip', 'addr', 'add', '%s/64' % ll, 'dev', 'msh0'])
+call(['/bin/ip', 'addr', 'add', '%s/64' % ll, 'dev', iface])
a = 2+(ord(os.urandom(1)[0])%250)
-call(['/bin/ip', 'addr', 'add', '172.18.16.%d' % a, 'dev', 'msh0'])
+call(['/bin/ip', 'addr', 'add', '172.18.1.%d/24' % a,
+ 'brd', '172.18.1.255', 'dev', iface])
# XXX: BSSIDs of all 0, F, or 4 are invalid
-# set up route to 172.18.0.1
-call(['/bin/ip', 'route', 'add', '172.18.0.0/23', 'dev', 'msh0'])
-call(['/bin/ip', 'route', 'add', 'default', 'via', '172.18.0.1'])
+call(['/bin/ip', 'route', 'add', 'default', 'via', '172.18.1.1', 'dev', iface])
# should be able to ping 172.18.0.1 after this point.
# the IPv4 address is a little hacky, prefer ipv6
+def select_mesh_channel (channel):
+check_call(['/sbin/iwconfig','eth0','mode','ad-hoc','essid','dontcare'])
+check_call(['/sbin/iwconfig','msh0','channel',str(channel)])
+check_call(['/bin/ip','link','set','dev','msh0','up']) # rely on ipv6 autoconfig
+set_addresses('msh0')
+
+def select_ibss (ssid):
+print attempting connection to open IBSS, ssid
+check_call(['/bin/ip','link','set','dev','eth0','up']) # rely on ipv6 autoconfig
+check_call(['/sbin/iwconfig','eth0','mode','managed','essid',ssid])
+
+# wait for association, max 5 secs
+for i in range(0, 10):
+time.sleep(0.5)
+output = subprocess.Popen([/sbin/iwconfig, eth0],
+ stdout=subprocess.PIPE).communicate()[0]
+lines = output.split(\n)
+if len(lines) 2:
+print bad iwconfig output?
+return False
+
+ssidpos = lines[0].index(ESSID:)
+iw_ssid = lines[0][ssidpos + 6:].strip()
+if iw_ssid != '' + ssid + '':
+if iw_ssid != '':
+print unexpected ESSID value:, iw_ssid
+continue
+
+appos = lines[1].find(Access Point: )
+if appos == -1:
+continue
+iw_ap = lines[1][appos+14:].strip()
+if iw_ap[0].isdigit():
+print connected!
+set_addresses(eth0)
+return True
+
+return False
+
def try_to_get_lease(family, addr, serial_num):
s = socket(family, SOCK_STREAM)
try:
@@ -55,23 +94,87 @@ def try_to_get_lease(family, addr, serial_num):
finally:
s.close()
-def try_network (channel, serial_num):
+def contact_lease_server (iface, serial_num):
+# try to contact the lease server
+for family, addr in [ (AF_INET6,('fe80::abcd:ef01',191,
+
Re: Joyide on Fedora 11/rawhide
Hi Greg, Thanks for poking :) After a brief discussion with Jeremy, it appears that Fedora 11 in rawhide has had many boot issues on many platforms, and they're tackling them one by one. He promises to have a look at OLPC specifically on Friday. Excellent news. In the mean time, even with boot issues, there's nothing wrong with getting a rawhide based stream in progress so that various other issues that will undoubtedly show up so that when the boot problem is fixed we're already on the ground and can start running. After all there will no doubt be other deps and composing issues that need to be resolved. too. Either way, ping me on or off list for any heavy lifting I can help with. Cheers, Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyide on Fedora 11/rawhide
On Wed, 4 Feb 2009, Peter Robinson wrote: Hi Greg, Thanks for poking :) After a brief discussion with Jeremy, it appears that Fedora 11 in rawhide has had many boot issues on many platforms, and they're tackling them one by one. He promises to have a look at OLPC specifically on Friday. Excellent news. In the mean time, even with boot issues, there's nothing wrong with getting a rawhide based stream in progress so that various other issues that will undoubtedly show up so that when the boot problem is fixed we're already on the ground and can start running. After all there will no doubt be other deps and composing issues that need to be resolved. too. Either way, ping me on or off list for any heavy lifting I can help with. cjb, it was my understanding that you were already essentially doing nightly builds from rawhide using livecd-tools. Am I mistaken? --g -- Got an XO that you're not using? Loan it to a needy developer! [[ http://wiki.laptop.org/go/XO_Exchange_Registry ]] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyide on Fedora 11/rawhide
2009/2/4 Chris Ball c...@laptop.org: Hi Jerry, I've been playing with booting fedora on the XO, mostly with anaconda (F9/F10) to be able to run an install on the XO itself for the XS. I'll try to boot the F11 kernel/installer when one is available, it looks like there are issues building anaconda atm, there is no isolinux directory on the mirrors... Perhaps someone could shed some light on the issues with rawhide that were uncovered thus far. Is there a tracker somewhere? F10 boots, but here's what happens when I try to boot Rawhide: http://dev.laptop.org/~cjb/f11-boot This is Fedora's initramfs, right? Peter's suggestion is to use pilgrim to create rawhide builds, hence using the olpc initramfs. If we are still facing problems beyond Friday, this may be a good thing to do in the interim. Peter does not have an XO (g...@contrib program extreme slowness!) but may be able to help on other issues that surface as the result of an available public build... Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Mesh support very likely to miss Sugar 0.84
Hi All, I've never used the mesh before so I'm not 100% on how it works... In Sugar 0.84, will mesh at least be disabled, from the point of view of Ohm and the kernel, so that the WiFi chip can be powered down when it's not in use for WiFi? To me, one of the most attractive points about the OLPC is the capability to use it collaboratively far from civilization. This capability is customarily described as two kids under a tree. I'm not sure completely sure about deployments but how much are they actually used? Two kids under a tree don't technically need a mesh to collaborate (as cool as it sounds). The language in the above quote implies that 'mesh' is disposable. With help from this list, I've been successful in using a (manually initiated) mesh between XOs running Joyride 2633. PLEASE do not take away my ability to do this !! I'm not sure about mesh as such but I wonder how much the mesh is actually used in large deployments (I believe in at least one large deployment the network function was essentially nor used)or deployments generally but on the other side of things Fedora 10 and the associated NetworkMager 0.7 on which the non kernel side of OLPC networking is based supports also by default the sharing of wifi. If there's issues with mesh would is be possible to add a sharte my network checkbox which automagically uses the network sharing options included in NM 0.7 to allow Two kids under a tree to collaborate without the mesh (unless they're both looking over the shoulders of each other anyway :-) My own long-term proposal for powering down the radio chip is to have *two* checkboxes in Control Panel - Network -- one for 'Mesh' and one for 'Wifi'. The user who wanted to power down the chip would uncheck both. My thoughts would be to have this a whole lot automated as why would/should some random kid care about what wifi and mesh mean. Surely it would be better to have almost a learning style system (In the last 10 times I'm been powered up I've never seen a mesh network so I'll power down the mesh until the next time I reboot/powerup and will rescan. If I don;t find one then I'll just turn off. Rescan on restart and then turn off. If a mesh is there don't power off and join in. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyide on Fedora 11/rawhide
Hi Greg, cjb, it was my understanding that you were already essentially doing nightly builds from rawhide using livecd-tools. Am I mistaken? I was doing manual builds from rawhide using livecd-tools, trying to get them to boot. Haven't got around to nightly yet, since it didn't seem like there was much point when they aren't booting. - Chris. -- Chris Ball c...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyide on Fedora 11/rawhide
On Wed, 4 Feb 2009, Chris Ball wrote: Hi Greg, cjb, it was my understanding that you were already essentially doing nightly builds from rawhide using livecd-tools. Am I mistaken? I was doing manual builds from rawhide using livecd-tools, trying to get them to boot. Haven't got around to nightly yet, since it didn't seem like there was much point when they aren't booting. Which is still true, apparently, so there you are. Although nightlies may be required at some point -- perhaps this process is what Peter is volunteering to help get off the ground? --g -- Got an XO that you're not using? Loan it to a needy developer! [[ http://wiki.laptop.org/go/XO_Exchange_Registry ]] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC upgrades
On Wednesday 04 February 2009 17:58:24 Albert Cahalan wrote: Assembly has a reputation for being hard, but this is far from the truth. It is large assembly projects that are hard to understand. For tiny things, assembly is even easier than C. What you see is what you get, exactly. Python has lots of magic. With assembly, everything is there for you to see. Using assembly is the worst idea for a non hardware related open source project, besides the fact that the x86 architecture is awful, programming in assembly will lock the software to that architecture, meaning that you would have to forget about porting to ARM or MIPS. Also, in these days C compilers are very good, they can even sometimes generate better code than some experienced assemly programmers, thus performance reasons are no longer valid. Rewriting everything done to assembly would take ages, and you'd need to rewrite everything again if you change the architecture. If you understand me, you should propose C instead. PS: Sorry for my english. Regards, -- Francisco Castro signature.asc Description: This is a digitally signed message part. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Gitorious still hanging up on me
I tried to do a git push to gitorious this morning and it failed without even trying to ask for my passphrase. I'm going to try it tonight using the box I originally migrated to gitorious with and see if that works any better, but I believe I created the public keys the same way on both and they look similar when I view them in my user profile, so I have to wonder if there is a problem on the server side and if anyone is trying to resolve it. Thanks, James Simmons ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Assembly vs. Python
I've been amused reading these comments about Knuth and Assembler vs. Python. Back in 1978 at Western Illinois University I encountered Knuth's books in the school library. He not only used Assembly in his examples, he used a made up version of Assembly language for a machine that did not exist. He said that most programmers end up learning more than one kind of assembly language, so learning one more was no big deal. Even in 1978 that sounded questionable! I did study BAL at WIU. The first class I took I barely passed with a D. The teacher had no clue how to teach BAL, but fortunately the textbook was good enough to learn from without him. I decided that D or no D I did understand BAL, so I went on to learn COBOL and I took another BAL course after that where I got a B. I've written a fair amount of BAL professionally. I've also done Turbo C, COBOL, Java, and other languages. I only learned Python for OLPC, although I was exposed to it when I configured Freevo. I like the language well enough and performance hasn't been much of an issue for me. It's comparable to Java, probably better for most things. It is certainly more understandable for complex apps than COBOL or BAL ever were, and I think its a decent language for a new programmer, especially one who is not interested in programming as a career but just has a problem he needs to solve. Maybe he's studying trigonometry or linear programming or statistics and he needs to crunch some numbers to understand things better. Why not write a Python program? If blinding speed on the XO was all that mattered we'd still be using Turbo C on top of MS-DOS. We'd be bypassing the BIOS and moving data directly to video memory. We'd write TSR programs to get some of the benefits of multitasking without the overhead of a multitasking OS. We'd have to know the difference between expanded and extended memory. I have done all of those things, but I wouldn't wish them on anyone else. At Walgreens many years ago we had a batch program in BAL that took 4 hours to run because it used its own swap file. I modified this program using a COBOL subprogram to replace the swap file with arrays in memory. The finished program took 10 minutes to run after that. Would it have run faster still if I used BAL for the subprogram? Not much, but it would have been *much* harder to write. The program was slow because it spent so much time waiting for disk reads and writes, not because it was running unnecessary machine instructions. All programs wait at the same speed. I would agree that whatever performance issues there are on the XO, we probably can't blame too many of them on Python. James Simmons For teaching, remember that Knuth uses assembly. C is an awful lot closer to that than Python, and isn't the XO about teaching? Ha, ahat age group is Knuth teaching assembly to?? What level of math and science skills are they expected to have? Assuming we start with no programming skills... Assembly has a reputation for being hard, but this is far from the truth. It is large assembly projects that are hard to understand. For tiny things, assembly is even easier than C. What you see is what you get, exactly. Python has lots of magic. With assembly, everything is there for you to see. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Treatise on Formatting FLASH Storage Devices
On Wed, Feb 4, 2009 at 4:11 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: This gives us Linux users a bit of a dilemma if we want to use FTL flash for primary storage. FAT does not provide the file access permissions, symlinks, hardlinks, or even case sensitivity, that we desire for most filesystems on unixy systems. However, FTL devices behave as a sort of FAT-oriented black box, full of secret proprietary firmware that loves FAT. One obvious proposal, therefore, would be to use FAT for storage, but wrap it with a layer that implements all our favorite POSIX stuff. What about a small script that could do two things: - determine and dump the factory partitioning data from a device (by looking at how the FAT filesystem is laid out) to a file (perhaps we could build up a database for popular FLASH devices, like the SanDisk Ultra III's?) - take the factory partitioning data from a device (or dump file) and create a new partition map and well behaved ext2/3/4/whatever file system on the device I'm quite new to this wide world of filesystems and block devices, so let me know if there are clear or obvious reasons this can't be done, or why it would be harder than it sounds. Bobby ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Network addressing for activation-over-IBSS
The XS does not bind the server to the IPv6 address correctly (perhaps we can work on that)., so it currently runs over IPv4 True - the XS runs an IPv4 infra. IPv6 offers link-level addresses that don't require any infrastructure, not even a DHCP server. If you make both ends work with IPv6 then you don't have to worry about assigning addresses at all. And you can send a UDP query to an IPv6 link-level multicast address, so you don't need to know the school server's address. It can respond via unicast to your link-level address. Many nodes who want to offer leases can listen on that multicast address (the only one that should respond is one who has a lease to offer this client). (It doesn't appear to work to use IPv4 link-local addresses in this application, because one is not always assigned; while in IPv6, whenever your interface comes up, a link-local address is rapidly assigned to it.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Treatise on Formatting FLASH Storage Devices
On Wed, Feb 04, 2009 at 07:51:44PM -0500, Bobby Powers wrote: What about a small script that could do two things: Sounds great. -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyide on Fedora 11/rawhide
On Wed, Feb 04, 2009 at 05:53:14PM -0500, Chris Ball wrote: Hi, This is Fedora's initramfs, right? Right. Peter's suggestion is to use pilgrim to create rawhide builds, hence using the olpc initramfs. That's an interesting idea. I don't like it long-term, because no-one's working on pilgrim or our initramfs, but it could help us get moving. Two small corrections: a) the initramfs continues happily under active volunteer development -- it received two new features and a bugfix contributed by a deployment support volunteer (dsd) in the last two weeks, along with patch review and volunteer testing by folks back here in the States. b) While pilgrim may be a dead-end, the ideas underlying it are not. This week, I translated pilgrim's ideas into the simplest form yet achieved, namely, a plain old Makefile: http://dev.laptop.org/git?p=users/mstone/puritan;a=tree;hb=make and used it to produce builds from the olpc4+joyride tree and the rawhide+olpc4+joyride tree (with minor edits). The former booted happily into Sugar and built on both Debian and Fedora. :) (The latter, still using the olpc initramfs, dies because upstart 0.5 still doesn't know how to run as non-pid-1. olpc4's upstart-0.3.9 has a patch which implements this feature.) Peter does not have an XO (g...@contrib program extreme slowness!) but may be able to help on other issues that surface as the result of an available public build... Oh, let's fix that. Ed, SJ, could one of you take care of sending Peter some XOs ASAP, please? Good idea. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Network addressing for activation-over-IBSS
On Thu, 5 Feb 2009, Martin Langhoff wrote: 2009/2/5 Daniel Drake d...@laptop.org: I have modified the XO activation initramfs to attempt to locate a lease server on an XS on each open infrastructure network that can be found (early patch attached). Great -- I am not too conversant on the initrd code, probably makes sense to repost it to devel@ where cscott and mstone lurk... I can possibly help too w.r.t. the OLPC initramfs, I have hacked it up to the point of not needing it but I have a general idea how it works. If you need to make simple modifications, Google Building Initramfsen for a simple guide. -Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] mod_ctrlextra, shared roster groups and more pubsub fun...
On Wed, Feb 4, 2009 at 8:16 PM, Martin Langhoff martin.langh...@gmail.com wrote: Do I need to patch mod_ctlextra? Retry with 2.0.2? 2.0.3? Getting the same behaviour on v2.0.3. Any hints? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Network addressing for activation-over-IBSS
On Thu, Feb 5, 2009 at 3:13 PM, Wade Brainerd r...@wadeb.com wrote: I can possibly help too w.r.t. the OLPC initramfs, I have hacked it up to the point of not needing it but I have a general idea how it works. dsd is proposing a patch. Might merit review :-) http://lists.laptop.org/pipermail/server-devel/2009-February/002823.html If you need to make simple modifications, Google Building Initramfsen for a simple guide. Yes, I've been through that once :-/ m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: OLPC upgrades
On Feb 4, 2009, at 12:47 AM, Bobby Powers wrote: On Tue, Feb 3, 2009 at 7:55 PM, da...@lang.hm wrote: On Wed, 4 Feb 2009, Martin Langhoff wrote: On Wed, Feb 4, 2009 at 1:03 PM, da...@lang.hm wrote: Ok, what tools can I use to satisfy you of this 'opinion' that applications start faster on either KDE or GNOME than on Sugar on the same hardware. by the way, you are the first person I have heard dispute this. Erik has done a few things lately that made me change perspective. Most comparisons have been made against stuff running off the SD- card, and made our Sugar/Fedora look very slow in comparison. Everyone jumped on Python/Sugar. However, our NAND is *slow*, it busy-waits, JFFS2 is slow, and Linux under a bit of mem pressure (and having no swap) starts discarding pages, assuming that disk reads are reasonably fast and non-cpu-blocking. But reading pages from the NAND turns out to be slow and most importantly it pegs the CPU hard. Get the debxo or the vanilla fedoras running on the NAND. The performance delta is not what we thought it would be. I know that debxo will install on the NAND. I haven't done so on my systems yet as I wanted to leave the NAND intact to test the official builds. I'll go ahead and do this on one of my boxes. most of my testing has been via USB, do you have any idea how it compares performance wise to the NAND and SD card? SD USB NAND is there any ability to not use JFFS2 on the NAND? I believe UBIFS is the up and coming JFFS2 killer: http://www.linux-mtd.infradead.org/doc/ubifs_whitepaper.pdf I don't know the status of it tho, I believe there was some testing at 1CC recently with mixed results. Testing of UBIFS at 1CC ran into a bug which was patched and has now been running for months without problems. See: http://wiki.laptop.org/go/UBIFS_on_XO Cheers, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: x11vnc and vncviewer for classroom
On Tue, Nov 25, 2008 at 12:39 PM, Anna ascho...@gmail.com wrote: Another option to accomplish this is to stream the screen of the Ubuntu machine as ogg and then the XOs can simply play the stream via totem. The src of the video is a conventional ubuntu machine - - how powerful is the source machine? - how do you grab the screen? - what bandwidth does the stream take? Setting things up so this is easy to do is something I hope to get to at some point -- cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Treatise on Formatting FLASH Storage Devices
On Wed, 4 Feb 2009, Mitch Bradley wrote: da...@lang.hm wrote: so if the device is performing wear leveling, then the fact that your FAT is on the same eraseblock as your partition table should not matter in the least, since the wear leveling will avoid stressing any particlar part of the flash. That would be true in a perfect world, but wear leveling is hard to do perfectly. Relocating requires maintaining two copies of the erase block, as well as hidden metadata that tells you which copy is which, plus a hidden allocation map. Updating all of these things in a way that avoids catastrophic loss of the entire device (due to inconsistent metadata) is tricky. Some FTLs get it (at least mostly) right, many don't. FTL software is, after all, software, so obscure bugs are always possible. Making hardware behave stably during power loss is triply difficult. so it sounds like you are basicly saying that if the FAT/Superblock gets corrupted due to a bug in the FTL software it's easier to recover than if the FAT gets corrupted, so isolating the two is a benifit. is this a fair reading? I will note that even if you never write to the partition table, that eraseblock will migrate around the media (the fact that it's never written to make it a good candidate to swap with a high-useage block. it will move less, but it will still move. I suspect, based on cryptic hints in various specs and standards that I've read, that some FTLs have special optimizations for FAT filesystems with the factory-supplied layout. If the FAT is in a known nice location, you can apply different caching and wear leveling policies to that known hot-spot, this makes sense and perhaps even reduce the overall metadata by using the FAT as part of the block-substitution metadata for the data area. this I don't understand. Many manufacturers could care less about what Linux hackers want to do - their market being ordinary users who stick the device in a camera - so such cheat optimizations are fair game from a business standpoint. this is definantly true as such I see no point in worrying about the partition table being on the same eraseblock as a frequently written item. Many filesystem layouts can recover from damage to the allocation maps, either automatically or with an offline tool. It's possible to rebuild ext2 allocation bitmaps from inode and directory information. For FAT filesystems, there's a backup FAT copy that will at least let you roll back to a semi-consistent recent state. But there's no redundant for the partition map or the BPB. If you should lose one of those during a botched write, it's bye-bye to all your data, barring mad forensic skills. I've recovered from partition table mistakes in the past, it's not that hard (and in the cases like flash where the media is small enough that there is usually only one partition it becomes as close to trivial as such things can be) In stress testing of some LBA NAND devices, we saw several cases where, after a fairly long period, the devices completely locked up and lost the ability to read or rewrite the first block. I had done a bad job of partitioning it, because I wasn't paying enough attention when I created the test image. It's unclear what the results would have been had the layout been better - the stress test takes several weeks and the failures are statistical in nature - but I can't help believing that, for a device with a known wear-out mechanism and elaborate workarounds to hide that fact, working it harder than necessary will reduce its lifetime and possibly trigger microcode bugs that might otherwise cause no trouble. interesting datapoint, but not something that I would call conclusive (especially when some of the elaborate workarounds you are referring to are speculation, not documented) as for the block boundry not being an eraseblock boundry if the partition starts at block 1 if you use 1k blocks and have 256k eraseblocks, then 1 out of every 256 writes will generate two erases instead of one worst case is you use 4k blocks and have 128k eraseblocks, at which point 1 out of every 32 writes will generate two erases instead of one. to use the intel terminology, these result in write amplification factors of approximatly 1.005 and 1.03 respectivly. neither of these qualify as a 'flash killer' in my mind. The main amplification comes not from the erases, but from the writes. If the cluster/block space begins in the middle of FLASH page, then 1-block write will involve a read-modify-write of two adjacent pages. That is four internal accesses instead of one. Each such access takes between 100 and 200 uS, depending on the degree to which you can pipeline the accesses - and read-modify-write is hard to pipeline. So the back-end throughput can easily be reduced by a factor of 4 or even more. The write-amplification factor is 2
Re: Treatise on Formatting FLASH Storage Devices
On Wed, 4 Feb 2009, Bobby Powers wrote: On Wed, Feb 4, 2009 at 4:11 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: This gives us Linux users a bit of a dilemma if we want to use FTL flash for primary storage. FAT does not provide the file access permissions, symlinks, hardlinks, or even case sensitivity, that we desire for most filesystems on unixy systems. However, FTL devices behave as a sort of FAT-oriented black box, full of secret proprietary firmware that loves FAT. One obvious proposal, therefore, would be to use FAT for storage, but wrap it with a layer that implements all our favorite POSIX stuff. What about a small script that could do two things: - determine and dump the factory partitioning data from a device (by looking at how the FAT filesystem is laid out) to a file (perhaps we could build up a database for popular FLASH devices, like the SanDisk Ultra III's?) - take the factory partitioning data from a device (or dump file) and create a new partition map and well behaved ext2/3/4/whatever file system on the device all you need to do is to not change the partition table, do a mkfs on the existing partiton and then use tar or cp to put files there. no need to involve dump files. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Treatise on Formatting FLASH Storage Devices
On Wed, 4 Feb 2009, Mitch Bradley wrote: Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mitch Bradley wrote: It has been my experience that USB sticks and SD cards with intact factory formatting tend to last longer and run faster than ones that have been reformatted with random layouts. This gives us Linux users a bit of a dilemma if we want to use FTL flash for primary storage. FAT does not provide the file access permissions, symlinks, hardlinks, or even case sensitivity, that we desire for most filesystems on unixy systems. However, FTL devices behave as a sort of FAT-oriented black box, full of secret proprietary firmware that loves FAT. I think that FTLs are getting better over time, so maybe the FAT-specific optimizations are starting to be replaced by more generic algorithms. The rapidly growing market for FLASH-based storage is certainly attracting lots of development dollars. In the absence of FAT-specific optimizations, perhaps properly-aligned ext2 layouts will work well. Another solution is to choose high-quality devices. I've had good results with some models from SanDisk and Transcend. But sometimes it comes at a cost penalty - the really good SanDisk Extreme III SD cards cost 2.5x the going rate for commodity cards of the same capacity. The good cards appear to be rather more tolerant of abuse than the El Cheapo's. But even with the tough ones, I think its prudent to treat them gently. the small devices are cheap enough, I'll bet a lot of people would be willing to chip in a few bucks if someone were to orginize a controlled test (or possibly one of the hardware websites can be prodded into doing a long enough and large enough test to have some valid statistics) One obvious proposal, therefore, would be to use FAT for storage, but wrap it with a layer that implements all our favorite POSIX stuff. the problem with this is that your access won't follow the FAT pattern anymore, it will follow the pattern of the higher-level filesystem. also, most setups like this that I have seen concentrate the 'extra' metadata for read efficiancy, but that's exactly the wrong thing to do for flash. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyide on Fedora 11/rawhide
On Wed, Feb 4, 2009 at 8:50 PM, Michael Stone mich...@laptop.org wrote: On Wed, Feb 04, 2009 at 05:53:14PM -0500, Chris Ball wrote: Hi, This is Fedora's initramfs, right? Right. Peter's suggestion is to use pilgrim to create rawhide builds, hence using the olpc initramfs. That's an interesting idea. I don't like it long-term, because no-one's working on pilgrim or our initramfs, but it could help us get moving. Two small corrections: a) the initramfs continues happily under active volunteer development -- it received two new features and a bugfix contributed by a deployment support volunteer (dsd) in the last two weeks, along with patch review and volunteer testing by folks back here in the States. b) While pilgrim may be a dead-end, the ideas underlying it are not. This week, I translated pilgrim's ideas into the simplest form yet achieved, namely, a plain old Makefile: http://dev.laptop.org/git?p=users/mstone/puritan;a=tree;hb=make and used it to produce builds from the olpc4+joyride tree and the rawhide+olpc4+joyride tree (with minor edits). The former booted happily into Sugar and built on both Debian and Fedora. :) (The latter, still using the olpc initramfs, dies because upstart 0.5 still doesn't know how to run as non-pid-1. olpc4's upstart-0.3.9 has a patch which implements this feature.) I've ported the patch to upstart's bzr trunk (it applies cleanly to 0.5.0), and scratch-built some rpms: https://koji.fedoraproject.org/koji/taskinfo?taskID=1106475 The patch is here, along with the srpm and spec file: http://dev.laptop.org/~bobbyp/upstart/ Of note, I had to add dbus-devel to BuildRequries, as upstart seems now to need it. I haven't had a chance to test the rpms, hopefully tomorrow. Hope this helps :) bobby Peter does not have an XO (g...@contrib program extreme slowness!) but may be able to help on other issues that surface as the result of an available public build... Oh, let's fix that. Ed, SJ, could one of you take care of sending Peter some XOs ASAP, please? Good idea. 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
