Re: [Server-devel] [UKids] Lightning kills underground Ethernet too; PoE wiring/voltages non-trivial!
> Would a PVC pipe protect an ethernet cable that ran between buildings too? No. PVC pipe won't protect your power cables either, except from mechanical stresses like a tree limb hitting it. If the building on either end of the power cable gets hit by lightning, the lightning will be conducted to the other building. The classic electrical code in the US requires "electrical conduit" rather than PVC. Conduit is thin walled steel pipe with special (cheap) connectors between segments. It is not structurally strong -- you can bend it by using a short lever, for example, and cut it easily with a hacksaw -- but when installed properly, it provides a complete grounded path from one end of the conduit to the other end. This grounded path is a better conductor for things like lightning (or short-circuits caused by bare bits of wire, etc), which makes the whole circuit safer for the nearby humans -- and protects it from mechanical stresses like a PVC pipe would. > Sounds like if not, an ethernet switch (to prevent electrical links, like > Sam suggests) or a wireless repeater (to eliminate the need for cables of > any kind) are necessary. If a cat5 or cat6 Ethernet cable is carrying a lightning strike, it will destroy pretty much any Ethernet switch that it's plugged into. The best ethernet switches (for this purpose) *might not* conduct that strike into all the other Ethernet cables plugged into the switch. But the average cheap one almost certainly will result in everything that's plugged into any Ethernet cable getting destroyed. I am not sure how you would find a "best" switch for that purpose. What was suggested for between-building use was not just an "ethernet switch", but a fiber-optic Ethernet link. Gigabit ethernet switches that have one or two slots for a fiber interface are available. You plug an "SFP transceiver" into one of those slots, plug a fiber into the SFP, run the fiber to the other building, put a second SFP there, plug that into a second fiber-enabled switch, and you have a working Ethernet connection. The beauty of this for lightning is that there is NO metal connection between the buildings -- the fiber cable is plastic and glass, containing no wires at all, and the gigabit data is carried as pulses of infrared light traveling through the glass fiber. The plastic and glass will not conduct electricity or lightning. Another advantage is that you can easily get a fiber to carry gigabit data over 40 to 80 *kilometers*, while a cat5 ethernet cable only works for perhaps 100 meters. The cheapest of those fiber-enabled switches still cost about US$300 the last time I looked. The GBICs cost about $50 to $100 at best. The fiber cable itself is finicky and ideally you would buy it from a supplier who will cut it to the right length and put the right connectors on it for you (because doing this in the field requires custom equipment, trained personnel, and is slightly hazardous with tiny bits of glass fiber that can get under your skin). Fiber cables can't be bent as much as cat5 cables (or the glass fibers inside break) so you have to take some care installing them. Unfortunately there are no standards for fiber connectors, or rather there are dozens, so you'd have to pick one connector type (e.g. "LC" connectors) and get the cable and the SFP that have those connectors. There are half a dozen 1000Base-something standards for fiber ethernet, too, for different kinds of fiber cables and different distances, so you have to specify which standard your SFP's will use. You may need a pair of cheap attenuators too, if your fiber run is short (to reduce the intensity of the light in the fiber). Compared to just getting cat5e or cat6 cables and plugging them into a cheap and standard switch, fiber is much more complicated and expensive. If there are power cables running between the two buildings, those power cables will conduct the lightning anyway, so there is zero reason to use the expense and complication of a fiber optic ethernet. The thing that fiber ethernet is really good for is connecting places that are kilometers apart, with a super high speed (gigabit or faster) connection. > > If you are going to use any cable outdoors or where it may be exposed to > > the elements, getting cable rated for the desired outdoor use may be as > > important as its speed rating. You don't want the cables getting water in > > them, causing interesting shorts and ground currents. UV-resistant cables are needed outdoors (the outer cable plastic doesn't break down when exposed to ultraviolet light from the sun for a year). > > Cables routed inside of walls/vents/etc. also often have to be one of a > > few special types for fire safety and other reasons. These are called "plenum rated". Their special property is that when they burn (e.g. when the building catches fire), they don'
Re: External hard disk testing for use with IIAB (internet in a Box) on XO based XSCE servers
For important systems, I think a USB hard drive will be a better choice than an empty enclosure. They are also often cheaper than a new empty enclosure and a new hard drive. Indeed, buying a brand-name external USB2/3 hard drive, which is invariably implemented as a SATA drive in an enclosure, is often cheaper these days than buying the exact same drive as a SATA drive. Check prices at http://newegg.com if they sell in your country. The Internet Archive, with 10+ Petabytes of spinning drives, buys hundreds of drives at a time, and these days they usually have hundreds of discarded enclosures and power supplies to recycle to local hackers. :-/ John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] External hard disk testing for use with IIAB (internet in a Box) on XO based XSCE servers
For important systems, I think a USB hard drive will be a better choice than an empty enclosure. They are also often cheaper than a new empty enclosure and a new hard drive. Indeed, buying a brand-name external USB2/3 hard drive, which is invariably implemented as a SATA drive in an enclosure, is often cheaper these days than buying the exact same drive as a SATA drive. Check prices at http://newegg.com if they sell in your country. The Internet Archive, with 10+ Petabytes of spinning drives, buys hundreds of drives at a time, and these days they usually have hundreds of discarded enclosures and power supplies to recycle to local hackers. :-/ John ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: minimizing footprint
We are talking of end users systems, how many kids will add a cron task? I was more concerned with other Fedora packages that insert cron jobs when they are installed. But if Fedora gets the dependencies right, rpm would install and run cron at the same time the package that needs cron is installed, so that's not an issue (unless the package dependencies are set to assume that cron is always part of the base system). The packages you're proposing to change are OLPC-specific packages anyway, so the changes won't mess up any other Fedora installs. I do see the point of removing unneeded daemons in every memory-constrained laptop, and this does look like low hanging fruit. On the Ubuntu system I happen to be typing on, 'cat /proc//status' shows cron taking 300k of resident RAM and 2.7Mb of virtual memory at its peak (and I have a place to page out to, which most XO's don't). The XO system will certainly be more responsive with another 2MB of memory available for general paging; its worst performance bottleneck was lack of DRAM when I last looked, and that situation has probably gotten worse as the system grew. My thought was that systemd probably wouldn't get much bigger if it got a parser for cron files. But your proposed change is less work, though it only fixes the issue for XO's, not for other memory-constrained systems. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing cron in 13.2
As a simple step in reducing base system footprint a little, I'm thinking of removing cron in 13.2.0. The 2 current users of cron (ds-backup and olpc-update-query) will be moved to systemd timer units which have equivalent functionality. The classic Unix interface for starting processes periodically is cron; all other packages that need that feature use it, ever since Unix V7 or so in the 1970s. If systemd has reimplemented the equivalent, can you fix systemd to implement the cron interface to that feature? That looks like the clean way to shrink the system a little. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] Customization Sticks fails on 13.1.0 12.1.0 for XO-1
Wad said: Please don't redistribute secure laptops --- OLPC's policy since early 2009 has been to deprecate the security system. The exceptions have been deployments large enough to have dedicated support staff capable of handling their own keys. Richard said: That policy is fine but perhaps needs to be more visible to the people going into areas where secure laptops were distributed ... Can an upcoming signed software release automatically disable the anti-owner security system on old lockdown laptops? Any new, signed Forth release could look for the original OLPC signing keys and disable security on laptops that depend on those, avoiding changing any laptop that has custom signing keys. Including this code in each new, OLPC-signed release, would tend to eliminate the problem. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] gray dots forever: when 12.1.0 13.1.0 never fully boot (XO-1 especially? 11.3.1 too)
(1) If powerd fails when the clock is set to before the Unix epoch, powerd is buggy, and this bug should be ticketed and fixed. That bug is independent of the situation that causes the clock to get set that way (which may well be another bug in another component, which would deserve another ticket). (2) Perhaps the reason there is trouble with reflashing some laptops whose clocks are bad is that the signature on the new release has a limited validity time period, and the security system is rejecting the new release because the bad clock looks like it's outside the validity period? John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Fedora-18 ARM release: support for OLPC hardware?
I'm way outside the OLPC Fedora development processes nowadays, which is why I'm asking what may be a dumb question. The Fedora 18 release is finally out for x86 and x64. There's a beta for ARM that supports half a dozen ARM systems. Oddly, in my mind, OLPC is not one of them. It's odd because there are probably more OLPC systems running Fedora than any other ARM hardware. In F17, the ARM release went to GA - General Availability for those half dozen ARM boards, again not for OLPC hardware. See: https://fedoraproject.org/wiki/Architectures/ARM Is there a good reason that the Fedora secondary architecture release process never builds releases for the OLPC? Or is this omission just an artifact of the history of how OLPC releases have been cut? Presumably the official Fedora release for OLPC ARM hardware could relatively simply use the Gnome user interface. Or even include the version of Sugar that's packaged to live in (x86) Fedora releases. Due to differing release schedules, it would not match the Official OLPC software releases, but that has always been true of Fedora releases, even on x86 based OLPCs. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Will the XO-4 need nonfree firmware
In that case, this machine without that card might be an option for people who want laptops they can use in freedom. They would need to get an external USB network device. Yes, or they could even get a different SDIO network device, if they can find one that's free and that has a compatible antenna connector. If someone sells them without the card (NOT with the card separately packaged), under another name, and if the cards are not easy to obtain, that could be a product we could endorse. I don't think anybody plans to sell XO-4's anyway. They're for whole countries to buy in huge orders. (I'm way out of the loop on stuff like that -- maybe things have changed.) If you personally happen to want one for development, you could get one through the OLPC developers program. But there probably won't be anybody selling them in stores, or over the web. FSF could advocate that countries should get them only with free SDIO network cards, and some countries might even listen. But to do that effectively, FSF would have to find at least one free network card that they could actually order and use; test it with the device to make sure it integrates properly; etc. I doubt that a country's education department would buy thousands of XO-4s that depend for their connectivity on dangling USB network sticks that kids are likely to lose or break. John PS: If you want to spend time on the freedom of OLPC products, first get the FSF staff to enforce the GPL on OLPCs. Major OLPC customer countries are still providing hundreds of thousands of laptops full of GPLv3 binary software to kids who can't examine, replace, or get the matching source for that software. These laptops are locked down with Secure Boot, with a remote disable switch (time-limited leases), and also shipped with root access disabled, so the owner can't even do simple software edits or upgrades. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OwNet
implemented using Microsoft technologies. However=2C this year we are goin= g to reimplement it using cross-platform technologies so that it can also b= e used under Linux. Have you heard of the Squid caching proxy for the Web? Lots of people at the slow end of an Internet connection use it, including major ISPs. It's already written, portable, and debugged. See: http://www.squid-cache.org/ I also see a Sri Lankan effort called Dalesa, that works in both Windows and Linux: http://www.opensource.lk/projects-Dalesa John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: scamometry
How can an HTML5 app be closed source ? It may not be free, and you may not be able to redistribute it, but it is HTML... It's a scam. It is built upon the open source library JSXGraph (which is LGPL: http://sourceforge.net/projects/jsxgraph/ ), but sketchometry itself is proprietary (only free to use: http://www.sketchometry.com/ ). They do not mention this fact clearly anywhere - they're trying to hide its proprietary nature while mentioning open source in their press release (http://www.sketchometry.com/wp-content/uploads/2012/07/press-release.pdf ). Of course, since they don't let you download it, they can shut off your access to it on their website at any time, or change the terms under which they'd offer it. (Yes, you can snarf a copy of the obfuscated JavaScript, but it won't be maintainable. And you can't legally make copies of it, you'd be violating their license.) Restrictively, they support storing your drawings in a couple of varied cloud services -- but not on your own computer. Its German authors from the University of Bayreuth don't seem to share OLPC's mindset and strategies. I suggest ignoring it... John PS: It didn't run at all in my Ubuntu Firefox web browser, even after I turned on NoScript and RequestPolicy for all the sites it wanted to download scripts from. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC build creation failed
On Thu, Sep 13, 2012 at 3:57 PM, Jose Prous josepr...@gmail.com wrote: Yes it's a x86 machine, I guess that is the problem. Thanks. Glad that we found the reason. We should add an explicit check in OOB that gives you a more useful error msg. Instead, you should fix OOB so it works to cross-compile. We at Cygnus spent years making the GNU tools able to cross-compile, and it all works. We built a big test infrastructure and made sure that the resulting executables were bit-for-bit identical no matter what the build host was. It's just your builder script that's unable to do it -- and that is under your control. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
We have no control over the network environment what so ever and need to work within the confines of what is available. This is our primary constraint: we cannot install servers or proxies. Schools in remote areas have latent/slow/expensive Internet links. You'd think that a caching proxy is common sense. Unfortunately not :( Furthermore, the newer wireless networks treat every client as potentially hostile and hence prevent them from communicating with each other. This also means that no collaboration can take place. You *are* sending them XO's or at least XO software loads, yes? Fix the XO software with a simple control panel checkbox to make it a cacheing proxy access point. Tell them to configure one of the XOs as a cacheing proxy, stick it in a corner on permanent power with its ears up, and have the rest connect to that one, not to the provided base station. They'll be one radio hop further away from the Internet (unless you send 'em a USB Ethernet dongle for that XO), but they'll be able to collaborate and share, and get much faster access to things that more than one of them need. If there isn't enough storage on those XOs to make a decent cache, send 'em a 16GB USB stick or a similar SD card too. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
We use yum to provide automatic updates to our XOs in the field, and we must be mindful that large RPMs can have an impact on the school's Internet connection. If 400 XOs need to download a ~800KB Sugar RPM, that's 320MB being downloaded, potentially at the same time. Isn't there a cacheing yum proxy? Yes, it turns out: http://terrarum.net/administration/caching-rpms-with-pkg-cacher.html [Beware the install advice in that page. It tells you to set gpgcheck=0 to install their packages -- rather than telling you where to get a public key -- and it neglects to tell you to restore gpgcheck=1 after you install pkg-cacher.] Supposedly apt-cache can do it as well, though I don't see a step-by-step guide: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482949 Once one of your local machines is running the proxy, then you point each of the XOs to the proxy as well as to the standard RPM repos. I think yum is smart enough to download it from the first repo that offers it, which means that if your cache is responding, it'll download packages from there. (Warning: I haven't done this myself.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Python bindings based on Phonegap?
Does anyone know if there are Python bindings based off the Phonegap API, with similar method calls, etc.? I'm developing an HTML5/Javascript activity that I would like to eventually port to Android and other mobile platforms. Having a set of Phonegap-like Python bindings for Sugar would help considerably. Sounds like doing a native Linux port of Phonegap would be a useful addition, with both X11 and Sugar window interfaces. Then Phonegap apps could, perhaps, work on both classic Linux machines and on OLPCs. Hmm, it looks to me like Phonegap isn't a write once, run everywhere kind of thing. According to the doc, every platform your app targets needs tweaks in the app, and/or needs a development tools platform for that target. It's more like classic Unix portability: how to build your app so that you can copy the source to 7 different build environments and get it to build and run on each one. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora 18 features that could affect xo-1
The outcome of our discussion was that we don't want this size increase, not on any of our platforms. But actually we see it as a significant downside for all small systems, not just ours. The wiki page mentions 43mb growth - that would be really painful. And foolish me thought a few years ago that with a million+ machines in the field, under relatively common management, that there would be time effort allocated to make those old machines run even more efficient software over time -- running faster, using less power, and taking less space. And to add high leverage features to the old machines, like sharing a cache of their infrequently used files automatically among the network of machines, backstopped by a local or global server. (We could put 43MB of constant debug info into 43 machines, one megabyte in each one, if we had a protocol for each machine to get the part it wants when it wants them. And could do the same for the entire Wikipedia dump, or the entire library of ebooks, or thousands of free videos both educational and entertaining, from all the places in the world that are doing free-curriculum development). Where are the audio chat programs that turn these laptops into phones for the kids, or let them hear the day's lessons from home when they're sick and can't get to school (when nearby Internet access is available)? We have 95% of the deep infrastructure built, and nobody's bothering with the other 5% of polish and interface that makes those capabilities usable by the kids. OLPC itself was likely to get sucked into new product development, paying less attention to the older platform, and indeed that did happen. But what about the in-country education departments? Do they simply not have the expertise (nor enough gifted high-school or college students to put in the human labor) to look through their software release with a finer comb than OLPC's always-rushed release teams could do? To toss the irrelevant or useless, to recompile with optimization for space, to pare away configuration options, to actually investigate what happens in DRAM as you run low and improve on the sketchy kernel behavior? Or even to stick a 1-gig SD card into the old laptops as $2 a midlife kicker (and improve the software so it can effectively use both the internal and external storage without requiring kids to do sysadmin)? I really don't think it is the nature of software to always get bigger and slower. I think a focused effort can pare it back. The country education departments would get clear benefit from such an effort (as well as giving their older kids a serious education in how modern operating systems work inside). But no? Clue me in, please. John PS: Many improvements made by an efficiency improvement team would be welcomed back into the upstream global Linux code base, too. So it shouldn't be too hard to backstop the older kids with country teams and the country teams with global developers. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: On XO-1.5 with 11.3.0/11.3.1 -- hang during shutdown?
I doubt that this issue is your problem. But in response to one remark: On the theory that these writes may be stalling due to the block number, (and we haven't seen any evidence yet of this), you can test for that by repeating the writes... There *is* evidence that accesses to some block numbers in MLC flash chips are much faster or slower than others (like 5x slower). They seem to be designed with fast blocks and slow blocks, though this is undocumented. There is no interface for telling the software which is which (except by actual measurement of the responsiveness of the chip -- and in microSD cards, accesses are mediated by a Flash Translation Layer of unknown characteristics). See: Characterizing Flash Memory: Anomalies, Observations, and Applications Laura Grupp, Adrian Caulfield, Joel Coburn, Steven Swanson, Eitan Yaakobi and Paul Siegel UCSD Tech Report CS2009-0946 August 19, 2009 Unfortunately the amazing people at UCSD fail to put up their archival tech reports in readily accessible PDFs. (It seems to be some sort of half-assed DRM system, since they yammer about copyrights on the same page.) They do have a mangled (OCR'd!) abstract here: http://csetechrep.ucsd.edu/Dienst/UI/2.0/Describe/ncstrl.ucsd_cse/CS2009-0946 and a mangled 18MB PostScript version available here: http://csetechrep.ucsd.edu/Dienst/Repository/2.0/Body/ncstrl.ucsd_cse/CS2009-0946/postscript The Wayback Machine failed to capture it while it was there. But I got the PDF from them when they had published it in 2009. I have put up the 1.5MB PDF temporarily here for research purposes: http://www.toad.com/TEMP-Grupp-2009-TR-FTest.pdf with the slides here: http://www.toad.com/TEMP-Grupp-2009-FMS-FTest.pdf John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Switching to randomly generated hostnames
Currently, XO hostnames are set on first boot in the following format: xo-A-B-C Where A, B and C are the last 3 bytes of the MAC address expressed in hex. In Nicaragua we are seeing cases where XOs have no hostname set, both on XO-1 and XO-1.5. On XO-1 this is presumably because libertas usb8388 init was never 100% reliable, and on XO-1.5 its presumably because the wireless card was DOA but was replaced after first boot. Why would we need to get it from the wireless card? Isn't the laptop's MAC address stored in the manufacturing data in motherboard flash? But if for some reason you can't use that... I propose we move to generating hostnames in the same format as before (xo-A-B-C), but with A, B and C assigned as random hex digits on first boot. (If people are worried about collisions, maybe we add a D digit.) Existing hostnames have three bytes of info (e.g. xo-12-3a-49). Particularly if you're going to generate them at random rather than by prior assignment like MACs, why reduce the amount of unique information (e.g. xo-1-a-4 or xo-1-a-4-d)? Producing three random bytes of info for the hostname, rather than 1.5 or 2 bytes, would reduce the chance of collisions; and has the advantage of not changing either the size or format of the hostnames, in case anything else is depending on it. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
AFR: Sony's 2-screen Tablet P: a good idea gone wrong
[Summary: 2-screen laptops need fairly deep software support because 2 screens don't look like 1 screen. I excerpted freely below; see the link for the entire story. --gnu] http://www.afr.com/f/free/technology/digitallife/g_ZWzfPcJsePV9VdQfxY9w1H Sony's tablet a good idea gone wrong PUBLISHED: 30 Mar 2012 The best thing that can be said about Sony's new $729 Tablet P is that it means well. The central idea that must have led to the construction of the Tablet P -- that iPads are too large -- is pretty sound. iPads are too large, at least for a lot of users (the staff here at the Digital Life Labs included), and at least for a lot of applications. So, yes, Sony was trying to solve a genuine problem when it came up with the Tablet P, a tablet that folds in half so you can slip it into your pocket or purse, that's light enough to read e-books on for hours without your hand cramping, and small enough that you can use it as a camera without looking like a total tool. The trouble was, they couldn't make it happen, not with today's technology. To have a tablet fold in two, you either need one screen that folds in two, or you need two screens with absolutely no bezel, so that one screen blends seamlessly with the other screen when they're placed side by side. Neither of those technologies are available today, so all Sony's engineers could come up with was two screens, each with a modest 4 mm bezel that, when placed next to the other bezel, creates a whopping great 9 mm-wide black bar right in the middle of the display. (The other millimetre is the gap between the displays, which can be quite irritating if there's light behind the display, shining through.) Now, that wouldn't be completely fatal if the Tablet P were running an operating system that knew how to handle two screens with a black bar and a sliver of light in the middle of them. But the Tablet P is running Android, and neither Android nor most Android apps have a clue how to use the dual display. Some apps on the Tablet P, chiefly the ones Sony has rewritten specifically for the device, work quite well. The email app, for instance, uses one screen as a virtual keyboard, and the other screen as a display, when you're creating emails. When you're viewing emails, one screen is used to list the items in the inbox, and the other screen is used to preview the highlighted item. But trouble arises when you use apps other than the ones written to cope with the black bar. Most apps will just curl up into a ball and display only on one of the two screens. Neither of those screens is very large, so you end up with apps displaying little bigger than they would on a mobile phone. Worse yet, they're both very long and narrow, far more so than many apps seem able to cope with, and as a result many apps won't even fully utilise the one small screen they're on. Amazon's Kindle app, for instance, an app so well written that it can usually cope with any screen you throw at it, uses only 83 per cent of one screen, and zero per cent of the other. Almost 60 per cent of the Tablet P's display is left blank. It's such a pity, because a tablet that folds in two is such a good idea. Perhaps the best thing that can be said about the Tablet P is not that it means well, but that it's simply ahead of its time. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
idea: set a niceness value under which a process won't awaken suspended CPU
Here's a power-saving idea that's been marinating since 2007 (in an obscure corner of my mail queue). When I reviewed it today I didn't see anything too wrong with it. John Message-Id: 200710240912.l9o9c1k2026...@new.toad.com To: gnu Subject: OLPC idea: set a niceness value under which a process won't awaken suspended CPU Date: Wed, 24 Oct 2007 02:12:01 -0700 From: John Gilmore g...@toad.com An easy lever for CPU consumption management (power mgmt) would be to define a set of user processes that won't be scheduled in a power-suspended system. They won't wake the CPU even if their timer goes off, their packet arrives, or their fairy godmother calls. But if something else wakes the CPU, and it's going to stay running a bit while some higher priority process is waiting for flash or packets or something, these processes can run in the background. My idea is to tie this to nice. So if you nice -20, it puts you into this range. Say everything below -15, which lets you set a few priorities among the low priority background stuff. So if you nice things all the way down, they run when the CPU is powered, in the cracks when there's nothing else to do, but they don't cause the CPU to wake up to service them if nothing else is going on. For example, code that polls and updates the battery status once a minute in HAL. Or a system activity monitor that shows CPU state graphs or how many MHz we're running. Or an RSS feed reader. Or the thing that clears out Mozilla's cache. Or the incremental backup daemon that copies the machine's state to the school server. (If that ran with scavenged electricity, cool! It can raise its priority once a day or so, to make sure that a backup gets done one way or another.) The GUI could have a way to throw a process into this state or out of it. E.g. push your mail reader there, polling every once in a while for email, opportunistically. John --- End of Forwarded Message ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
waking up on all multicast frames, apparently even ones that wouldn't normally be sent from the hardware to the driver There's a flag for that, ifconfig wlan0 allmulti, which should NOT be set. That configuration tells the hardware that we want to receive all multicasts, not just the ones we have software listening for. (It shows up in capital letters, in the flags line of ifconfig wlan0 if set.) If that's off, waking on all multicasts is pretty unlikely. Multicast reception hardware (for every Ethernet as well as every WiFi) is designed so that it doesn't see packets unless they match the address filter, which the Linux drivers already know how to set. This is easy to test. Run ip maddr, it will tell you all the addresses that the driver is listening for, on each interface. It lists link-level (MAC) address, IPv4 addresses, and IPv6 addresses. To test it, let the laptop auto-suspend. Then from another node on the same network (AP or adhoc or ethernet), ping a multicast address that the node should NOT wake up for, e.g. the all routers on this link address in IPv6 (ff02::2): ping6 -I wlan0 ff02::2 This should NOT wake up the autosuspended laptop. You can try pinging various other multicast addresses, e.g. ff02::f, or ipv4's 224.1.2.3. After confirming that, try sending a multicast that SHOULD wake up the laptop. You have a list of them from the ip maddr output. An easy one that's always there is the all nodes on this link multicast address in IPv6 (ff02::1): ping6 -I wlan0 ff02::1 This should wake up the laptop (and get you a ping response sent back to the second node). However, old bugs like http://dev.laptop.org/ticket/6528 may prevent the ping response (packets that wake the laptop from suspend are often lost). If we're still dropping some packets that wake the laptop from suspend, then that could be one of the problems with collaboration. Four years ago, I commented: http://dev.laptop.org/ticket/6818#comment:18 Yes, the real test will be how it integrates in the whole system: With the presence service running, with ethtool -s msh0 wol uma, and with auto-suspend: Will we drop the unicast or multicast packet that wakes us up (#6528), or will it actually reach the application that's awaiting it? And, secondarily, can we stay suspended long enough to save power? Or will the application level multicast traffic be so constant that we always wake a few seconds after we suspend (in which case we need to fix the applications so they aren't so chatty)? John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
The first problem I see is that machines don't wake on ARP. Ultimately I believe we don't want our machines to wake on ARP, we really want firmware that can handle ARP and only wake when our address is ARP'd. I don't know how unreasonable a request that is. It's completely reasonable, and we've put together most or all of the parts to get it working for IPv4. See: http://dev.laptop.org/ticket/3732 If we fix the wake-on-multicast problem then we'll fix IPv6 ARP as well (it uses multicast for neighbor discovery packets that replace the ARP protocol): http://dev.laptop.org/ticket/4616 Another problem appears to be lost wakup packets while collaborating. http://dev.laptop.org/ticket/6528 This should be able to be fixed by using an iptables queue. If we queue collaboration traffic that isn't responded to, we can quick of a script when the queue gets X long that tries various methods to wakeup the machine on the other end. We should fix the real problems, which are low-level, straightforward, and easy to reproduce, rather than building crazy workarounds at higher levels. Be smarter about how we track network traffic. Other than just checking if there is network traffic, we should be tracking where this network traffic is from or to. We shouldn't need to check whether there is network traffic when desiring to suspend. If no process has run in N milliseconds, the kernel should autosuspend. N should be tuned to avoid constantly suspending and then immediately reawakening, e.g. between packets in an active HTTP connection. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On Sat, Feb 4, 2012 at 10:26 AM, Samuel Greenfeld greenf...@laptop.org wrote: Disabling suspend during collaboration was discussed a year ago, but as far as I know this has not made it into any 11.3.x build: http://dev.laptop.org/ticket/10363 There are longstanding bugs from four to five years ago, all the way back to the XO-1, that prevent collaboration from working when aggressive power management (suspend) is enabled. Most of those never got fixed, as far as I know. Lots of circumventions were attempted. Some bugs were closed despite not actually getting the right fix implemented. They're all still in trac. E.g.: http://dev.laptop.org/ticket/4616 http://dev.laptop.org/ticket/9535 http://dev.laptop.org/ticket/10878 http://dev.laptop.org/ticket/10363 http://dev.laptop.org/ticket/10207 (closed because it still fails!) http://dev.laptop.org/ticket/7128 http://dev.laptop.org/ticket/6818 http://dev.laptop.org/ticket/6684 Back then, we were barely able to do the bugfixes needed to get to minimal power when suspending the XO-1 when you close the lid. Making exotic features like collaboration work was way beyond what the team was able to do. Perhaps now is different? John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: RTC anti-rollback testing
I added the rt tag, but when I run command ok rtc-rollback? . the laptop powers off. Is it a normal behaviour? It's normal for DRM to make your system do obscure, non-intuitive things. Did nobody explain that to you when you asked for this? John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: open datasheets
John touches upon a sore subject around OLPC here. On both 1.5 and 1.75, OLPC obtained assurances from the companies that the data sheets for the processor/companion chips/SoC would be publicly availably by the time the laptop reached production. In both cases, the companies lied to get the designs started and have no intention of ever releasing critical documentation outside of an NDA. As a company with extremely limited means, what is OLPC to do ? Trying to do business with people who lie is a classic reason for contract law. Write a contract before you start, which permits YOU to release the specific documents that you care about (which you have received under NDA). You clearly have them in-house. If your contract with the company permits YOU to post them, then no amount of later lying by the company can prevent you from posting them when the laptop goes into mass production. If the company refuses to sign that contract, don't use their chip; use someone else's -- BEFORE you spend the multiple million dollars. Since you tend to like ARM these days, there seem to be about 20 ARM chip vendors around; ONE of them should be smart or stupid enough to sign such a contract to get your business. In what form were the existing assurances from the companies provided? In writing? If they are, or could be interpreted as, part of the contract negotiations or committments, then OLPC may already be free to post these documents. Or, more likely, to sue the companies to force them to honor their contract. (That's why a better construction for future contracts is one that lets you release it yourself, without needing a lawsuit.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: hardware crypto
Is it worth looking at enabling the HW crypto devices for the various platforms? I have a Fit-PC that I use as a FW with a geode and the HW crypto is pretty good on that, the Via chip has one on the 1.5 and there's also some form of HW on the 1.75 too. last time I looked we weren't enabling them, We disabled it for XO-1.5 early in the development cycle because it caused kernel crashes. Could be reevaluated now, if someone tests it and tells us that it works then we could enable it again. Last time I looked at the hardware crypto in XO-1 Geode, it was designed by people who didn't consider any of the system or software aspects. Using the crypto hardware was actually slower than doing it all in software, for 99% of use cases. The one useful thing they might have provided, that we couldn't do well in software already, was a random number generator -- but they didn't. The Via chip spec for XO-1.5 is still not available, despite OLPC's suggestion that they wouldn't ship a processor without an open manual. I haven't looked at the ARM chip in the XO-1.75. Is the spec even available? The Hardware Specification 1.75 page doesn't exist in the wiki yet. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.0 build 4 released, for *XO-1.75*, XO-1.5 and XO-1
a mess. I made the suggestion on adding an a/i to the build so it would be os4i.zd4 or os4a.zd4. You couldn't put the model number into the file? Rather than a cryptic a or i, how about 1, 1.5, or 1.75? Teachers and kids aren't going to know who designed the processor inside their laptop. We'll be lucky if they DO know the model number, since it isn't printed on the device. (Perhaps inside the battery compartment?) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sad face
Uruguay replaces the OLPC key with theirs. There is nothing we can do. You must talk to Uruguay support. Ah, thanks. I'll stop thinking about it then. Don't stop thinking about it. OLPC always has the choice to stop making DRM-locked machines. Your next machine should not offer a DRM option. I strongly suspect that the countries would buy it even without that feature - and the kids and teachers would be better off. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: License files - L10n
The theory was to provide, in flash, the unofficial license translations in the languages primarily used in deployments, e.g. Spanish. That way the kids can actually tell what rights they have without having to (1) learn English, or (2) access a perhaps nonexistent or very slow Internet connection. Providing the English language license is a requirement of the licenses themselves; if you ship the software, you must provide them. Providing the unofficial translations is not a requirement of the licenses. But how can you teach kids the principles of free software without them ever being able to read how they can apply those principles in their own life with the software right in front of them? (Indeed some of the deployments appear to have never read nor understood the licenses -- or to just be corrupt -- since they violate the TiVoization clause. Having locally readable licenses may help fix that, too.) The license translations are tiny -- a couple of kbytes each -- so flash space isn't a big issue. I'm just hoping to close a simple ticket here and this is the easiest and most correct solution I could devise. Easiest, certainly. Most correct, no. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: powerd-dbus network extension
What kind of idle-suspend are we talking about here (and on what XO hardware)? Shouldn't a proper idle-suspend be resumed when the system isn't idle any more, i.e. when a packet comes in or a timer expires in NetworkManager? Fixing that would eliminate having to build a separate kludge for every time-sensitive protocol. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar Commander
I'm sorry, I don't mean to ruffle any feathers, but the flat journal is a really broken model when you stick in a USB stick with 2000+ The flat journal worked great on 8 floppies. It was obsoleted in 1982 or so. The whole emphasis on the journal as filesystem interface was another of those grand OLPC experiments. Unfortunately, unlike the mesh, its failure was not followed by junking it and replacing it with what every other computer does -- what works. This journalism religion is also a major reason why kids can't read or edit the source code of the OLPC -- because it isn't visible in a journal, and if it was in there, it would be painful or impossible to find or organize. The new Unity 2D UI that Ubuntu defaults to makes the same decision, and it works well. It works so well that I won't be using Ubuntu in the next release, because they are forcing everyone to run Unity, I think on the theory that if they force enough people to use it, some of them will fix all the bugs and misfeatures in it. Unfortunately for them, this is not a market where they have any power to compel users; we'll just go elsewhere. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 touchpad once more [Devel Digest, Vol 64, Issue 28]
Anyway to quantify touchpad use and behaivor in F9 builds? I don't know of any way that involves only the laptop or software. Quantifying use and behaviour would require a video camera on both the touchpad and the screen. Or accurate reporting from both people who experience a problem and those who do not. Self selected reporting from community enthusiasts isn't as reliable. It might be possible for testers to tape a small mirror on their XO camera (perhaps 1cm square), so it can see the touchpad. Run a test program in the background that records the video into a circular RAM buffer, and saves a chunk of it whenever it sees the pointer jump. Then go on doing what you usually do on the XO. An engineer can later look at those saved videos to see how many of the pointer jumps happened without a corresponding finger motion. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Out
I had to think about this some before having a useful response. I cannot speak for every Sugar developer, but the approach I have tried to take with Turtle Art is a bit different than you are describing. The block-based programming environment is not meant to be a substitute for real tools; it is meant to be a place to get started; to learn that you can write and modify code; and to provide multiple motivations and launch pads for getting into the real thing. I've worked pretty hard to make the structured thing behind the view more approachable, and have provided multiple ways in and out: exporting your fluffy view into Logo that can be run in Brian Harvey's text-based Logo environment; direct, in-line extensions written in Python; the ability to create new blocks by importing Python; a plugin mechanism for making major interventions; and a refactoring of the underlying structures to make the code more approachable. (The source code is peppered with comments and examples of how to make modifications.) None of these interventions are intended to keep the kids programming in Turtle Art. They are all intended to get the kids started down the path of real programming. But I content that we need to engage them; let them discover that they can write code; and make changes; and that it is not something just for others but for everyone. Walter, this is a worthwhile approach. But it was all invisible from an OLPC user's point of view (i.e. a child's). All they get is a GUI in which they can hook blocks together and see graphics. Even finding the library of fun looking pre-existing designs was hard (it's hiding behind a bizarre looking icon that you can't even see until you go to a different tab in the Frame than the default one). If you show a kid how to find one of those designs, they get the idea of TurtleArt, and can modify them to see how the design changes. Until they see a complete, working design in 10 blocks including a loop, TurtleArt is a morass where new users can drag things around but it doesn't do anything fun. (Note I'm working from memory of a several-year-old TurtleArt. Perhaps it's better now.) (Also, it's hard to make the leap from a slow turtle leaving marks behind as it goes two steps and turns, to the whole screen being filled with colors in a flash. Most things in the world don't have the many-orders-of-magnitude speedups that we in computing have become blase about. It wouldn't occur to us that to paint an entire wall in a second, we should tell the painter to move the brush one inch and then repeat that over and over until done. We'd look for a spray gun, or toss a whole bucket of paint, or recruit a crowd of painters, or something. Fast things and painstaking things aren't disjoint in computing, as they are elsewhere; how do you teach that powerful insight?) I am open to suggestions as to how to get more kids to move on from Turtle Art to ___ (insert you favorite real programming environment here). First, have Turtle Art start up not with a blank slate, but by bringing in one of the predefined designs -- preferably at random, so they'll see more of the corpus as they run it over and over. Second, I suggest that if some blocks are implemented in short bits of Python, that there be a user interface for seeing and modifying those short bits of Python (by examining the block in the GUI). This will provide a bridge for exploring kids to notice that the blocks are built out of short bits of structured text -- and that they can understand and modify those texts. If they've already figured out that they can modify the numeric blocks, then they'll try modifying these too. The thing that pops the blocks open shouldn't be too hard to find -- perhaps a double-click, or something else that they'll do by accident sometime. If you can implement more blocks in such bits of Python, do it, so they'll have more blocks they can open up and examine and modify from the GUI. How to get them beyond the TurtleArt GUI into the actual Python source code of the body of TurtleArt is a challenge that nobody seems to have insight on. The View Source concept seems to have been much harder to implement than we all expected. Don Hopkins worked on a PostScript-based window system (HyperLook) that would let you flip over an object on the screen to see behind it a control panel with the guts of its implementation visible. You could modify those, then flip it back and it would resume running. See: http://www.art.net/~hopkins/Don/hyperlook/index.html and http://www.art.net/~hopkins/Don/simcity/hyperlook-demo.html . Looking back at HyperLook, it looks a lot like the etoys environment, full of object oriented code with direct manipulation gui editor interfaces. It's dead now; a historical curiosity of interest only to prior-art searchers defeating too-obvious software patents. It's hard to keep such self-contained and self-referential environments alive and relevant in the world at
Re: Prelink
Using a well-behaved olpc-update, minor updates should be really lightweight and low-risk to deploy. The standard solution to that is called package managers - rpm in your case. Unfortunately its network version, yum, is really heavyweight and too clumsy to run in many XOs. Installing updates with rpm, and fixing or rewriting yum to be low impact in XOs would be much better for the community than continuing to evolve your own sui generis tool. Though it's much more fun to reinvent the wheel, the subsequent maintenance load is substantial, as you're noticing. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Out
Recently, I finished my dissertation on mobile development directly from mobile devices. Something like this might've been very useful, although I did target experienced developers, not beginners. Mobile development would work great on mobile devices like the XO-1, XO-1.5, XO-1.75, and perhaps even the XO-3, if only we'd teach the kids a few simple paradigms like files, hierarchical file systems and text editors. (Efforts to teach computers to compile or interpret large programs that aren't written in collections of files are doomed to niche uselessness, though it sure makes a fun research/masturbation topic. I spent years paid to write big programs in APL that way in the '70s -- those programs are all unportably dead today, and APL is a tiny niche.) These are not hard concepts. Kids learn them daily, but not from XOs. Since OLPC can't seem to be dissuaded from this fundamental error, the question for me is whether it can be influenced to minimize the amount of learning that kids go through which is unique to this useless programming model. There *is* usefulness in teaching kids how to write tiny programs that can never scale up to useful, portable, supportable programs. But once they get the basic concepts, they should be transitioned to industry best practices pretty quickly, writing a real Hello World and then evolving it to be more useful. Rather than getting stuck by e.g. trying to make substantial programs fit on one screen by moving tiles around visually. As in the model-view-controller paradigm, the kids need to learn that the view is not the model, but the model is a simply structured thing that lives behind the view. If you don't teach the abstract structures that the model is based on, the kids can't learn to make that separation. This is why they never learn to modify the real programs that hide behind the fluffy interfaces on their real XO computers. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Disabling prelink in software builds
Any objections to prelink being disabled? I object. You are running a diskless, swapless system. The whole point of prelink is to make your read-only binaries actually remain read-only, rather than requiring the dynamic linker to modify them in memory. This allows large numbers of pages of executables, their data, linkage tables, etc, to be paged out by merely throwing them away, whenever there's memory pressure -- which under Sugar and Browse is all the time. They can be paged in merely by reading them from the prelinked executable files on flash. If you don't run prelink, all these pages are stuck in RAM, because they are modified by the linker before main() is ever called, and there's no way to page them out, so those page frames are permanently in use even if the program never needs or uses any CPU time. This reduces the memory available for the programs that ARE trying to run. In ordinary Linux systems that have swap space, non-prelinked processes that are inactive can swap out their modified pages, onto a small partition on the hard drive, freeing those page frames in DRAM for use by active processes. The XO doesn't have that luxury. Measurements made immediately after booting, when there's little or no memory pressure, won't tell you anything about this aspect of prelink. You have to look at /proc/XX/smaps in a running system that IS under memory pressure, to notice that much more of the memory of the inactive processes has been released from DRAM, than in a non-prelinked system under memory pressure. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD cards and DATA_STAT_AFTER_ERASE
Currently, when installing software, OLPC firmware erases the entire disk then writes the entire disk contents, even if most of that is zeroes. I am looking at an optimization where we can simply avoid writing those 0 blocks, greatly speeding up the flashing process. In my test case of 1 SD card, DATA_STAT_AFTER_ERASE=0 and the vendor is not lying about this, so I managed to cut down the time needed to install an OS image by more than 50%. Hopefully this can apply on a wider basis... I suggest writing paranoia into your code. Check the flag bit if you like, but also, read back an erased block and see if it's 1's or 0's. Hmm! You can make it perfectly symmetrical: Erase the drive, read back a block, then compare each block (that you consider writing), to that block which you read back. If it erases to all ones, you won't write any all-one blocks to the drive. If it erases to all zeroes, you won't write any all-zero blocks to the drive. (Of course, when doing these writes, don't do one-block writes to the drive; accumulate a bunch of them into a single larger write. If you know the erase block size, the code could seek to do writes of that size, aligned on that boundary - particularly after recovering from a series of blocks it doesn't need to write to. But some cards may be able to erase several blocks simultaneously, and may thus prefer a write of N erase blocks. Or cards may or may not care whether your writes are aligned (since they're remapping the blocks anyway through the flash translation layer), and may just prefer that you always write one or more erase-blocks' worth of data, no matter what the alignment. Since reading flash is much faster than writing (and since one of the nasty aspects of flash is that writing block X can screw up the contents of block X-1 or X+1), would you consider reading back the entire drive after you're done, making sure the whole thing checksums properly? (And also making sure that your checksum detects substitutions of entire all-1 blocks for entire all-0 blocks and vice verse!) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Mesh Potatos and OLPCs?
Has anyone used the Mesh Potato devices from villagetelco.org to provide mesh connectivity to a network of OLPCs? Eben Moglen's Freedom Box mailing list has been exploring whether to include mesh in their boxes. My experience with OLPC's mesh has led me to question the risk/reward payoff of doing wireless mesh, though I think a wired mesh of Ethernet cables could be very interesting. But others have turned up who are building wireless meshes, who claim to be making them work in production. Here's one such, the Mesh Potato from http://www.villagetelco.org. It's a $119 (retail) box with 802.11b/g and a wired phone jack, plus Ethernet. It meshes over 802.11, provides an access point, and lets you make phone calls to other Mesh Potatos or any SIP phone reachable on the net. It is open hardware, runs open software, and is designed to live outdoors and run on rough rural power. It unfortunately needs detailed sysadmin with Linux shell commands now. This 1-minute embedded YouTube video explains their goals: http://www.villagetelco.org/2011/02/in-a-village-telco-minute/ I've edited the enclosed message down to the relevant part: Date: Mon, 21 Mar 2011 14:51:59 -0500 From: Charles N Wyble char...@knownelement.com To: freedombox-disc...@lists.alioth.debian.org List-Archive: http://lists.alioth.debian.org/pipermail/freedombox-discuss On 3/20/2011 8:44 AM, James Vasile wrote: Meshing is hard. Nobody I met knows anybody who is nailing mesh networks. I'm going to get all the mesh heads together soon for a real conversation to see if we can work towards a recommendation on the most promising avenue. Um *waves*. I guess I need to get out more. I've built a few mesh networks over the past year. It's not that hard (it used to be quite difficult, but the underlying bits have really matured). Us mesh heads hang out at villagetelco.org and a few other places (olsr.org, batman.org) :) We have an annual gathering already, http://battlemesh.org/ Join the mailing list and say hi. Mesh is moving along, slowly and steadily. Mesh is the underpinning of an open network. Open networks are the underpinning of everything else. I feel that mesh networks have reached the point of maturity, that they can stand on their own. I feel they are readily and rapidly deployable (plug and play) due to the work of villagetelco.org. Has OLPC seen these before? If so, what's your experience? John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Harvesting Sugar Trees.
Over time, most embedded system developers have pushed their work upstream. This happened gradually as system developers learned that it was more expensive to maintain their customizations locally then to work with upstream. The tipping point was often found as system developers tried to rebase their customization when upstream rebased. At Cygnus in the 1990s we were in the middle of some of that. We were paid to clean up the work of several big companies on the GNU compilers, and integrate it into the master sources. For example, Intel had built COFF object file support as well as a GCC code generator for the i960. Their support of Cygnus led to BFD, which allowed the binary utilities to support many, many file formats simultaneously. Wind River had their own GDB debugger interface to their embedded operating system, and custom binary utilities. We merged all their stuff too. While pitching one company on our merging and development services, Michael Tiemann told them we'd do their job for $X this year or for $2X next year. He failed to close the deal. But indeed, the company came back a year later, and paid twice as much. They had spent the year trying to do their own integration and patching, while the GNU compilers evolved furiously underneath them, and were ready to leave that job to the professionals and go back to doing what their own company was good at. Our best GCC developer, Jim Wilson, often spent more than half his time merging Cygnus's GCC changes (created by himself and dozens of other employees) into the master GNU GCC sources, and vice verse. It was frustrating but necessary, to avoid forks that would lose access to major capabilities built by other teams. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
F15 glibc again fails on AMD Geode LX
FYI: Early Fedora 15 builds don't run on the Geode, again. This time, people seem to be on the issue, and may resolve it without much work from OLPC. But I think it would be worth spending some testing time to make sure it's really resolved, so the final F15 can be used as a basis for an OLPC release for the XO-1. https://bugzilla.redhat.com/show_bug.cgi?id=579838 --- Comment #33 from Andre Robatino robat...@fedoraproject.org 2011-02-04 02:31:39 EST --- The most recent glibc.i686 build for Rawhide ( http://koji.fedoraproject.org/koji/buildinfo?buildID=215507 ) appears to have reintroduced the NOPL instruction. See http://lists.fedoraproject.org/pipermail/test/2011-February/096805.html . --- Comment #34 from Peter Robinson pbrobin...@gmail.com 2011-02-04 03:06:02 EST --- Re-opening and adding as a F15 Alpha blocker John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Feature requests for 11.2.0 - seeking deployment and community input
Please post any ideas here, and they'll be considered when we come to plan which features we'll aim to include. Well, the obvious one is to actually implement the real idle suspend that happens in between keystrokes, turning off the CPU to save massive amounts of power, while keeping the screen as it was. This was targeted for 9.1.0: http://wiki.laptop.org/go/Feature_roadmap/Page_of_all_features_that_target_9.1.0#Feature_roadmap.2FImproved_battery_life but it isn't clear how many of the numerous requirements actually got done. This particular bit is requirement 15 in the Improved battery life feature. This is one of the laptop's key innovations, designed to save massive power, allowing kids to use their laptops all day, even with the small and cheap battery that's designed in. It required significant rethinking, engineering, and testing of the hardware (DCON, etc) compared to other laptops, and OLPC actually did that. And yet to this day the software that would implement it for end users has never been delivered. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: os351 on XO-1 - Browse memory pressure
Do a df and see if any temp file systems are chewing up a lot of memory. yum is known to just barely work and leave a lot of junk files in memory. Perhaps someone could produce a patch to yum to remove these junk files before it exits? That would benefit all yum users, not just tmpfs-constrained OLPC users. John (not a yum user) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Aggressive suspend vs NM/DHCP
(nor for the first time) I spot an XO that goes into suspend in the middle of the DHCP conversation. In this case, it was with a bad WEP key so we never heard back from the DHCP server. But if you look at /var/log/messages, you see dhclient's DHCPDISCOVER and 12s later PM: Syncing filesystems... done. Normally you'd get a response from a working DHCP server in much than 12 seconds. Do we wake up on broadcast DHCP responses properly? (Am I worrying pointlessly?) If the client sent a broadcast DHCP request, any response will NOT be a broadcast -- it'll be sent directly to the MAC address of the requester. (I co-designed the BOOTP protocol that DHCP is based on.) Otherwise, is there a way for powerd to wait a bit longer when NM/dhclient are... active? I guess I have to post this once a month: stop dumping more kludges into the kludged autosuspend implementation. If you fix it properly, once, then you'll never have to kludge anything again. An autosuspended laptop should awaken when it gets a packet addressed to it. Fix all bugs around that and you won't need kludges. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Memory leak in Sugar -- how to dump Py data structures?
[1] http://www.lshift.net/blog/2008/11/14/tracing-python-memory-leaks [2] http://mg.pov.lt/blog/python-object-graphs.html Fedora 14 (imminent) includes GDB updates for debugging heap allocation issues. It's python friendly. You can probably backport it into whatever Fedora you're running Sugar on. See: https://fedorahosted.org/gdb-heap/ John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power down USB when suspending
It would be better if you could explain WHY you need to take a photo quickly after resuming. Is the idea that the laptop will save power? It could remain suspended for a long time, wake and take a picture, then suspend again until the next picture is needed. In that case, you can wake it a bit early, and it can still take the picture on time. If suspend in the OS was working properly, you could just sleep() as long as you require, and the OS would automatically suspend and resume at the right times. (Though if you have a USB peripheral plugged in, it shouldn't be suspending at all, since that cuts the power to the peripheral, which might not be able to deal with that.) Is there some other reason why you need the laptop to suspend? (Even if it could power the USB bus during suspend -- or if you use an external USB hub with power -- the camera will burn power constantly rather than saving power while suspended.) The built-in XO-1 camera is not connected via USB, so it should be available more quickly after resuming from a suspend, if you can use it instead of a USB webcam. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bad interaction between sleep timeouts and Salut?
It's pretty simple, actually. When in idle suspend, the system should remain fully functional, just burning fewer ergs. It's an optimization, not a change of behavior. This means the system should wake up anytime it would've gotten an interrupt during normal operation. Which means for any unicast packet, any ARP packet directed to it, and any multicast packet that it's listening for. But people keep insisting on making this simplicity complicated, and thus trying to figure out how we can disable idle suspend while doing multicast collab or how we can send more or fewer packets to suspended laptops or whatever. Just fix the bugs and it'll work a whole lot better. THEN if you have a performance problem, and only then, start to optimize it by fiddling with timers and disables and such. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: backups
If a USB olpc-update isn't possible, I'll have to flash my XO-1 and lose my work. Release notes say only, Make a copy of any data you wish to keep... how? I don't know of a guide. It's because being forced to manage your ongoing work via the Journal is so much easier and more intuitive than using the file systems that the rest of the world uses. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
I didn't do as detailed an analysis as NoiseEHC - I looked at dirty page frames, and realized that a large part of RAM was filling with dirtied pages (even dirtied pages of executables, which get patched to fill in shared library linkages). Without swap, this left very few page frames for read-only executable code to live in -- so it would tend to get paged out (destroyed) on the theory that it's easy to bring it back in again. The result was slow execution. My theory on how to improve on that from the high Python app level was to have the Python apps save their state when obscured (like Android apps) and also provide a fast start path from a saved state to a resumed process in that state. Any process which had saved its state this way (probably in a little xml file or binary file -- something quick and not memory-intensive to parse) could then terminate, which would free up all of its dirty pages. When it needed to be visible again, it would be re-invoked by the shell and would jump to the same place in the GUI without stirring up a lot of memory references. This high level kludge would allow even interpreted Python programs to effectively reduce their working set. This strategy was never built and tested, however. I could barely get people to look at the /proc/smaps results that pointed to dirty pages stuck in RAM as the slowness culprit, and was also unsuccessful in convincing OLPC to prelink the shared libraries before shipping a release, thus allowing read-only pages to not get dirtied with shared library linkage relocations. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Killing activities when memory gets short
As long as activities are saving and restoring properly it could be made pretty much transparent to the user. Of course that's easier said then done... Android has a whole mechanism for this: http://blog.rlove.org/2010/04/why-ipad-and-iphone-dont-support.html That explains the problem, but doesn't explain the Android answer to it, which is here: http://developer.android.com/guide/topics/fundamentals.html The section Component Lifecycles gives the summary. They call each app's onPause() method when it is obscured from visibility on the screen, and that method is responsible for recording everything the app needs to restart itself and get back to the same screen display (what file it was working on, how far down the file it was, etc). Then, any process whose onPause() method has been called is considered a cache, and can be killed without warning by the kernel. (I'm not advocating using this system -- I've only barely been exposed to it. But it's useful to see how others have solved the problem you're facing, before making your own solutions.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend: RTC wakeup, sleep
There is no 1-second ambiguity in the RTC. The CPU can only read out a value accurate to 1 second, but the CPU can tell precisely when the RTC ticks from one second to another, which gives it much higher precision if it's willing to wait. Its precision is greater than its accuracy. But now each resume can have up to 1 second of delay while you wait for the tick to occur. No need to wait; you can ask the RTC to interrupt you on ticks. That will get you very close to knowing the accurate RTC time (based on your interrupt latency). Then set up the kernel to awaken 0. seconds from the previous tick, and when you're there, read the RTC registers continuously until it actually changes. Then you're within a microsecond or better of knowing when it ticked, without creating much delay. Your estimate of the time will be OK on resume, get better after the first tick, and be completely accurate at the second tick. And you can arrange your estimate so that as you improve it, time never moves backwards, only forwards, to avoid strange effects. OLPC is in the market for a dedicated (and local) kernel hacker to work on things like this but right now we don't have one. Until we get one or until someone in the community works on it this will just be ideas. Right. But ideas that will, in theory, double your battery life -- and finally put to use all the incredible effort that went into making hardware that would reliably suspend and resume, tickless kernels, user mode programs that don't awaken unnecessarily, etc. We have also veered off thread...The original questions/responses were on what happens _now_, not what we should be doing. I'd like to understand the existing issues first. I'm sorry I don't have insight into those to offer :-/ John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Recommend build for XO-1.0 deployment
On Sun, Aug 1, 2010 at 8:59 PM, Tabitha Roder tabi...@tabitha.net.nz wrote: Does anyone have a build they would recommend? I believe the laptops are locked, so it will have to be signed. At this point I would recommend the 10.1.2 development builds -- but as James points out, they are not signed. But it's so easy to unlock locked laptops, and then you can run any build you like. OLPC has for more than a year recommended that everyone run unlocked laptops unless their particular country has a need to lock them. Unlocked OLPC laptops are just like ordinary laptops that you might buy in a store; no more and no less secure. There is no reason to lock a laptop, and no reason to keep laptops locked, unless you have a major theft issue in your country's laptop program. I think the whole reason many early laptops went out locked was that the local projects thought that somehow a locked laptop was more secure or better than an unlocked one. Field experience has proven the opposite. Unlocked laptops give the project more control, easier support, and more options. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend: RTC wakeup, sleep
My power logging scripts originally used 'sleep'. But what I found was that if the time-to-suspend was shorter than sleep then the script would have cases where it would never run. Are we experiencing confusion between autosuspends and lid-close suspends? By design, autosuspends should not change the timing behavior of programs; the idea is for the computer to act the same, but do so using less power. I seem to recall a lot of discussion about what happens to sleeps and other interval timers during the POSIX standardization process. They ended up with POSIX clocks which offer both realtime and monotonic timers, so programs can specify which behavior they want. These were designed to deal with time warps when a clock is moving unusually -- either via settimeofday() or via adjtimex(). A manual suspend such as a lid-close suspend acts like a forward time warp, in that user processes get no chance to run, then suddenly the time is much later. This book about internal Linux kernel architecture discusses this somewhat: http://book.opensourceproject.org.cn/kernel/kernel3rd/opensource/0596005652/understandlk-chp-6-sect-6.html My suspicion is that POSIX punted, i.e. the old Unix calls such as sleep() have undefined behavior during time warps. If you want better defined behavior, use the new POSIX calls. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend: RTC wakeup, sleep
By design, autosuspends should not change the timing behavior of programs; the idea is for the computer to act the same, but do so using less power. Autosuspend and lid-close suspends are identical in function. The only difference is the allowed wakeup source. The CPU is turned off. All timing save the RTC (and EC [1]) is stopped. These two suspends are only identical in function in the EC. They need not be identical in the kernel. With the RTC you have a 1 second ambiguity There is no 1-second ambiguity in the RTC. The CPU can only read out a value accurate to 1 second, but the CPU can tell precisely when the RTC ticks from one second to another, which gives it much higher precision if it's willing to wait. Its precision is greater than its accuracy. As man 8 hwclock says, The control program can read or set this clock to a whole second, but the control program can also detect the edges of the 1 second clock ticks, so the clock actually has virtually infinite precision. See also the discussion in the initial comments in hwclock.c: http://www.sfr-fresh.com/linux/misc/hwclock-2.32.tgz:a/hwclock-2.32/hwclock.c and the timing precision of the EC is not suitable for accuracy over longer periods or temperature changes. (its RC based) If it's within 10% or 20%, the EC's resistor-capacitor based timing is accurate enough for the kernel's purposes in doing short suspends of the CPU invisibly. It's unlikely that the kernel will decide to suspend for more than an hour, say; probably some daemon or kernel code will be scheduled to wake up before then. (The invisible suspend code can set an upper limit and force a wakeup every 10 minutes, for example, if it thinks that's prudent.) The kernel can initially err on the side of waking early. After each resume, it can accurately measure the inaccuracy of the RC-based timer on that suspend. Then it can improve its estimates to let it the next suspend wake later and thus waste less power. Of course it will always need to keep waking early enough that a temperature change that alters the timer's inaccuracy won't make it miss a deadline, but for the expected short sleeps of under a minute, there isn't much time for the temperature to change while suspended, even if the laptop moves from sun to shade or vice verse during that minute. The kernel in XO-1 has at least two ways to accurately measure the duration of an EC timer based suspend. One is to use the CPU clock to count subseconds since power-up, and then watch for an RTC clock tick. When the RTC ticks, subtract the subsecond count from the CPU clock, and you'll know exactly when the CPU resumed. A second way is to leave an MFGPT timer running during suspend. There are one or two timers that can't wake the system, but which can count while suspended, and at high accuracy. See http://dev.laptop.org/ticket/6053#comment:7 and subsequent comments. I haven't examined the XO-1.5 timer situation. So with the system as it stands there is really no (good) way to accomplish a zero timing impact suspend. There are clever ways to do it despite the limitations of the hardware. When the CPU restarts after a suspend, the kernel can decide how to treat sleeping processes. In a suspend that's intended to be invisible, the kernel already knows it asked to be powered down for a shorter time than any pending userspace sleep() call or kernel timer queue entry. The kernel can figure out how long the suspend actually was, to high precision, and can then awaken the user process or kernel task at the proper time. A lot of this is explored in http://dev.laptop.org/ticket/6053 (Clock drift during suspend/resume), http://dev.laptop.org/ticket/4606 (XO can't resume from suspend at a particular time set by software), and http://dev.laptop.org/ticket/3359#comment:3 . These are 3-year-old bugs, so it's unsurprising if you've forgotten their contents, but since I did a lot of the analysis of how we COULD do invisible suspends, I remembered where to look for the details. John PS: Invisible suspends will work much better if you fix #9054 as well, pulling 700ms out of the resume path and making it effective to suspend the system even if it needs to reawaken a few seconds later. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Idle suspend instabilities on XO-1
I'm happy that we experimented but I think it's too early to turn on idle suspend on the XO-1 builds, like we have attempted for 10.1.2. You've enumerated the downsides -- what are the upsides? Does it double battery life in normal use? John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Uruguay violates GPL by deleting root on OLPCs
Ignoring the fact that some deployments ship without root access. Is the practice of completely locking-down the laptops something we'd even want to encourage? Shipping the laptops TiVoized like Uruguay does has put them into serious legal trouble. OLPC should definitely not encourage anybody else to do this. Why bankrupt your project by losing a copyright enforcement lawsuit? Shipping the laptops without root access is a direct violation of the GPLv3 license on a dozen packages (probably 50+ packages in later Fedoras). They have shipped binaries, while using technological means to deny the recipient the practical ability to upgrade or replace them with versions modified or chosen by the recipient. Only an idiot would distribute hundreds of thousands of units while setting themselves up to pay the Free Software Foundation any amount of money they demand. (Given the way OLPC and Uruguay have ignored the notice that they're in violation, for years, I do hope FSF extracts both future compliance, and its next ten years of operating expenses, from these scofflaws.) Or does Uruguay think, Sue us for copyright violation in our own courts -- we'll make sure you lose?? In other words, do they just brazenly steal the GNU Project's software, knowing it's wrong? John Gilmore ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Eben Moglen: Re: Uruguay violates GPL by deleting root on OLPCs
[I didn't see a copy of this come through on devel, so assumed that it bounced because he's not a recipient. --gnu] Date: Wed, 7 Jul 2010 12:47:26 -0400 To: martin.langh...@gmail.com, g...@toad.com, ber...@codewiz.org, devel@lists.laptop.org, sugar-de...@lists.sugarlabs.org Subject: Re: Uruguay violates GPL by deleting root on OLPCs In-Reply-To: Martin Langhoff's message of Wed, 07 Jul 2010 11:21:27 -0400 aanlktikxexio9oikse4dugp2bdo55ain8xn0mruzh...@mail.gmail.com From: Eben Moglen mog...@softwarefreedom.org I don't know what the technical details are, but it sounds as though the right people are present in the conversation. For GPLv3 programs-- which would include bash, tar, and Samba as well as the toolchain, to take some examples--the requirement is for installation information to be provided to anyone who requests or receives source code. Installation information is defined as any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in [the laptop] from a modified version of its Corresponding Source. That requirement can be satisfied, for some programs, by informing the user how to run a replacement copy, without root privilege, out of the primary user's home directory. Some programs might require escalated privileges in order to install and run a modified version (of a daemon, for example). Side-stepping the OS on the hard drive, booting a system on removable media, and then installing the new version on the fixed disk would be a method within the meaning of the license in those cases. Details are crucial. Working with relevant parties to ensure compliance is SFLC's purpose in a situation such as this. We'd be happy to help if there is interest. Regards, Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Uruguay violates GPL by deleting root on OLPCs
Please explain your statement that lack of root violates GPLv3. Couldn't the owner of the system insert a SD card with a developer's version of Linux, mount the internal drive of the XO, and tinker with the installed packages as root from the external OS? Does GPLv3 expressly mention root access? The laptops refuse to boot a developer's version of Linux. They require a signed kernel and initrd. Some people call this DRM; it's definitely TiVoization (check Wikipedia if you don't know the term). I think Ubuntu disables root logins, but allows sudo access for root permissions. Is that a violation of the GPLv3? As Eben explained, the GPLv3 doesn't require root, it just requires that you be provided all the info you need to install modified software of your choice, in the environment in which the binaries were shipped. su is fine, if documented, and it is. John PS: Get a clue, folks. This is bigger than OLPC. You've been spoiled by 50+ years of general purpose computers without cryptographic access controls. Four big oligopolies (Intel, Microsoft, Hollywood, and NSA) are all trying to wipe out the general purpose computer and replace it with one that only allows running approved software. They've jiggered the law to make it illegal to circumvent such controls, even if you own the hardware and all the software is free. All the Apple products except the Macintosh are already this way (and they produce more revenue for Apple than the Macintosh), and their customers have barely noticed or complained. It gets harder in every generation of iPhones to jailbreak them, even if it was legal; they're closing in on shipping products that close *all* the exploitable holes, leaving the buyer totally at Apple's mercy. If even the free software community shuts up and demurs when one of our flagship projects locks down the hardware to disallow freedom, why should *any* evil empire delay going right ahead and screwing every consumer, every curious questioner, and every tinkerer? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: AIR + Flash/AIR issues wikis
There's a long standing hard bug of non-accelerated video on Linux (not just XO). That hurts hurts HURTS any Linux device. There is some backstory on that -- it's whether to use Xv or not, whether the video frames can be grabbed from the Xv pipeline to overlay stuff on top or not - early Flash9 used Xv, then stopped, and vid performance sucked ever since. Prerelease versions of gnash now have accelerated video on Linux. It uses the terrible Intel-designed vaapi (it only accelerates video codecs that Intel approves of, and is not readily extensible). But it's better than nothing. Is there a vaapi accelerated video implementation for the XO-1.5? John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
I looked at the kernel patch for emulating the missing instruction (long NOP). It looks like it works, and only needs minor patching-up for security enforcement. The big argument on the Linux kernel list was about not having a little kludge like this, which is likely to grow to emulate many other things and become unmaintainable; some people would rather use the whole virtual-CPU emulation mechanism for this, which is much more heavyweight, but also a lot easier to test and validate. If having to maintain a 20- or 50-line kernel patch is the price of being able to move forward onto using unmodified modern Fedora release repositories, I'd say the choice for OLPC is very clear - do it. The change that introduced the use of this instruction was in the binutils (assembler) rather than in gcc. I believe it is used when a .align directive is given in an executable segment. When optimizing, GCC has been aligning some loops on cache line boundaries for some time (by inserting nop padding BEFORE the loop), but previously, the assembler was filling with various N-byte NOPs that would work on any x86. It has been improved to pick faster ones on modern hardware. The relevant code is in gas/config/tc-i386.c, function i386_align_code(). I haven't pinned down the actual code change that bit us, and perhaps it's just the change in -march and/or -mtune options used by Fedora when calling gcc. Gas is careful to only use NOPs that are compatible with the specified instruction set, if one is specified -- but Fedora is specifying the wrong one for our purposes. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
2) FESCo (Fedora Engineering Steering Committee) is dealing with the
issue upstream [1][2] in Fedora with the view of getting it fixed
upstream for F-14 or at the very least clarified. It was agreed in
F-12 that the Geode LX would be supported and that decision wasn't
discussed otherwise. Please add to the conversation on the ticket or
the list. It might be worth seeing the outcome of this before we go
and reinvent the wheel again.
Peter
[1] http://lists.fedoraproject.org/pipermail/devel/2010-June/137070.html
(but thread goes back to April)
[2] https://fedorahosted.org/fesco/ticket/387
It's nice to know we have the attention of the right folks. But there's
some useful info we could give them for tomorrow's FESCo meeting.
Do we know which i386/i686 packages in F13 actually contain NOPL
instructions? Apparently, glibc does contain them, due to the report
here from the beta:
https://bugzilla.redhat.com/show_bug.cgi?id=579838
If fixing F13 would only require rebuilding five, ten, or twenty
packages, then fixing it in the F13 repos (for everybody, not just for
OLPC) is totally doable. If it requires a total rebuild, then the fix
could only occur in the next Fedora release.
This message suggested that the NOPL instruction doesn't appear in any
of the coreutils programs:
http://lists.fedoraproject.org/pipermail/devel/2010-June/137144.html
To figure this out, I downloaded and booted the F13 i686 LiveCD and
did this:
for x in {,/usr}{/bin,/sbin,/lib}/* ; do
echo $x
objdump -d $x | grep nopl
done
It shows nopl's in:
/sbin/ldconfig
/sbin/mdadm.static,
/sbin/sln
/lib/ld-2.12.so
/lib/ld-linux.so.2,
/lib/libanl-2.12.so
/lib/libanl.so.1
/lib/libc-2.12.so
/lib/libcidn-2.12.so
/lib/libcidn.so.1
/lib/libcrypt-2.12.so
/lib/libcrypt.so.1
/lib/libc.so.6
/lib/libdl-2.12.so
/lib/libdl.so.2
/lib/libm-2.12.so
/lib/libm.so.6
/lib/libnsl-2.12.so
/lib/libnsl.so.1
/lib/libnss_compat-2.12.so
/lib/libnss_compat.so.2
/lib/libnss_dns-2.12.so
/lib/libnss_dns.so.2
/lib/libnss_files-2.12.so
/lib/libnss_files.so.2
/lib/libnss_hesiod-2.12.so
/lib/libnss_hesiod.so.2
/lib/libnss_nis-2.12.so
/lib/libnss_nisplus-2.12.so
/lib/libnss_nisplus.so.2
/lib/libnss_nis.so.2
/lib/libpthread-2.12.so
/lib/libpthread.so.0
/lib/libresolv-2.12.so
/lib/libresolv.so.2
/lib/librt-2.12.so
/lib/librt.so.1
/lib/libSegFault.so
/lib/libthread_db-1.0.so
/lib/libthread_db.so.1
/lib/libutil-2.12.so
/lib/libutil.so.1
/usr/bin/gencat
/usr/bin/getconf
/usr/bin/getent
/usr/bin/iconv
/usr/bin/locale
/usr/bin/localedef
/usr/bin/rpcgen
/usr/bin/sprof
/usr/sbin/build-locale-archive
/usr/sbin/glibc_post_upgrade.i686
/usr/sbin/iconvconfig
/usr/sbin/iconvconfig.i686
/usr/sbin/nscd
/usr/sbin/prelink
/usr/sbin/zdump
/usr/sbin/zic
There are no nopl's anywhere under /lib/modules. objdump couldn't
examine the mashed kernel image in /boot, but I bet it's free or
almost free of nopl's.
Virtually all of these files are generated from the libc sources
(except two executables statically-linked with libc). In short, this
is almost exclusively a glibc problem. It's probably just a bug
introduced into the glibc configuration or makefile in F13.
Fedora Bug 579838 should be reopened -- it was inappropriately closed
by Andreas Schwab on 2010-04-07. (Jakub's comment wasn't pretty, but
he didn't close the bug - Andreas did. But closing bugs
inappropriately to make your bug stats look good is rampant in every
development org - e.g. I regularly complain to Ubuntu about this.)
This is not a dead issue for F13, and we should seek solutions within
F13 as well as outside it.
Oddly, F13 offers release CDs and DVDs only for i386 (and x86-64),
but offers live CDs only for i686 (and x86-64). It is completely
unclear from the documentation (which suggests using these
interchangeably) whether the i386 DVD is really compiled for i686 or
i386. See:
http://fedoraproject.org/en/get-fedora-options
(hover over the Download Now buttons to see which ISO image each
one offers.)
http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/ch-new-users.html#sn-which-arch
John
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: What's the current status of suspend/resume?
I've lost track of this area. Could somebody please give me/us a review and/or update. On which hardware? XO-1 had a lot of niggling bugs around the edges (all documented in trac). The largest was that the Linux kernel does busy-waits for the USB bus's startup delays for sequencing power and signalling. It took about 900ms to resume, instead of the expected 100-200ms. As far as I know, nobody is working on fixing that. Turning on the USB bus is on the critical path to receive any packets that the WiFi chip has for us, but it can be done with timers and interrupts, allowing the rest of the system to come up more quickly, run user processes, handle keyboard/mouse input, etc, in parallel with bringing up the WiFi interface. This is http://dev.laptop.org/ticket/9054. The next worst of those was that we could only wake up on 1-second boundaries because the system was only wired to wake up when the realtime clock ticked (in classic MSDOS style: Wake this machine at 8AM please). That's http://dev.laptop.org/ticket/4606. We had a fix planned, which was for the EC to support sub-second timing and wake the CPU when instructed. I believe that Richard wrote the EC support, but the Linux kernel has never used it. Fixing these two problems would allow the system to suspend even when user processes are running and expecting to wake up in a few seconds, without messing up the user processes. Currently, when it suspends, it goes down hard and only comes back up when a key, mouse, or packet arrives (and takes almost 1s to come back). This causes various troubles like the screen brightness not being changeable during suspend because the machine can't wake up to dim it, and suspend not being viable unless the machine is very idle. There is also a layer of bugs, most of which were never chased down to a fix, most of which relate to I/O devices screwing up when we suspend. For example http://dev.laptop.org/ticket/6528, Packets that wake the laptop from suspend are often lost; or #3732, arp broadcasts don't wake up autosuspended laptop. There were numerous bugs producing dozens to hundreds of useless wakeups per second. The most egregious was #4680, Sugar apps' pygtk main loop polls 10 times a second, always. Many of these, including that one, have been fixed somewhere upstream. I don't know whether modern Fedora (or any OLPC release) has all those fixes, but have heard that new releases only make small numbers of wakeups per second. Fixing all of the above would let the kernel invisibly autosuspend whenever it had no processes to schedule for half a second or so (and based on recent history, expected no TCP packets to arrive for a similar period). I'm not up on the XO-1.5 suspend/resume status at all. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Free software for an ARM tablet?
If somebody gets Android running on a tablet and that somebody actually honors the GPL, it's likely that much of the work of a real Linux port has been done. Except that I've heard from a very credible source that in existing Android *phones* there are 9 pieces of essential yet proprietary software, which they have shoehorned into the GPL kernel by writing a GPL'd dummy driver that lets the real (proprietary) drivers run in user space. One, for example, calibrates the accelerometer, and is considered highly proprietary by the *%%## who build the chip. OLPC has dealt with this problem before (honorably), and it would be a real shame for OLPC to give millions of units of chip sales to a company that would do that to its customers and developers. (But: the VIA cpu chip and its companion chip in the XO-1.5 still don't have published specs. Nor the codec chip.) Then you'd have to throw away the deliberately-differently-encoded Android Java runtime and hacked-to-be-incompatible libc and such. But that part isn't much work at all. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Idle-suspend a little too intrusive to user experience?
...the biggest problem area in terms of suspending and not coming back is the network, and without wake-on-precisely-what-i'm-waiting-for, that's problematic. Most wireless and Ethernet chips can be configured to interrupt or wake on precisely what you're waiting for. They discard all packets for other network addresses. They discard 98% of multicasts that you aren't listening for. They even discard broadcasts if you ask them to. The really smart ones can ignore all broadcasts except for ARPs that are for this machine (there's already a kernel interface for this, ethtool -s wol a, which we got working late in the XO-1.) I don't know what wireless chip made it into the XO-1.5 (the XO-1.5 hardware spec wiki page just says a QMI WLAN module with no data sheet, and the PDF page is even less informative), so I don't know just how fancy its wake-on-lan configuration is. If our new chip is not fancy, it might even be possible to cheat with a mite of code to the resume sequence in Open Firmware. This would look for an incoming ARP that wasn't for us, and quickly put us back to sleep before turning on the DRAM and video and such. Before going to that premature optimization, we should see how many times our suspend-on-idle kernel wakes up and then immediately decides to go back to sleep. If it's uncommon, no need to bother. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #10045 HIGH 1.5-sof: XO-1.5 Record audio/video are out of sync with each other
There's a classic Unix problem with distribution of disk access times that relates to how older Unixes did sync -- every 30 seconds there was an instant traffic jam at the interface to the drives. This has been studied to death; here are some assorted papers: http://www.cis.upenn.edu/~jms/usenix.pdf Has graphs from old DEC hardware that look similar to XO-1.5. http://www.usenix.org/events/osdi06/tech/nightingale/nightingale.pdf Good references section. http://www.eecs.umich.edu/Rio/papers/chen96_2.pdf Studies ext3 performance in depth. Most such studies looked at read() times because the usual workload has far more reads than writes. Odd delays in write() times are interesting. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Idle-suspend a little too intrusive to user experience?
Is OLPC's Idle-Suspend not waking up the machine when the next process wants to run? No wonder you're having all these problems where it suspends and doesn't come back. Don't fix it with 27 kludge patches (to audio players, to network managers, etc), just fix the kernel so the suspend ends when the next process wants to run. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: the old keypad behavior gets too sensitive
I have been running into this with the XO-1.5 prototype but thought it was either a prototype issue or my fat fingers.. however I noticed it with my kid also. Pretty much the same behaviour you list below.. in low humidity the cursor will move without touching the keyboard. Is there anything I can do to help debug/fix this for people (New Mexico is pretty much always low humidity) I have seen a symptom in several Ubuntu Jaunty and Karmic machines in which the cursor runs to the upper right corner of the screen, for no reason. This is with different input devices (HP mice, Acer laptop trackpad). It occurs both while scrolling by mousing a scrollbar, and when typing (the active window loses focus and the typing goes where it doesn't belong). My tentative conclusion is that it's caused by a longstanding Linux kernel bug. If true, this bug is also likely to be in the XO operating system, and may be confounding your ability to detect and debug hardware or firmware problems with the XO trackpad. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: resizing rootfs to fit the disk
but again: where should such a flag go? is there a precedent for such things? /.i-am-a-hidden-flag ? Safety would argue for doing the opposite: * Build the installation images to contain a file like /.resize-root-once. * If that file is present ** Remove the file ** Sync the disk ** Attempt the online resize ** Sync the disk again * If that file is not present ** Do nothing. Leave the filesystem alone! The idea of a Linux system that, when it boots, resizes the root filesystem every time to try to fill up the entire drive it's on, fills me with horror. I prefer to partition my disks myself, thank you. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: surprisingly early suspend
Perhaps the suspend/sleep process should be disabled until the laptop is assigned a child's name and color preference on first boot. I find sleep to be more disorienting, as the screen is turned off (my laptop broke!) and it takes a press of the power button, not the keyboard, to wake the laptop up. What ever happened to making suspend invisible on the XO, and happen between keystrokes? I thought the new hardware was going to fix all the issues that prevented us from enabling that in the old hardware. (Suspend -- turning the CPU off -- should be separate from dimming the screen, and should also be separate from sleeping. If you can suspend and can dim, maybe you should sleep after an hour or something, but with the CPU and RAM off and the backlight off, how much does sleep really save?) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 keyboard
:-) you're right -- it _is_ awesome. wad seems to have mastered the art of getting the laptop to really go together right after the conversion. One of the things I asked wad to improve when he was looking for things to fix for the XO-1.5 was the incredible flakey keyboard. Everyone knows when I type an email message on an XO, because it's always so full of typos that it's just not worth going back to fix them all. One of my XOs has a CTRL key that would press itself at random intervals, which was really fun under Sugar. One would think that a keyboard designer would make very sure that the shift-keys were more reliable than the letter keys (since they get pressed a lot more often), but in the XO-1 it was the opposite. I eventually tried to batter my way through the alleged OLPC parts-and-repair process (and failed); but somebody nice took pity on me and mailed me a spare keyboard. Wad said improving the keyboard wasn't on the main program for 1.5 but he'd see what he could do. Did anything happen? John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC hardware: what if there was an SDR modem / chipset?
This whole discussion has been happening on the wrong mailing list. Please move it to discuss-gnura...@gnu.org (subscribe at http://www.gnu.org/software/gnuradio/mailinglists.html). They use and maintain the GNU Radio free software that does SDR, and also design and build the USRP hardware that's the cheapest and most capable hardware currently available for SDR. They'd be happy to hear about new chips that make cheap and more capable SDR's possible. At one point I tried to get someone to design an SDR for a new generation OLPC -- something that would cost less than 15c per deployed unit, perhaps using a few analog components and a spare A-to-D/D-to-A on a sound chip. For example, something that would receive AM or FM radio, or transmit AM or FM at low power. For a super stretch goal, receive analog TV signals, making the laptop capable of being a TV set. And be another sensor that the kids can learn about the world through. The biggest cost would probably be the additional connector for an external antenna. Even that initiative went nowhere at OLPC (mostly because no experienced analog engineers stepped up to design such a cheap circuit). OLPC can't afford to include even a $2 chip (plus analog components, power supply, connectors, wires, antennas, etc) for such a marginal use in their low cost product. So please move the discussion to a place where you'll find researchers *happy* to build SDR chips into their next hardware project. John Gilmore ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] New release of F11 for the XO-1 - Build11
2GB SD card in my XO, and I have Firefox on it. I installed the ePubReader plug-in for Firefox. This runs nicely and allows you to view eBooks in ePub format, which is the up-and-coming open format for books. You can get free ePub eBooks from several free sites, including books.google.com, www.feedbooks.com/publicdomain, and gutenberg.org. Also, the Internet Archive (www.archive.org) has more than a million books scanned and available in ePub. You can also reach them through a possibly nicer interface at openlibrary.org. (All of those books are also available in PDF, plus other formats, and are also readable using a Javascript-based online reader that should work in most browsers). John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New release of F11 for the XO-1 - Build11
Keyboard and mouse will not wakeup from sleep. Can be fixed by disabling power management in Sugar. Is there any reason for cutting release after release that don't work unless end users disable power management (sometimes twice!)? Surely if you can't fix the bugs, you could at least ship the release with power management disabled by default, so it works out of the box. Or, one step up from that, have it figure out which hardware it can reliably suspend on, and only have it enable suspend by default on that hardware. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Android, OLPC, and native hosting
Since when did it take more than a GB of RAM and 4GB of disk to host an IDE ? I think that was Emacs 23. No, that was Eight Megs and Continuously Swapping. I.e. in an amazingly large and expensive Sun Workstation with 8 *megabytes* of RAM, emacs would still make the system page-fault at a high rate. Those young 2nd-graders just don't know what they're missing... Why in my day, we had to disassemble 6502 machine language just to peek and poke the screen into high-resolution character graphics mode. We had to put little pieces of tape over the holes in our punch-cards to save paper. Solar powered gigabyte WiFi Linux machines? Our school's calculators had neon NIXIE tube displays! John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Android, OLPC, and native hosting
I would argue that an operating system that doesn't natively host its development tools is not appropriate for OLPC's target audience. Does the XO-1 host its own development tools? I don't think anyone has ever rebuilt the system from source code on an XO-1. I don't even know anyone outside the OLPC office who *has* the source code for an XO-1 software release. (At least Fedora and Ubuntu and Debian cut a source release to match each of their binary releases, and hundreds or thousands of people download it.) Could the XO-1.5 host its own development tools? More likely, but again I don't think anyone ever has. Perhaps someone rebuilt a few packages from source, natively, while debugging. Must have been someone with great Internet access to download compilers and such, and great knowledge of where to *find* the source code in the wilds of the Internet. Still that's a step forward. Does Android not host its development tools because it doesn't run the X Window System? Since X already runs on most of the hardware that Android does, that wouldn't be too hard to remedy -- and would benefit the whole Android community. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-3 super-o-fficial
What makes you think that this will be a proprietary version of Android? Android is licensed Apache 2.0 with kernel patches as GPLv2[1], although there have been some proprietary apps and customizations on top. I hadn't looked closely enough to see the detailed licensing. But I'd seen the news stories about Google cease-and-desists to the guys making improved free versions. Is a useful fully-free version readily available, as a practical option? (This is mostly off-topic for OLPC, unless there's a plan to try Android on XO hardware, which might be amusing. 20,000 apps and an active developer base might be an attraction, versus the hundred or two Sugar apps.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-3 super-o-fficial
We don't necessarily need to build it, Negroponte told Forbes. We just need to threaten to build it. Looks like Notion Ink has already done so, sort of: http://www.slashgear.com/notion-ink-tegra-android-smartpad-uses-pixel-qi-display-1866308/ The OS is proprietary (android), it would probably fail it you dropped it in a puddle and it has too many radios (GSM, UMTS, GPS, and Bluetoot, besides WiFi) -- but at least it has connectors! Remote villages shouldn't waste power with inductive charging, and can you imaging debugging a cranky XO-3 via multitouch? See also: $99 NVIDIA Tegra MIDs in development http://www.slashgear.com/99-nvidia-tegra-mids-in-development-android-ported-to-tegra-1734880/ John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-3 official
I would take it all with a large dose of salt. Also, as usual, the left hand at OLPC doesn't know what the right hand is doing. The press release isn't on www.laptop.org, nor is there anything in www.laptop.org or wiki.laptop.org about the XO-3 (or even the XO-1.75). The press release (which is on Business Wire) links to 30 megs of nice publicity photos -- which nobody can download any more, because they're on a foolish hosting site that has reached its download limit. Etc. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] XO 1.5 to XS-onXO1 behavior
as Fall semester finishes) but I have a XS-on-XO1 running at home and when a XO1 associates with it, the XO1 gets a 172.18.xxx.xxx address (school mesh portal). When the XO1.5 associates with school-mesh-0 (I have to click on it in the Neighborhood view) the association happens, but the XO1.5 gets 169.254.xxx.xxx address, and beyond that the network is unusable. that's expected, unfortunately. The XS-on-XO runs an active antenna / mesh gateway in the sense of 802.11s. As the current XO-1.5 drivers/firmware don't talk 802.11s, it won't work. In that sense, the XO-1.5 is the same as any other 802.11a/b/g device. There are two paths to address this - get the hostap / thinfirm driver+firmware combo working again. It was last seen working on a 2.6.17 i think. - get 802.11s on XO-1.5 going. this is not trivial... The least common denominator in the XO-1 and XO-2 clients is a connection to an access point. So making the XS (on any hardware) provide a standard 802.11 access point would probably be the easiest path forward. As I recall there was some step in the XO-specific school provisioning (antitheft DRM?) that only works over the mesh. So if that hasn't been fixed, either deployments would have to turn off the DRM, or OLPC would need to revise the firmware and/or initrd to handle this interaction via ordinary 802.11 access. Or they could just throw away their DRM-choked devices, as many others have had to do when the big DRM server in the sky went away, and take a lesson from that. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
#10 0xb67fae59 in gst_xvimagesink_xvimage_put (xvimagesink=0x8364160)
at xvimagesink.c:864
src = {x = 134867456, y = 140758336, w = -1259457208, h = 1}
dst = {x = 137730309, y = 3, w = 0, h = 137691184}
result = {x = 0, y = 0, w = 322, h = 241}
draw_border = 322
__PRETTY_FUNCTION__ = gst_xvimagesink_xvimage_put
The src.w value is in the same range as the Xlib function addresses;
-1259457208 is 0x4B11CAB8 and as can be seen from the call frame #9
the XSync function is at 0x4b0eccf7. The other values seem
irrational. This may be evidence that the stack has been corrupted
somewhere else, or the values not initialised.
Just to rule out going too far down a blind alley...
Try adding a printf of these values to the code there, rather than or
in addition to using GDB. GDB may not be 100% reliable when accessing
variables from optimized code. (I used to maintain GDB, and I worked
very hard to make it never lie to you, but that precept hasn't always
been followed in the intervening decade, and optimizations have also
gotten a lot more complicated.)
Or try compiling that code without -O and see if that changes either
its behavior, or what the debugger reports.
John
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: 1.5 - gnome-packagekit?
One disadvantage of doing this is that it would harm the use of olpc-update -- pristine updates would fail. And also the software would be silently lost when an olpc-update happens, which is now Good thing we reinvented the wheel here. RPM packaging was too complete and flexible for kids or teachers (or school administrators). They're so much better off NOT being able to install any of 5,000 packages freely contributed by talented programmers all over the world. John :-( ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: About 8.2.2 unlocking
I think for the case of Cambodia with many small deployments (educational NGOs got XOs donated from G1G1/OLPC or other donors), no signed builds probably means that the XOs don't get updated anymore. Are you trying to say that the Cambodian OLPC recipients don't have any serious chance of jailbreaking their laptops? Installing an OS release is a fifteen minute process, whether it's signed or not, once you disable the DRM. The DRM is the only constraint (other than losing all the data you had in the laptop). Perhaps instead of coming with a signed build, new releases should come with a monster keyring that will unlock any known laptop and then install the release on it. Hmm, another way to do this would be for OLPC to sign one last build, which installs new firmware that unlocks any laptop except those built for specific large-scale deployments (which have internally decided to continue the DRM and sign their own builds). But whether the unlock is automatic or must be done manually, at least every new installation on a random XO will leave that machine unlocked, thereby reducing the long-term problem. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OS and Firmware testing for XO 1.5 B2: gnash
Gnash and youtube is a no go. No error now, just a black screen Within the last month, Youtube changed their default player to require Adobe Flash 10, including ActionScript 3. Gnash does not yet implement AS3 properly -- that's why you got a black rectangle. The (shrinking) gnash team is working on this, but they won't have even an internal version that plays today's youtube before the end of November -- maybe much longer. There's a hack though: rewrite the URL from: http://www.youtube.com/watch?v=zeeie9l9taM to http://www.youtube.com/v/zeeie9l9taM That uses the old player. (The videos themselves are unchanged, it's just the stupid stuff around the edges, like the Play/Pause button, that's causing the trouble.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Information on XO-1 power efficiency
How well does sleep-between-keystrokes work if I ignore USB? Pretty well -- but check bugs.laptop.org. That's where our institutional memory of the bugs that prevented full blown suspend exists. Search for power or suspend or sleep. If you're serious about working on this, I can spend some time looking in there for the next low hanging fruit. I remember there were some high priority bugs we were trying to shoot. When OLPC had to fire most of the software team for lack of money, and focus down its efforts on what its country partners wanted, Chris and I stopped working on improving power consumption. Has anything interesting changed in this area for XO-1.5? Lots, though as far as I know, auto-suspend on XO-1.5 is not working yet. Is USB device discover inherently slow? Or is the sloth just handling strange cases? Can I speed things up if I only need to verify that devices I knew about are still there? Bringing up the USB bus is apparently *designed* to take a large fraction of a second. After you turn on USB bus power, you have to wait for X hundred milliseconds for the power to stabilize and for any devices to come out of power-on reset. Ditto after you turn on USB signalling. The way to play with this is to unload the USB module from the XO-1 kernel. Then it won't play any part in suspend/resume. (This will lose you the WiFi.) You'll be left with something that suspends in ~250 ms and resumes in ~400 ms as I recall. Resume time with USB is 900 ms. To fix this, refactor the USB startup code so that it runs asynchronously on resume (i.e. it doesn't prevent the kernel from starting to run user programs). This should produce a kernel that resumes in about the same amount of time, whether or not you have a USB module loaded. The trick is probably to manage this in a way that upstream will accept. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: wlan interface (was: first play with new XO 1.5 machines)
I mean the clock in the 802.11 MAC sublayer. This defines the basis of the timing synchronization function (TSF) which is a core part of 802.11. Without synchronized clocks, nodes cannot communicate. I talked with one of the 802.11 experts I know. He's quite sure that there should be no problem on Atheros hardware at least. He has no problem transmitting arbitrary packets at arbitrary times and no problem receiving packets either. is that you get just one channel at a time. ... The TSF stuff looks like an optimization that you don't really need, except perhaps when sending to a receiver that stops listening at certain times. Lame hardware misses out, no surprise. It's for power saving. When 802.11 is used with an access point, the access point can be asked to buffer up frames for battery powered stations, and send an indication in its periodic beacons. The station wakes up for each beacon and can sleep the rest of the time. In addition, 802.11e provides more power-save modes (APSD). See this paper: http://www.redpinesignals.com/VoWiFi-Implementation-with-Single-Stream-802-11n.pdf I don't think that XO-1 WiFi chips ever did any power saving. Don't know about XO-1.5. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: the importance of providing swap space
I happened to have an SD card with me that had a swap partition defined on it. The XO's SD slot was already in use, so I attached an USB card reader (with my card in it), and issued the appropriate 'swapon /dev/...' command. I'd suggest a small enhancement: that when a removable medium with a valid swap partition is plugged in, start swapping to it immediately. That would cause a problem when trying to remove it, though, since Linux doesn't provide a dismount all partitions in preparation for ejecting operation in the GUI. Perhaps this is one area where Sugar could improve on the general Linux GUIs. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: tap-to-click feedback
we tried the synaptics driver initially (when we got the new touchpads) but by itself it caused extremely erratic (perhaps not erratic, exactly, but just way-too-fast) mouse cursor behavior. There seems to be something wrong with general Linux mouse behavior. Even on ordinary optical mice (like the HP I'm using now), the mouse works fine about 98% of the time; then it jumps to the top of the screen inappropriately. (Running Ubuntu Jaunty with 2.6.28-11-server kernel.) I'd noticed this with touchpads and assumed it was a buggy touchpad, but it seems to be a more generic bug somewhere in Linux. The latest Ubuntu (karmic beta) disables tap-to-click by default, which is a regression (see https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/378391 with it's more-than-a-dozen duplicates and see also #441013). It turned out that there was a lot of complicated interaction behind the scenes that would make it work, fail, work, fail, ... with different versions of various packages. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Testing] first play with new XO 1.5 machines
On Oct 20 2009, at 19:04, Tabitha Roder was caught saying: no mesh network showing in neighbourhood My understanding is that mesh is not currently supported in the WLAN firmware for the new chips. I am not sure what the plan of action is in regards to mesh support for 1.5. For laptops to communicate when they're nearby, no mesh is needed. The usable range will be shorter than with a mesh, but on the positive side, XO's should be able to communicate with every kind of device, not just themselves. But I don't know if NetworkManager and Sugar are fully organized to do Ad Hoc networking, presence, messaging, file sharing, etc in the absence of an access point. The mesh channels in the GUI could be converted to ad hoc channels, unless ad-hoc WiFi networking has a protocol for searching all the channels for nearby machines. (Channel-less operation would be simpler for users -- one less setting.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW access from linux - kgdb
it sounded like there was also some thought that the emphasis should be on tools, like kgdb, which can be more general purpose, and more widely used and maintained. to which i'd say, the more the merrier -- i'd love to use kgdb regularly, but it requires a second machine, and it ties up scarce serial ports. so OFW is a win, for my current uses. In theory we could make one OLPC kernel debuggable by another OLPC, just using the WiFi interfaces and a simple matter of software. kgdb should be able to use an ethernet, if the Ethernet driver implements the NETPOLL interface. I think WiFi counts as Ethernet, at least if you use ad-hoc mode, or if you can get the interface brought up (by the usual means) before you need the debugger. You still need two machines, unless the kernel you're debugging is running in a virtual machine. The machine you run GDB on can be any computer, it doesn't have to match the one you're debugging. See: http://kernel.org/pub/linux/kernel/people/jwessel/kgdb/index.html which was readily findable via Wikipedia's kgdb entry. For all I know, OFW has a gdb debug stub in it somewhere, too... John (I used to maintain gdb, in the distant past.) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW access from linux
there's no SysRq key on the XO keyboard, so you'll need to use a break on the serial console to invoke it... Please. If you're going to put this hook in, which I think is a great idea, at least make it work on the standard hardware! And when the operating system is not very responsive. That's when you'll need it for debugging or resetting the system. Without taking the plastic apart, finding a part with no known suppliers, and soldering it to your motherboard. On Sun workstations, the L1-A key combination (pressed in exactly that order, with no intervening keys or key-ups) got you into OFW or its predecessor. (L1 was the top left key in the keypad to the left of the main keyboard.) We shipped it that way for decades without trouble. There are some pretty obscure keys on the XO keyboard -- howabout something like holding down the leftmost and rightmost gradually increasing sized dots keys in the top row, and then pressing the M-for-Mitch key? John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Is Project Ceibal violating the GNU General Public License?
Re: [Sugar-devel] RFH - Journal corruption reports fom 8.2.1 users in Uy Remember that Ceibal XOs have root access locked-down. And I recently found out that since the key-delegation stuff was implemented, we can't request developer keys. Not from OLPC at least, and LATU is not providing that service that I know... Could someone please clarify this? It sounds like Project Ceibal is explicitly violating the GNU General Public License on much or all of the software that it ships: * It provides binaries without source code, and without a written offer of source code. * It provides binaries in a physical form (laptop) which is protected against modification by the end-user, so that those users cannot replace the GPLv3-licensed software on the laptop with later versions. More than 20 packages shipped are GPLv3 licensed, as of 12 months ago, including the Coreutils (most shell commands), tar and cpio (used for software updates), and gettext (internationalization). GPLv3 requires that the relevant passwords or keys must be supplied to the end user -- including both the developer key and the root password. * Some programs are modified, but the modified versions are not marked to distinguish them from the original GPL-licensed programs. There are other less important violations as well (most are documented at bugs.laptop.org; search for GPL). I would be happy to learn that the children receiving these laptops have full access to source code, ability to upgrade their laptops at will, and can tell modified from unmodified software. Please let me know what is really happening in the schools of Uruguay. John Gilmore ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power, time keeping, networking...
Hal, you're asking a lot of great questions. Basically, we could never turn on the original power management design by default, because of too many bugs in the periphery (USB, timers, clocks, network, etc). The bugs are well documented in Trac. The final XO-1 software release added the ability to turn off the WiFi chip when you close the lid, which meant suspended laptops would last ~40 hours instead of ~8. It was hard in the trenches to focus on those bugs (among all the other bugs and feature requests), because each one seemed like a who-cares nit. But from a strategic level, they were in the way of doubling battery life. The team was gradually knocking off those disabling bugs, when OLPC ran out of money and had to lay off most of the software team. They then noticed that it was getting hard to buy some almost-obsolete XO-1 components, and OLPC performance wasn't going up every year like most PC vendors' products. So OLPC put all their power-related efforts into making the XO-1.5, picking a Via CPU chipset with a much better chance of being able to suspend buglessly for subsecond intervals, and improving the charger's solar panel efficiency. The chip and board are working in prototype, production is coming, but they haven't had time (as far as I know) to actually debug deep subsecond suspends on it. So, if you have serious time to be able to help, ask for a prototype board and help with that work. Nobody at OLPC understood the clock goes bad if you suspend problem; they wanted to fix it by slamming in a new clock value every once in a while (like at reboot, or re-association with a school server). Yes, I think the problem is that they're reinitializing with the value from the RTC, without accounting for the subseconds. The XO-1.5 hardware keeps the clocks and interrupts running during suspend, so it should not need that kludge. I encourage you to run NTP on it for long-term testing, and document and/or fix any clock anomalies that you find. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Disk layout for XO-1.5 (LVM reliability)
LVM has a level of appeal. But it caused me a lot of trouble once. I'd built a striped ext2 filesystem using it, so I could get enough disk bandwidth to record raw sampled HDTV radio signals in realtime, using Mandrake Linux and GNU Radio. When I upgraded that system to Fedora a few years later, the new LVM wouldn't read the old LVM's partitions, making that filesystem inaccessible. Turned out there was a bug in the old Mandrake LVM that put the wrong metadata onto the second and subsequent stripes of a partition. The new Fedora LVM checked that bad metadata and barfed. It ended up impossible to fix without going under the hood, understanding the block layout and the metadata, and doing some hand editing of the disk. It was also impossible to copy the data out while keeping the old disks read-only, violating another of my long-standing sysadmin strategies.(*) Ultimately there wasn't that much under the hood -- LVM is a simple format -- but it didn't provide the bulletproof reliability that I've come to expect from, say, MSDOS partition tables. John Gilmore (*): ext3 filesystem recovery also has this dubious property -- even if you mount such a filesystem read-only, ext3 will scribble on it, if if finds an unclean journal, rather than just recovering into its own in-memory data structures. And it gets harder every year to find disk drives (or flash drives) with hardware write-protect switches or jumpers; you end up having to use 'forensic' interface tools to truly prevent software from writing to a drive whose contents you cherish. Every flash drive I stick into a Mac, for example, just so it can read something off the drive, ends up with a root directory full of trash files created by the Finder. The OLPC's Finder used to do the same, and perhaps still does. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar as operating system
More seriously, I don't know if it is possible, but getting Nicholas to stop making a scrambled egg out of the software stack with his omelet analogy would go a long ways to reducing the confusion in the media as well. His continued insistence that Sugar is an operating system--the problem--is being spoken out of ignorance and does not reflect well on either project. As you know better than most, the bulk of the software engineering effort at OLPC has been in support of getting the hardware to boot, drivers, security, power management, etc. All critical tasks, whether or not this is an education project. Sugar (or any other user-facing) bits have always been and still are almost entirely separate from these engineering necessities, as is content development and the bulk of the deployment work. I heard a ring of truth from Nicholas's last remarks, even if you didn't, Walter. OLPC needed to pull off too many miracles to ship the XO-1, and one of those miracles that didn't work was the total rewrite of the GUI. Not just rewriting all the applications, ignoring the hundreds of useful ordinary Linux GUI programs that still don't work on the XO. But making your own window manager and insisting that any program had to be sugarized to run on the machine was Icarus-style hubris. That then required rewriting all the ancillary control panels including power management settings, WiFi selection and passwords (which had endless bugs), two or three brand new software update mechanisms, the DRM, the worm security model, building your own Linux distro releases, etc. It was all fun research, of course. But doing all that stuff *before* being able to ship hardware was makework that OLPC could ill afford. There's still a lot of hardware potential in the XO-1 that the software never got its chops together to exploit -- but three years have gone by and all the work is going into new hardware. The other major challenges were plenty hard enough. Netbook companies figured out that they could ship tens of millions of laptops without all that makework. Some of OLPC's most important innovations (like auto-suspend) have never recovered because they didn't get enough attention. (It's shipping, but not on by default, because of too many serious bugs -- so battery life is half what it ought to be). I'm glad that the team learned those lessons, painful as it has been. The XO-1.5, installing a standard Linux release, with Sugar as an option, will take an order of magnitude less software work, if those lessons have really been taken to heart. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New kernel branch for XO-1 and XO-1.5 development
Given that we are building the for completely different CPU core, we will need different kernel RPMs to make sure our kernel is optimized for the given machine. Optimization is one thing; functioning is another. Fedora *functions* on just about any x86 system you boot it on. A Fedora kernel with OLPC's patches should also *function* when you boot that kernel on any x86. Including XO-1 and XO-1.5. I don't know many people who actually recompile their Fedora kernels and flip all the hundreds of config switches to optimize their kernel for their hardware. The vast majority just run the stock kernel, which optimizes the human cost of sysadmin, future upgrades, security patches, etc. There was a long debate on the Fedora list about desupporting the 586 so the stock distro could be compiled for the 686. The problem is that it breaks *function* for a cheezy optimization of way less than 5% improvement. A tiny number of features (e.g. PAE kernels that use more than 3 GB of DRAM) require a kernel reconfig/recompile; the rest just happen at runtime. OLPC's chip and board support should happen at runtime, like everybody else's. With regard to optimization, OLPC is in a tighter position than most Fedora users, particularly on the XO-1 at 256MB of DRAM. It might be worth shipping a custom-configured kernel for the XO-1 to save a meg of RAM (if it actually did save that much). A better but harder approach would be to fix the stock kernel so it can discard more portions of itself that aren't used on the running hardware. John PS: Someone on the kernel list reported that compiling with -march=atom made his Geode faster than compiling with -march=geode. The theory that each board's kernel would be faster when recompiled for Via vs. Geode should be tested. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] poor man's mmap sliding window on Python 2.5.x
The process is doing a linear read through the file, and is slow enough that it appears only to grow. But if I run another process that allocates a lot of memory, then the kernel does discard pages pages. So are you saying that two identical processes that mmap large amounts of memory, (much larger than the DRAM and with no swap space), then walk sequentially through the memory, will split the memory evenly among them, and will complete in a reasonable amount of time. But one process will get very slow and never complete? Sounds like a reproducible test case like that would be worth reporting to the linux-kernel mailing list, to see if anybody recognizes the bug, or wants to go hunting it. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New kernel branch for XO-1 and XO-1.5 development
Congratulations on the merge. Note that currently there is nothing keeping anyone from installing a kernel meant for one gen machine on a different gen machine. Just don't do that. :) Eventually if both machines are going to run a standard Fedora release, the same binary kernel will have to be able to run on both (and figure it out at runtime, like it does with most other x86-based systems). I'm presuming from your message that that's scheduled to happen some time ... later ... John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Touch-screen OMAP3-based netbook as XO-2 prototype?
The new Touch Book by Always Innovating looks interesting as a possible prototype for the XO-2. It looks vaguely like an ordinary netbook, but the electronics are behind the screen as in the XO-1, as is one of the batteries. So the keyboard half can detach from the screen/electronics package. The two are connected via USB (and the keyboard provides a second battery, doubling life to 10 hrs). $299 in quantity one ($399 with keyboard). Fanless, uses TI OMAP3, internal SDHC card for storage, internal USB slots for connectivity. Open source oriented company, running Linux, XFCE, etc (Ångström Distro, which started from OpenEmbedded). They are willing to license the hardware design, or even give it away to open-source-oriented projects. Motherboard is tiny; photo below. http://www.alwaysinnovating.com/home/ http://www.alwaysinnovating.com/company/design.htm http://www.magniel.com/omaplaptop.html What it doesn't have that the XO-2 wants: * Multi-touch or all-fingers touch-screen-keyboard. * Mary Lou's screens. * Camera * Two screens (however I bet you could attach two of them to each other with a little bit of USB host/host connection glue). FYI. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 microphone testing
Basically, for each configuration (external microphone plugged in, and external microphone not plugged in), I'd like to know the following: - which of the 8 microphones is the one to use - which ports we can turn off In reading the generic Intel HDA codec spec, and comparing it to the http://dev.laptop.org/~dsd/20090629/codec0.txt, it seems that the Configuration Default registers aren't being set up properly by OFW. These registers define the physical location, color, and type of device connected by motherboard wiring to each pin on the codec. E.g. Internal Mic Inside Lid versus External Green Headphone Output 1/8 Jack on Left side. It's also easy to specify Not Connected here. Normally these would be set at power-on by the BIOS, and then read by the software in order to properly label the various audio controls. This design avoids needing separate software driver mods (kernel quirks) for every single model of motherboard or laptop. (These register contents are not retained over a full codec power-down, so the kernel would probably want to save a copy from boot time.) I hope you'll test with both mono and stereo external microphones. The new hardware supports analog stereo input (and mic). It'd be a shame to turn that capability off in software because it was only tested with an analog mic. I think it should be possible to turn the mic bias on and off in software (allowing the mic port to be used as Line In). It should be possible to turn the headphone output into an unamplified Line Out. Testing the OLPC-specific analog sensor input mode would be very useful. Given the stereo input jack, this would give experimenters TWO analog inputs. (Somebody should tell XXX who's uploading a bunch of instructions for making analog sensors on the wiki; e.g. XXX). It would also be useful to test the higher sample rates and larger sample sizes (24-bit samples, at 192 ksamples/sec outbound or 96 ksamples/sec inbound). I've had trouble with those settings on an Acer netbook, for example. If the microphone LED is on a GPIO under software control, independent of the hardware's actual ability to listen on the internal mic, then the LED isn't providing any useful function. (In which case that LED hole might as well be used for sensing the brightness of the light falling on the screen; one of the audio ADC's might be useful for that.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Journal and filenames on USB disks - more leases.sig problems
Is there a better way to do this? Don't use Browse as if it was a real web browser. Don't use the Journal as if it was a real file system. Run Firefox, not Browse. Open up a terminal and do what needs doing. You've just stumbled on one tiny corner of the problem that the Sugar tools don't teach kids about real hierarchical file systems, and don't provide access to real hierarchical file systems. So kids don't get access to source code (for reading or writing) because they can't grok the structure in which it's stored. Nor access to anything else, like lease signature files. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: giving kids a platform to create their future
Personally, I feel it is a mistake for the OLPC project to continue with the concept of the Sugar platform as its exclusive model for an educational computer. The Sugar applications (activities) could just as well be run from the Ubuntu desktop. Then students would actually be learning in an environment that can take them into the real-world that grown-ups occupy on computers, when they are ready to go beyond the Sugar applications. ... Instead of making children do what *we* think is right (I am running 34 years behind my daughter), how about giving *them* a platform and asking *them* to create what they think will be their future? Sounds like a great idea. OLPC hasn't done that. Kids who have never heard of a file or a file system are not going to be able to edit source code. Source code exists in files which exist in file systems. The Sugar interface deliberately obscures the file system in favor of blog-like chronological ordering of activities. No source code control system or interpreter works like that -- including the one the OLPC software is written in, Python. If Sugar taught the kids how to navigate among and examine the thousands of files already sitting on their laptops -- or merely enabled the kids to explore it on their own -- then there might be some case for the Sugar XO being a platform for kids to create their own software. Today that promise remains unfulfilled. John PS: The kids can hack in little, quirky, restrictive environments like TurtleArt or eToys, and what they learn there is useful. But it certainly doesn't prepare them to hack the Python GUI (or any other conventional interpreted or compiled program), nor to take over some or all of the job of evolving the XO operating software. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
