Re: OLPC upgrades
Mitch Bradley w...@laptop.org writes: [...] It's also worth pointing out that the new low-power x86 processors, Atom being the poster child, are still stuck with power-hungry support chips - memory and display controllers. That might change soon, but for now it's still the case. [...] According to the ACPI battery gauges under Fedora 10, my Fujitsu U820 UMPC (Atom Z530, Poulsbo GMA500 MCH/graphics) takes around 6W *total* during light webby operations. - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
Yoshiki Ohshima [EMAIL PROTECTED] writes: [...] You'd be all set if you had Smalltalk source code that you could feed into any random Smalltalk system to create your build tools. While I happen to like C, and it's a very popular way to achieve the required ability to bootstrap, it isn't needed. You even get a certain amount of respect from writing the whole thing in Smalltalk. Use GNU Smalltalk. Your view on systems are way too limited. Where did this any random Smalltalk came from? [...] Please just don't make up new complaint whenever the old one didn't work. He is trying to help you by giving an example how bootstrapping could -- not must -- work for squeak. GNU Smalltalk does it. (It's more elaborate than your write(\x12.., 1), but logical - study it!) Emacs does it. Prologs, LISPs do it. Just about every really free language system I can think of nowadays does it. Once squeak etoys can do it too, these issues disappear. You would no longer have to explain/justify that change set passing is how we do things, because it wouldn't matter. You wouldn't have to explain to others whether .sources/.changes files are separate or internal to the image, which is a distinction without a difference. A new public release could consist of just a fileOut:. You wouldn't have to just *claim* that the new image blob is just that old image blob, plus these .changes chunks, because you could *prove* something even stronger. You wouldn't have to refer others to tools like SystemTracer that you hardly ever seem to use yourselves. You wouldn't have to rely on strangers trusting the long chain of custody/ancestry of the binary image blobs. That worked fine when Smalltalk was a commercial product, but not now, when one's upstream can be any web site with redistribution rights and lawsuit-immune contributors. Even you may rest a bit easier, knowing that the image blob would no longer be a precious heirloom with a murky history embedded within it, but something that can be recreated clean and new on demand. - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
Edward Cherlin [EMAIL PROTECTED] writes: [...] Can gst bring in a .sources file and a .changes file and create a working image? It doesn't have to. It builds gst.im from scratch at every bootstrap. If squeak/etoys did something close to that, many concerns would be pacified. - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
Yoshiki Ohshima [EMAIL PROTECTED] writes: The gist of the argument is that one can't currently know what's really inside an etoys image, except beyond what it itself tells us, BTW, do you now agree that this was not true? If you give me an image file and ask me why the word at offset 0x12345 in the file is 0x89ABCDEF?, I can answer that by opening the image file externally with InterpreterSimulator, examine the bits and answer something like this is a second slot of an Array that points to a number object, and the array is pointed to by this, this and ths object., etc. Yes, that sounds much better (from a security/trust point of view) than having to ask the virtual machine itself to introspect. It stills seems somewhat too low level to enable version control. (Back in the early 90's, when I wrote Smalltalk code for a living (sort of), we ended up having to use external system (teamwork/envy IIRC) to get decent version control and reproducible builds.) It may be a useful exercise to run this over the whole etoys image to identify those parts that are recompilable from the .source/.changes files, those that represent plain data that could be serialized, and perchance surprise objects whose existence was only known to Alan Kay or Adele Goldberg back in the 80s. :-) - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
Robert Withrow [EMAIL PROTECTED] writes: John and others seem to be making the argument Only seem. that unless something is technologically similar to GCC (in the way it is distributed, developed, and coded) it can't be --- picking a term --- open source. [...] Not at all. The gist of the argument is that one can't currently know what's really inside an etoys image, except beyond what it itself tells us, and cannot even be rebuilt from the sources it claims to contain. Someone else threw out the Thompson compiler hack and GCC as if it were an answer to this concern. Instead, it turns out that GCC is on the other (positive) extreme of bootstrappability. - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
Hi - On Sat, Jun 21, 2008 at 12:41:52PM +0200, Bert Freudenberg wrote: [...] (Sorry, this is probably OT for this list.) Considering the age of this smalltalk-derived image, is there some reason to be convinced that it contains no code/data other than that could be regenerated from sources today? [...] [...] The images contains instances that were created interactively for which there is no source code. I'm not entirely sure how many of these instances there are, but it's not only a few for sure. It would be a huge undertaking, for no obvious benefit than to satisfy those who erroneously believe source code must come in text files. [...] I was trying to hint at another (non-quaint) reason for that. How could someone be sure that such an image contains no malware; no hidden code that only pretends to run the embedded source code? This is one of the fundamental benefits of bootstrapping: one knows exactly what's in there. [...] Anyway, the Debian ftpmasters [...] were concerned about how to be sure what changed from one image to the next. Squeak comes with all the necessary tools built into it, but this does not work well with their established work flow. Plus it requires them (and users) to run the tools embedded into the possibly suspect image in order to describe itself. Do you see how there could be a trust problem there? - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
Holger Levsen [EMAIL PROTECTED] writes: [...] The reason for having it in non-free is that the Debian ftpmasters don't think it passes the criteria for inclusion in main. [...] http://paste.debian.net/6962 [...] (Sorry, this is probably OT for this list.) Considering the age of this smalltalk-derived image, is there some reason to be convinced that it contains no code/data other than that could be regenerated from sources today? If there is a mechanical way of assuring that, how big a step would it be to re-create the image from those sources? - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
Kim Quirk [EMAIL PROTECTED] writes: [...] Finally, I agree with Scott, that the easiest thing we can do in the short term is to make the 'get a developer key' more prominent for those who want to find it. [...] Taking away the 24 hour delay between key request and response could help solve both problems. - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: VGA external on OLPC
Jim Gettys [EMAIL PROTECTED] writes: Note there are USB display adapters (I have one in my hand as I write this); I'd love to see someone working on X.org drivers for it. [...] The sisusb-based USB display adapters have both kernel and x.org drivers today. - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Auto backlight management?
Bert Freudenberg [EMAIL PROTECTED] writes: [...] The XO does not have an ambient light sensor. The backlight is not turned off automatically in sunlight. [...] Opportunistic use of the on-board camera and the time-of-day clock could yield such heuristics. - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wordsmith ( Scrabble ) :GSoC application
Aditya Vishwakarma [EMAIL PROTECTED] writes: I am working on making a Scrabble game as a GSoC project called Wordsmith. [...] Beware recent trademark/copyright enforcement efforts by the owners of the game name/concept. (google hasbro scrabble facebook). - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Chilling Effects paper at USENIX
Charles Merriam [EMAIL PROTECTED] writes: I read the paper, and it seems to summarize as: 1. The BitFrost Specification is documentation, not detailed implementation. The author does not read code. [...] It seems like OLPC F. should issue an immediate (preemptive) response saying: 1. BitFrost is an open-source implementation. The BitFrost Specification is a high level document and not an engineering specification. Engineers can read the implementation source code. [...] As shown on the Bitfrost status wiki page though, there is not that much implementation yet to critique, so the paper's authors are perhaps justified in looking at just the plans. - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Community-news] OLPC News (2008-02-09)
Walter Bender [EMAIL PROTECTED] writes: [...] Chris Ball provided Richard with some power readings from our newly enhanced power tinderbox running a C2 (mass production) laptop. [...] The top auto-suspend power-draw breakdown: WLAN: 734 mW backlight:362 mW memory: 239 mW LCD: 218 mW EC: 108 mW other:339 mW total:2064 mW [...] A next step will be to see if the wireless power can be reduced during suspend. [...] Has the following idea already come up? How about just turning off the wlan entirely during suspend, if the machine has reason to believe that its contribution to mesh connectivity is negligible? - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Community-news] OLPC News (2008-02-09)
Hi, Chris - On Sun, Feb 10, 2008 at 01:44:15PM -0500, Chris Ball wrote: [...] Has the following idea already come up? How about just turning off the wlan entirely during suspend, if the machine has reason to believe that its contribution to mesh connectivity is negligible? [...] here's one potential problem: at school, each laptop will believe its contribution is small. If the laptops then all head home with wireless off, they aren't transmitting the mesh beacons needed for mesh discovery. [...] It could be a reasonable imposition upon an OLPC user to manually wake up their machine at least once when they relocate -- if they wish to participate in the mesh. When that happens, the machine could make a new judgement about whether wifi should be retained while next suspended. - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: python activities startup
[EMAIL PROTECTED] writes: [...] I can't comment on python modules, but I've seen similar issue on shared libraries with firewall proxies that did a fork for each connection. [...] if you can get the linking and initialization step down to once per boot it will bee a huge win. To what extent could prelinking, which should improve this aspect, be used on OLPC? - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power management experiences with joyride-1572
Chris Ball [EMAIL PROTECTED] writes: [...] In the future, we can imagine setting wakeups programmatically, with the help of the Linux dynamic ticks implementation and the cpuidle framework -- if Frank's sugar clock has a pending wakeup in 60 seconds to update the minute hand of the clock, we can set a wakeup for +59s before going to sleep. This is a long-term feature, though. To what extent do folks know what olpc userspace is doing in its idle moments? If there is not much junk system call traffic, one could imagine a tool that monitors the processes, and when it finds that they're all voluntarily sleeping for long enough, it could schedule an early suspend and a later automatic resume. i.e., if sugar clock is doing sleep(60), but other processes are blocked on I/O, this tool could run rtcwakeup 60; echo mem /proc/.../suspend). - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
power management experiences with joyride-1572
Hi - I've been dabbling with joyride-1572 on a g1g1 laptop for a day or few, and have noticed the suspend feature kick in after a few seconds of apparent inactivity. I have some questions about whether some specific experiences with this are expected: - that a resume operation begins only with a keyboard/touchpad input, and takes 1-2 seconds for interactiveness to return? - that running programs such as the sugar clock widget, or programs running in the sugar terminal, all freeze during the suspend? - that if one switches to the text console (C-A-F1), one observes the backlight intensity oscillate up down with about a 10s interval, despite ongoing keyboard input? - that power consumption during the awake mode has not significantly fallen since build-650 or -653, leading to a ~3 hour battery endurance for light continuous web browsing / terminal usage? Thanks! - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
