Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On Mon, 2010-08-09 at 14:05 -0400, Martin Langhoff wrote: > We do a ton of things in relationship with our 'community' (or perhaps > our different 'communities'). For example, we engage in this thread > with you. And yet, Developers on this list [olpc-devel] have complained when people have done that, because this is not the place for it. Of course, there isn't any other place for it. > As with most projects, it's up to you to help, participate positively, or not. Indeed, and I have tried to do that. I really don't want to get combative here. This may come off as "You guys all suck" but what I want is for things to improve. I feel that every criticism seems to be responded with a counterattack. I would much prefer it if there were at least an acknowledgement of the frustration that people 'on the outside' are feeling. When you say "it's up to you to help, participate positively, or not." it feels like the implication is that you think I should do more than just complain. That also makes it seem like I have been contributing in vain. I would also like to stress that it wasn't my intention to bring this up because I have found things hard. It's because so many of the people I have spoken to have felt the same frustration. I'm not a Python person, but a friend of mine who attended PyCon came back and said he was amazed with just how many people he met who felt burned by OLPC. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On Sun, 2010-08-08 at 19:55 -0400, John Watlington wrote: > On Aug 8, 2010, at 7:15 PM, Neil Graham wrote: > > > There is a small open handheld console. http://www.openpandora.org/ > > http://pandorapress.net/ The openness and friendliness of the community > > environment is a model for how things can work. > > The support page on that wiki points you to enter the bug in their bug > tracker. > What part of Pandora were you holding up as an example of better practices ? > > wad Goodness I didn't realise the difference was that profound. Community involvement is not a link on a webpage. If that is the level of interaction that you have been looking at then you haven't even been in the right book let alone on the right page. I doubt I ever clicked on that link, yet I know how many Pandora's are out there, where the various components of the as yet unassembled Pandora's are, what has been the most recent problem in getting them going. I don't actually have a Pandora but I know that the first few units had sticky shoulder buttons, I also know that was due to the paint, and what they did to solve the problem. There is a huge amount of transparency that just isn't there with OLPC. Perhaps that was out of necessity, most Pandora purchasers paid one or two years ago. You can't ask people for a million dollars then not produce anything for a year without letting them know something is happening. Nevertheless it has much better results. There isn't the them and us feel. The Pandora has been out maybe a month now. About a thousand units shipped. It has FireFox Chromium FBReader, Fennic, Pingus, Dink Smallwood, Pandora Panic, Lmarbles, Ur-Quan Masters, Quake 3, emulators for Linx,Amiga, MSX, psx, Oric, Amstrad CPC, PDP-11, Vice, DosBox little fairies didn't bring me that information, and neither did they port all that software. Perhaps what is needed is a KDE to olpc's gnome in order to lift the game of both. But really, I'm about done. I might just go and do other things. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On Sun, 2010-08-08 at 18:02 -0500, Mikus Grinbergs wrote: > > in general I think it's entirely appropriate to expect > > that people asking for help do so via the correct channels > > I believe that "asking for help" should not be the only supported > motivation for contacting developers. Along these lines, Is there a community liaison? If not, why not? If so, quite frankly when was the last time they liaised with the community. I'll put this here. There is a small open handheld console. http://www.openpandora.org/ http://pandorapress.net/ The openness and friendliness of the community environment is a model for how things can work. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Adobe Flash 10.1 + AIR 2.0 on the XO
On Wed, 2010-03-24 at 11:42 -0300, Gabriel Eirea wrote: > My personal observation is that this came from a high demand on two > fronts: kids and teachers complaining about youtube and online games > on one side, and local companies used to develop web pages and such > that wanted to create content but only had resources to do it in flash > and complained about gnash being too restrictive on the other side. I believe there are solutions to all-bar-one of those problems. There's not much that can be done for games already written in Flash. They are already there and most are written to use a more powerful machine than the XO. For the other points, there are possibilities. Video off of the web can be tackled a number of ways, I've not actually done much youtube style watching on the XO myself, but I hear others have had success with non flash options. I have been attempting to come up with a solution for custom content. A browser plugin that may be a step in the right direction. http://code.google.com/p/thefbi/wiki/Intro It is not compatible with flash but rather an alternative mechanism for running content in a similar fashion to flash. It actually runs a i386 elf executable in a sandbox and a custom int $80 API to interface to the browser. That way many existing tools can be adapted to generated content for the plugin. I have been developing it with the XO in mind and it performs well in-browser on XO-1 hardware. Here's a clip jumping to the 2:40 mark where it shows the plugin in action on my XO-1.http://www.youtube.com/watch?v=58UmxHryq8E#t=2m40s With my experience of flash on the XO, doing a display with a similar number of moving entities in a swf would be extremely chuggy. Significantly, as an open source project. If there is something that this plugin doesn't do well (which is a number of things because it is in its infancy). Anyone is able to make the required improvements. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
UDE - environment Alpha.
I've been working on this a while. I've got something for people to look at. It's Alpha with many broken parts, but there's enough to get the idea and, cross fingers, encourage others to contribute. http://screamingduck.com/ude/ It's an environment aiming to provide an alternative to Sugar or Gnome, It installs into the user's home directory so an XO user can install it without changing anything at the system level. You can however do a few system level changes in order to have most of the environment based on SD-card. To install to a permanently mounted SD card see http://screamingduck.com/ude/?Article=56&Show=ABCE I have worked hard to keep things lightweight enough to run on an XO-1. I have a nice four workspace environment, with desklets, ROX-Filer, and a number of other goodies running while being comparatively lightweight. Here's a ScreenShot showing the just booted memory state. http://screamingduck.fileburst.com/screenshots/ude/justbooted.png (If you run this, Click on the doodle icon centre-bottom it's cool :-) also note the launch time, That's what the XO can do ) While the system is a windowed environment, pressing the frame key toggles the current window to full-screen undecorated. The workareas are related to modes of thought rather than Sugar's zoom levels. An explanation and pretty pictures can be seen at http://screamingduck.com/ude/?ScreenShots [extra bits to look at, not all currently working in this release] Much of this is based upon things collected from the Free software cornucopia. Some parts I had to make myself, I failed to find a desktop widget system light enough for the XO, so wrote my own. Here's a clip showing some of the Unix philosophy behind the widgets http://www.youtube.com/watch?v=0QJ9fTYZuwk&fmt=22 Because the XO screen has such a high resolution, moving fullscreen graphics around can be quite slow. To mitigate this for programs needing animation more than resolution I have utilised an rgb565 video overlay. The Doodle program uses this technique. Here is a clip showing an animation demo on the XO using this method http://www.youtube.com/watch?v=KD95e9G1SiQ In addition to this I have created a simple little graphics library (called Whio) to enable full-screen animated applications to be put together with very little effort. This was inspired by the LÖVE project, I might have just used LÖVE, but for it's requirement of OpenGL. Instead this uses the Overlay technique mentioned above, this allows the programmer to ask for whatever resolution they want (up to 1024x768) and it will run fullscreen or scaled to a window of any size. Working in conjunction with the library is a easy project creation system so that users can create project bundles easily and consider them to be a single working unit until they are ready to look inside the bundle to deal with the finer details. This is a core principle, of UDE, easy to get started, but the finer control is there for those who go looking for it. This clip shows several components mentioned above. In it, I create two new projects by drag and drop. One is a Standard GUI style app, the other is a fullscreen animated app. http://www.youtube.com/watch?v=AMtleAzJ3AE&fmt=22 The IDE is a bit too complex for a beginner programmer, mostly because it looks intimidating. I hope to make something simpler for people to begin with, and give them the choice to switch to MSEIDE (the one shown in the video) later. (Actually, now that I've had to type it all up, it seems like quite a bit, maybe don't spend all my time playing QuakeLive) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: "Noise" level on devel
On Tue, 2009-12-29 at 09:26 -1000, Mitch Bradley wrote: > I regret that I must once again unsubscribe from devel, as the noise > level has gotten out of control. That 'noise' is engagement with the community. If you feel that olpc has the resources to provide a complete system through a cathedral model, by all means go off and do your own thing. > I need to get some actual OLPC-related work done, instead of listening > to people giving free advice and telling others what they ought to be doing. If a thread isn't to your liking it is remarkably easy to not read the remainder of the messages in that thread. > If something that requires my attention should pass this way, I trust > that one of you intrepid souls who can still stand to listen to all this > chatter will forward me the information. Let me try that for you in a different way. I an unsubscribing from this list, If something that requires my attention should pass this way, could someone please forward me the information That does the same job without going into details. If you thought that your feelings on the issue were relevant or had merit then.. WHAT THE HELL ARE YOU DOING COMPLAINING ABOUT OTHER PEOPLE EXPRESSING THEIR OPINIONS. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Android, OLPC, and native hosting
On Mon, 2009-12-28 at 19:38 +0100, Martin Langhoff wrote: > emacs is what I am using on both XO-1 and XO-1.5 so pretty good going > ;-) (Along with vim! Peace!) > > Lots of people here want to claim we need Eclipse to have an "IDE". Of > all the developers involved in the whole Linux > kernel+Fedora+Sugar+OLPC custom bits, the incidence of Eclipse usage > is vanishingly small. I have tried to do the bulk of my development actually on an XO (well until I got retina problems anyway, the screen gives me a bit of trouble now). It may not be up to running behemoths like Eclipse, but I've considered that to be Eclipse's problem more than the XO's. I do Pascal development mainly, Which suits the XO nicely for compile times and execution speed. On the XO I use MSEIDE which does a reasonably good. See here for a demo of the IDE and easy project creation, http://www.youtube.com/watch?v=AMtleAzJ3AE That clip makes a new Window and buttons style program, and a new animated game style program. That clip was not actually running on the XO, I run it on my Ubuntu box for screen capture purposes. To see the same system running on my XO (recorded with a crappy camera), watch http://www.youtube.com/watch?v=KD95e9G1SiQ I did a Ludum Dare 48 hour game competition on the XO, Doing all programming on the XO itself screenshot --> http://www.ludumdare.com/compo/wp-content/compo2/6952/20-shot0.jpg So a good level of development is possible on the system, I'm ok if the operating system itself gets built on a more powerful system, but I'd really prefer most applications that specifically target the XO be developed on the XO hardware. This I'd consider especially true for sugar apps. They should be developed in sugar, on an XO wherever possible. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-3 official
On Wed, 2009-12-23 at 18:33 -0800, John Gilmore wrote: > > 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. Actually I think the hands are all doing a very good job. It's the head that needs attention. One thing does interest me however. the comment "it plans to open the architecture of the device to allow any other PC maker to take over the project." Is this in the realms of possibility for the XO-1/1.5? Specifically, would OLPC allow a 3rd party to manufacture a system with their own motherboard using the XO-1 case, battery and screen. Perhaps with a colour change to make it distinctive as another product. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
On Thu, 2009-12-17 at 11:47 -0300, César D. Rodas wrote: > This probably reflects a bug in the program. > The error was 'BadAlloc (insufficient resources for operation)'. I'm doing some work that uses xv on the XO. I found that this occurred for me when running X in 24bit, but 16bit was ok. I'm assuming that it's not actually running out of ram because free reports that I have 223M totoal memory, I certainly hope that means that 32 meg has been given to the display driver. If not I'd like some of it back please :-) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 1.5 - gnome-packagekit?
On Wed, 2009-12-09 at 02:55 -0500, Walter Bender wrote: > Slightly off topic, but reading between the lines, it seems there is > something more fundamentally broken here. 5000 packages. The Apple app > store adds that many new "apps" every week it seems. Why aren't there > 5 million packages available instead of just 5000? What are we doing > wrong as a community? I have lots of theories but would be curious if > anyone had any concrete ideas. (Or maybe 5000 packages is better than > 10 apps and all is well in the world?) Well as I mentioned above, I'm working on my own environment thingy. Because I don't want to have to write everything myself, I have had to hunt for the right tool for each job. It is quite the task, it is one thing to say 'I know I'll use standard package X' It's something else completely to go hunting to see if there is something better. There is a _lot_ of stuff out there that is not in repos. A lot of it is crap, but that could be said for the contents of repos too. The proportion of good to bad I'm unsure of. I am more sure that the smaller the project, the more likely that it won't be available as anything but a tarball. Even given that I don't think there is as much out there as there should be. If I have a go at making something there are always those standing on the sidelines making derisive comments and saying 'just use [inappropriate program X]'. I think it's a telling sign that there is no good open alternative to flash. There should be a pile of them each trying different ways to do things, the better ones could then grow into something mature. I could rant all night on this issue. I don't think there is any one problem, I think it's a myriad of things. Attitudes, bureaucracy and just plain difficulty all play a part. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Swap to SD cards: performance and burnout test
On Tue, 2009-12-08 at 10:18 +0100, Sascha Silbe wrote: > > I don't think it's terribly useful to test memory consuming > > non-interactive tasks. > The problem is that the only way to get _comparable_, _repeatable_ > numbers is to make the test non-interactive. Yup, but that's looking where you didn't drop your contact lens because the light is better over here. > What's most important to the user is probably going to be the latency > (pointer "sluggishness", UI reaction time), though, and I don't have an > idea how to test that (still keeping in mind that it needs to be > comparable and repeatable). Simply cannot be done, User interfaces are inherently based around, well, interfacing with the user. The user is a component of the system. You could have a bot that does some automated clicking but you run the risk of ignoring exactly the data that would be relevant. The behaviour of the user will change with he speed of the system, sometimes that change will significantly change the speed of the system. An example is the user triggering an operation twice because the system took too long to demonstrate it was responding to the first one. Even if the double action is handled gracefully, it makes extra work to figure out what to do. When my daughter was younger she would just keep on clicking on supertux until it appeared, bringing the system to a standstill while it launched 20 copies. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 1.5 - gnome-packagekit?
On Mon, 2009-12-07 at 19:13 -0500, Reuben K. Caron wrote: > Since .XO and .XOL bundles were specifically designed to be "safe" for > installation and removal, I'm concerned the inclusion of gnome- > packagekit would allow one to more easily break their installation but > I also think it would be nice for children to explore the rest of what > Fedora has to provide. Perhaps this is something for Zeroinstall http://0install.net/ . ZeroInstall allows for installation of software as a user so you can do things without making system level changes. I'm working on a setup for the XO that can give you a custom environment. The entire thing goes into $HOME. I uses Zeroinstall to grab everything as needed, even the window manager. In practice the bundle comes with the window manager but that is merely as a pre-filled zeroinstall cache entry. Because everything is done at the user level, it is very hard to break things, but it still allows users to have a great deal of flexibility with their system. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Swap to SD cards: performance and burnout test
On Mon, 2009-12-07 at 19:16 +0100, Sascha Silbe wrote: > On Mon, Dec 07, 2009 at 03:41:10PM -0200, Emiliano Pastorino wrote: > > Does anyone come out with a possible test? > Compilation in general (e.g. Linux kernel or sugar-jhbuild) seems to be > quite stressful to SD cards and often consumes a lot of memory, so might > be a good benchmark. I don't think it's terribly useful to test memory consuming non-interactive tasks. The important factor with things like compilation is that it gets the job done, speed is preferale but not necessary. However Delays of the sort that can double the time of a build operation could quite possibly render a user interface totally unusable. The easiest way to test swap performance on working data and a user interface I would guess would be to run Firefox up to 300 meg. Short of running evolution that's the best way to frivolously eat up your ram. Then just try doing some things. I run a swap on my XO, The speed difference while actively swapping compared to running totally in ram is quite significant. I'd class it as barely usable. What it does give you is the ability to not crash when you run out of ram, and to do the memory intensive non-interactive tasks mentioned above. I haven't traced it all through but I imagine there is some benefit to swapping out parts of programs that used memory at boot time and are now largely idle. Those items won't swap back in effectively giving you a little more ram. Not really enough to have a huge impact though. What I have found is that the XO has more than enough ram to run all the lightweight programs it wants, and not early enough to run the behemoths. There isn't a lot of middle ground. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: os33 - video regression ?
On Tue, 2009-10-27 at 11:28 -0700, Jon Nettleton wrote: > > Xv can blit both YUV and RGB data to the overlay. I do not know why do > > not they support Xv but this cannot be the reason... > > http://blogs.adobe.com/penguin.swf/2008/05/flash_uses_the_gpu.html > > Down under FAQ. > It may be the reason given, but it still isn't a valid reason because it simply isn't true. It may be a simplifiaction of 'rgb overlays cannot be relied upon to be supported by the hardware'. That is true, some hardware only supports YUV. RGB565 certainly is possible an indeed exists on the XO-1. I'm using it to run graphics scaled. I would love to see the same mechanism on the 1.5. From the snooping I've done so far XO-1.5's have been reporting no adapters present or cannot open display. I'm guessing I have yet to encounter one with drivers advanced enough to allow XV. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Mouse wrap-around in X?
On Tue, 2009-10-06 at 13:50 -0200, Emiliano Pastorino wrote: > Does anybody know if there's any configuration in X or package > which let you make the mouse pointer jump from one edge of the > screen to the opposite one? > > This is a very useful feature for accessibility. > While it's not its primary purpose, synergy could probably do this. http://synergy2.sourceforge.net/ I have three monitors and have configured them in a loop (off the top of the rightmost comes onto the bottom of the leftmost). It's also great for the xo in ebook mode, When the xo is connected it plugs in off the top of the righmost and below the leftmost adding a new entry in the loop. (I usually sit the xo below the left monitor) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Testing] New F11 for the XO-1 Build 7
On Wed, 2009-09-23 at 10:13 +0800, Jerome Gotangco wrote: > Thanks for this! I've tried it on an XO-1 and it updates fine. Don't suppose you could run a few programs to show some info to help me to decide if I want to switch to this. Boot then open up a terminal in X and type free df xdpyinfo and xvinfo and could you post the output of those programs please. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Why not Xfce? (was: Re: The XO-1.5 software plan.)
On Sun, 2009-05-17 at 13:54 +0200, Martin Langhoff wrote: > Work on getting a top-notch polished $desktop on it, and continued > mantainership behind it, and it'll definitely be an option. It's > reasonably easy to get desktops "going", but good polish making it > suitable for end users takes a ton of detailed, subtle work. +1 that +1. I've been working on a ROX setup. It's quite a good fit since it follows the application-directory model so doesn't need to muck with the underlying OS or have extras installed as an even scattering of files throughout the fileSystem. It's been working a while but there's a heap of work to do to make it nice. I'll advocate people using it if and when it's good enough that people go 'Hey! Can I run that too' Things to make it nice for XO usage 4 paged desktops using the Square, Dot, DotDotDot and DotDotDotDotDotDotDotDotDot buttons. Contents of desktops divided by interaction style. (the division is not forced, but guided) A) computer -> brain (web browser/ book reader/ videos/ help documentation for (B) ) B) brain <-> computer (word processor/ Paint/ Coding/ C) Stuff I have(Apps to run, File views) D) quick utilities (things that the user interacts with on a short-term basis, calculator, network view, clock, battery monitor etc.) The frame button has been appropriated to toggle the active window into(and from) fullscreen-undecorated. This works a treat when you want to get down to work. I'm playing with screenlets as system that can aid Desktop (D), My daughter likes the fact that she has a clock with her name on it that she can move around. Screenlets have the potential to be quite kid friendly. Performance wise they are ok on an XO-1, because most don't do a lot of hard work. Hard to day when it comes to memory. Python is already floating around. A lot of this stuff becomes a lot easier with an XO-1.5, but as I expressed when it was first announced, I'm concerned that it has the potential to reduce support for the XO-1. This seems to have happened with the announced software plan. I'd be OK with this if there was a firm line drawn to say that the 1.5 spec was fixed, and a long term solution, there are not yet too many XO-1s out there that they could in-time upgrade. As it stands, it is quite easy to envisage in 5 years time there being little support for the XO-1. ...but why support the 1.5 if XO-2 does the same thing again? Upgrading the base spec every few years leads to the depreciation of the system as support for the older spec declines. Ultimately that means you are asking(whether you realise it or not) for people to buy a new system every few years. Incidentally, Does anyone have a cost breakdown of the XO-1.5, Cheaper, the same, more expensive? I assume someone knows this. Is it something us mere mortals are allowed to know? [well that was a post of two halves] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Why not Xfce? (was: Re: The XO-1.5 software plan.)
On Sun, 2009-05-17 at 13:54 +0200, Martin Langhoff wrote: > Work on getting a top-notch polished $desktop on it, and continued > mantainership behind it, and it'll definitely be an option. It's > reasonably easy to get desktops "going", but good polish making it > suitable for end users takes a ton of detailed, subtle work. +1 that +1. I've been working on a ROX setup. It's quite a good fit since it follows the application-directory model so doesn't need to muck with the underlying OS or have extras installed as an even scattering of files throughout the fileSystem. It's been working a while but there's a heap of work to do to make it nice. I'll advocate people using it if and when it's good enough that people go 'Hey! Can I run that too' Things to make it nice for XO usage 4 paged desktops using the Square, Dot, DotDotDot and DotDotDotDotDotDotDotDotDot buttons. Contents of desktops divided by interaction style. (the division is not forced, but guided) A) computer -> brain (web browser/ book reader/ videos/ help documentation for (B) ) B) brain <-> computer (word processor/ Paint/ Coding/ C) Stuff I have(Apps to run, File views) D) quick utilities (things that the user interacts with on a short-term basis, calculator, network view, clock, battery monitor etc.) The frame button has been appropriated to toggle the active window into(and from) fullscreen-undecorated. This works a treat when you want to get down to work. I'm playing with screenlets as system that can aid Desktop (D), My daughter likes the fact that she has a clock with her name on it that she can move around. Screenlets have the potential to be quite kid friendly. Performance wise they are ok on an XO-1, because most don't do a lot of hard work. Hard to day when it comes to memory. Python is already floating around. A lot of this stuff becomes a lot easier with an XO-1.5, but as I expressed when it was first announced, I'm concerned that it has the potential to reduce support for the XO-1. This seems to have happened with the announced software plan. I'd be OK with this if there was a firm line drawn to say that the 1.5 spec was fixed, and a long term solution, there are not yet too many XO-1s out there that they could in-time upgrade. As it stands, it is quite easy to envisage in 5 years time there being little support for the XO-1. ...but why support the 1.5 if XO-2 does the same thing again? Upgrading the base spec every few years leads to the depreciation of the system as support for the older spec declines. Ultimately that means you are asking(whether you realise it or not) for people to buy a new system every few years. Incidentally, Does anyone have a cost breakdown of the XO-1.5, Cheaper, the same, more expensive? I assume someone knows this. Is it something us mere mortals are allowed to know? [well that was a post of two halves] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO Gen 1.5
On Fri, 2009-04-17 at 15:24 -0400, John Watlington wrote: > The design goal is to provide an overall update > of the system within the same ID and external appearance. > > In order to maximize compatibility with existing software, this > refresh will continue with an x86 processor, using a chipset from > VIA. The memory will be increased to 1 GB of DDR2 SDRAM, and the > built-in storage will be 4 GB of NAND Flash with an option for 8 GB > (installed at manufacture). > > The processor will be a VIA C7-M [1], with plans on using one whose > clock ranges from 400 MHz (1.5 W) to 1GHz (5 W). The clock may be > throttled back automatically if necessary to meet thermal constraints. How much cheaper will the new system be? I was under the impression that the idea was to allow the XO price to drop with technology gains rather than spec increase. Of course I'm happy to accept spec increases if they come as a result of cost savings, but wasn't cost supposed to be the priority? Does this also mean that people who already own XOs will find that new software is going to require a computer more powerful than they currently have? I thought that that was something that was going to be specifically avoided. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: performance work
On Tue, 2008-12-30 at 20:41 -0700, Jordan Crouse wrote: > > I'm curious as to why reads from video memory are so slow, On standard > > video cards it's slow because there is quite a division between the CPU > > and the video memory, but on the geode isn't the video memory shared in > > the same SDRAM as Main memory. > > It is, in that they share the same physical RAM chips, but they are > controlled by different entities - one is managed by the system memory > controller and the other is handled by the GPU. At start up time, the > memory is carved up by the firmware, and after the top of system RAM is > established, video and system memory behave for all intents and purposes > like separate components. Put simply, there is no way to directly > address video memory from the system memory. Access to the video memory > has to happen via PCI cycles, and for obvious reasons the active video > region has the cache disabled, accounting for relatively slow readback. That makes my brain melt, you can't address it even though it's on the same chip!?! Even as far back as the PCjr the deal was that sharing video memory cost some performance due to taking turns with cycles but it gave some back with easy access to the memory for all. Has the geode cunningly managed to provide a system that combines all the disadvantages of separate memory with all the disadvantages of shared? One wonders what would happen if you wired some lines to the chips so that the memory appeared in two places, would you get access to the ram (with the usual 'you pays your money, you takes your chances' caveats about coherency) I'm not a hardware person, but that all just seems odd. > That said, the read from memory performance is still worse then you > might expect - I never really got a good answer from > the silicon guys as to why. > being hit with the full sdram latency every access maybe? Is it feasible to try with caches enabled and require the software to flush as needed. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: performance work
On Mon, 2008-12-22 at 15:36 -0700, Jordan Crouse wrote: > You might want to re-acquire the numbers with wireless turned off and > the system in a very quiet state. If you want to be extra careful, you > can run the benchmarks in an empty X server (no sugar) and save the > results to a ramfs backed directory to avoid NAND. The XO Numbers were recorded from a fairly inactive state. Wireless was active but there shouldn't have been any traffic. I did launch X with just an xterm, so sugar shouldn't be in play at all. I didn't think of the speed of nand writes however. > 2) The accel path requires reading from video memory (which is > very slow) I'm curious as to why reads from video memory are so slow, On standard video cards it's slow because there is quite a division between the CPU and the video memory, but on the geode isn't the video memory shared in the same SDRAM as Main memory. There's a separate 2 meg for DCON memory, but I was under the impression that was just to remember the last frame. Do I have that all wrong? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: performance work
On Tue, 2008-12-16 at 16:23 -0700, Jordan Crouse wrote: > I recommend running the Cairo benchmarks on the XO again with > acceleration turned off in the X driver. This will give you a good > indication of which operations are being accelerated and which are not. Done. http://screamingduck.com/Cruft/cairo_benchmark_XO_NoAccel.txt At a cursory glance it looks like an overall improvement without acceleration except for lines-xlib, add-xlib and over-xlib ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: performance work
On Tue, 2008-12-16 at 16:23 -0700, Jordan Crouse wrote: > I would start by establishing a 1:1 baseline - it is great to compare > against a 2Ghz Intel box, but that the differences between the two > platforms are just too extreme. No matter how good the graphics gets, > we are still constrained by the Geode clock speed, FPU performance, and > GPU feature set (what it can, and most importantly _cannot_ do). I'm not even sure there _is_ a decent 1:1 baseline (and if there were wouldn't it produce exact same results). I did the 2GHz machine because it's my slowest running box and more data can't hurt. I suspect it would be more value to compare the ratios of speeds between different tests on the same machine rather than across machines. At the very least it can impress upon people the speed difference between the machines. > The first thing you need to do is determine which operations you really > care about. I would first target the operations that deal with text and > rounded corners, since those will be the most complex. Straight blits > and rectangle fills are important, but less interesting, since they > involve the least work in the path between you and the GPU. Fundimentally, you care about the operations that are making it slow. Those are the ones A) being used lots B) Take notable amounts of time in total and C) have room for improvement. Is there a build of cairo that can produce a log of what calls are used in typical XO use? > > I recommend running the Cairo benchmarks on the XO again with > acceleration turned off in the X driver. That's just a xorg.conf change? I can do that and rerun the benchmark. > Outside of the driver, you are pretty much limited to evaluating > alogrithms, either in the software render code (pixman) or in the cairo > code. For those situations, I have less knowledge, but I do advise you > to remember the two hardware constraints which I mentioned above - CPU > clock speed and FPU performance. Remember that alot of this code was > written recently when nobody in their right mind has < 1Ghz on their > desktop - no matter how hard they try, this will end up biasing the code > slightly. FPU performance is more serious. The Geode does not do well > with heavy FPU use - to mitigate the damage, try to use single precision > only, and try not to use a lot of FPU operations in a row because the > Geode pipeline stalls horribly if two FPU operations are scheduled one > after another. > > Finally, I will remind you that you that no amount of hacking is going > to magically make the Geode + Geode GPU all of a sudden look like a > modern desktop Radeon. Agreed, but it at least should do something in the range of my old 166Mhz system with s3 card. Which it currently doesn't at a user experience level, how much of that is inefficiency and how much is trying to do too much remains to be seen. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar & XFCE
On Fri, 2008-12-05 at 19:37 +0800, Carlos Nazareno wrote: > These days, 433MHz may seem unusable to the average Moore's > law-spoiled user, but it was more than enough for me who grew up on a > 4.77MHz 8088 as a kid (yeah, that's nothing to you guys over here who > are older :P), a Pentium 166 MMX with 64MB RAM in college during the > late 90s, and then an AMD K6-2 500 w/ 256MB RAM as my primary > workstation during the early 2000's. > > That K6-2 500 w/ 256MB RAM's specs are practically the same as the > XO's and performs more or less the same as proven by this circa 2003 > experiment of mine: http://www.object404.com/lab/aquarium.php -- it > runs at practically the same speed on the XO as my aforementioned K6-2 > Win98 rig That doesn't change the fact that using the XO is like walking neck deep in treacle. I absolutely agree that the machine is up to doing good performance. It dismays me to see things like the scrolling of a static web page in browse can't keep up with keypresses. The real problem there is it's hard to isolate the slowness, I think largely due to the fact that the problems aren't isolated. Is there any central repository for information about where the speed is going? I'd like to help out here, and I've tried, but it has been very difficult. When looking at things I have encountered things like "Why don't you use [thing], that should do it the best way" only to find [thing] needs help from an experienced [thing] hacker to work efficiently in this case. Much of the time [thing] has been cairo or X. but I think that's only because of the areas I've tried to work. I'm still reminded of using GEOworks Ensemble on a 286. It could do so much with so little and the XO seems to do so little with so much more. Not blaming anyone in particular, but I've been trying to work on this stuff and I have to vent my frustration every six months or so. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Another sugar rant (was: x2o physics problem solving game)
On Wednesday 06 August 2008 7:08:33 am Alex Levenson wrote: > I'm announcing x2o's first tentative release! x2o is a physics problem > solving game in which you create Rube Goldberg contraptions in order to get > the O to land on top of the X. Check it out at > http://wiki.laptop.org/go/X2o, give it a try, write some levels, and let me > know how it goes. There are a lot of planned improvements on the way, but I > would love some feedback. I have been playing a lot of http://fantasticcontraption.com/ lately so this is something I'm quite keen on. Some things...[rant prep.] Searching for X2o using the wiki search doesn't find it. It's Called X2o! it's url is http://wiki.laptop.org/go/X2o for heaven's sake! Somebody either fix the search or just change the search box to go to google. With regards to using activities on the XO I've tried to be accepting of the sugar interface style, but this activity crystallizes things for me. I'm now prepared to move to the sugar-sucks camp. I've used many and written a few physics toy programs. I've had a fair experience with a variety of ways to do this kind of thing. X2o is the most cubersome that I have encountered. I'd like to be clear that I don't think there is anything done poorly in the X2o activity itself. I think it all comes from having the sugar interface. The more I encounter sugar interfaced programs, the more I think Activities would be better off with just about anything else. I gave myself a long time to acclimatise, much longer than I would have for anything else, because the XO is really quite important. I really believe in the goals of the OLPC project, but I cant use the XO effectively! My daughter can't use the XO effectively! At what point does a do-over make more sense? I was prepared to take the resource usage and the slow bits and the joke that is the journal because they were all things that future work would have addressed. The cumbersome user interface is a killer though because it's designed to be like that. When I got my XO it was as an XO, not as a cheapie laptop. I wanted to support the platform. A big part of that for me was dogfooding, but it has bought me nothing but frustration. There are some good things there. The activity security and the collaboration support are good ideas, I can't help feeling that those bits should be kept and the rest done from scratch. Sorry if this post irritates some of you. I'm not usually a mailing list ranter, but the olpc project is something that I think is really quite important for the world. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Parallel desktops
On Friday 27 June 2008 1:59:16 pm Chris Ball wrote: > Instead of (or as well as) preparing a separate disk image, we could > prepare a Desktop activity which launches an Xfce session and includes > some office tools, the standard NetworkManager applet, a configurable > CUPS installation, and so on. This could reduce our support load, > allowing us to proceed on with our regularly-scheduled world-saving. In another thread there is talk of using virtual desktops per Activity, which is an idea that I had been wondering why it hadn't been that way from the beginning. I think the best outcome would be to find a way to do these two complimentary. I don't like the Idea that a desktop and and sugar are mutually exclusive. Simply clicking on an activity in sugar and getting a traditional desktop would work for those that want it. A Windowsy theme and Wine may even satisfy those with urges leaning in that direction. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
boot-anim
As it stands now there seems to be no 100% reliable way to judge the compressed size of things on jffs2. I cast my eye to the boot-anim, uncompressed it comes to about 60 Meg, is there space being wasted there? http://lists.laptop.org/pipermail/library/2007-July/70.html says > JFFS2 compresses 4K chunks using zlib. So it's not just per-file > compression, it's compressing bits of a file. It doesn't compress files > where compression doesn't help. And there's a 68 byte overhead per > compressed chunk. Plus probably some fixed overhead per file. doing some tests using mkfs.jffs2 on a filesystem with a single file of zeros at varying sizes gave me. 409600 --> 11656 819200 --> 23256 1228800 --> 34856 1638400 --> 46456 each growth of 100 4k blocks added 11600 bytes. I'll go out on a limb and say the best case on jffs2 is turning a 4k block into 116 bytes, about 35:1 compression, or down to 2.8% if you prefer This is why the boot-anim bothers me. If it were all zeros it should be taking up just over 1.5 meg. It compresses really well, but it can't go beyond that limit. Running the jffs2size.py script on /usr/share/boot-anim reveals. no compression : 60480336, 60480K estimated jffs2: 1983630, 1983K (3%) mkfs.jffs2 : 2344068, 2344K (3%) zipped : 389259, 389K (0%) .tar.gz: 399360, 399K (0%) .tar.bz2 : 184320, 184K (0%) It looks like there's easily a meg to be had there, two meg looks doable. Where to go from here is another issue. total flexibility and 90% of the size gain could be had by using pngs (not sure if there is a speed issue there) If there were to be a simple runlengh encoding, the bulk of the size would go and jffs2 would crunch the remainder. wadeb whipped up a tiny rle compressor/decompressor pair. gzipping at a file level removes the block overhead and the size drops to about 380k. For smallest size, lzma compressed rle files. appear to be the best. lzma isn't in the default install. It is small at 90k and has potential other user applications. 6325 frame00.565.gz 2283 frame00.565.lzma 15236 frame00.565.rle 1841 frame00.565.rle.gz 1451 frame00.565.rle.lzma 28097 ul_warning.565.lzma 30594 ul_warning.565.rle.gz 22935 ul_warning.565.rle.lzma The final compression method is colour-of-the-bikeshed stuff, the important thing here is freeing up the 2 meg. Whether the actual saving can be1.9MB or 2.2MB is less important. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Frame Decision (was [sugar] OLPC priorities for Sugar in the August release)
On Saturday 17 May 2008 5:26:06 pm John R.Hogerhuis wrote: > One possible idea: rather than popping up the frame when near the edge, pop > up a translucent overlay in key places that looks just like the keyboard > frame key. If the user clicks on it, then bring up the whole frame. I had been pondering if that could be done as a solution also but to do something like that would require somethink like a compositing WM. I have a vague feeling it could be done with some low level geode hacking, but a simple overlay is tricky because it's the size of the screen with a hole in the middle. I wouldn't actually be opposed to the frame being some sort of special class citizen with specific driver support myself since it's a single unique and integral component (much like the mouse pointer being a hardware sprite). Of course The person who would have to implement this would probably be spitting tacks at the thought of it :-) A concern for me is the redraw required as the frame retracts. On particularly heavy load windows the redraw can take some time. If the repaint on frame retract could be avoided(by overlay or even a clever save-under scheme) then that would be a benefit. It would also allow a solution by where the time it takes for the frame to retract is decided as proportional to how long the pointer has been in a trigger-zone. so if you just bang the mouse into the corner and away again (something my daughter does all the time) The frame starts to appear but disappears just as quickly. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: View Source question
On Saturday 17 May 2008 11:27:29 am Robert Myers wrote: > 'View Source' is touted as one of the user win features of the XO. There > doesn't seem to be much useful discussion of it on the wiki. > > What's the best path for making an activity 'view source' friendly? > Reverse engineering from Chat, which is? Some other way? > > Chat is monolithic. Is there a way to make a multi-file activity 'view > source' aware? Or does one have to roll the activity into a single file? View source is a nice idea, but I hardly see how it could be practical. You could implement it at a level of having a key combination to open the current activity in develop. You wouldn't want a single key for that since it's a significant operation that you don't want to launch by mistake. At any other level it would be nigh on impossible to implement it meaningfully. You treat it as a sort of breakpoint event which opens up a simple text view of the current .py file being executed at that moment, but code flows all over the place when it's active and when it's not you just end up at a message loop. What a user would want is for the view to open up on code that is semantically relevant to what the XO is doing in relation to the user, that is a tough nut to crack from an automatic perspective. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: c preprocessor.
On Friday 16 May 2008 6:06:10 pm Martin Langhoff wrote: > What happens if we remove it? Well, it looks like Ubuntu tried, and > had to revert It looks like they just removed the dependency rather than a replacement. xrdb supports -cpp filename preprocessor to use [/usr/bin/cpp] so a smaller replacement is a possibilty here, tcc or mcpp The other option is to just ensure that resources do not need preprocessing. I'm not sure if that is viable but isn't xrdb simply a thing that happens at x startup? Once into X everything is ok, right? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
c preprocessor.
I noticed today that my xo (newly 703) has cpp which while modest in size seems to launch /usr/libexec/gcc/i386-redhat-linux/4.1.2/cc1 which weighs in at 5.1Meg Anybody know what this is used for? would either TCC or mcpp be up to the same task? This work http://www.gnome.org/~lcolitti/gnome-startup/analysis/ mentions that cpp is used by xrdb. If it's a similar case on the XO then an improvement in boot time and space could be had. My line of thinking is that if it's going to go to the trouble of being half installed maybe the rest of might as well be there. If not, can it be eliminated. pros and cons in either direction really. If not gcc then tcc is certainly worth a look, 100k for a c compiler is fairly good bang for your byte. http://fabrice.bellard.free.fr/tcc/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
