Re: languages et al.
On Nov 24, 2007 5:31 PM, Ed Montgomery [EMAIL PROTECTED] wrote: The really scary people are like James Platt (who, unfortunately is no longer with us), on the OED team, who was famously quoted as saying: consulted linguistic advisers, such as James Platt who knew scores of languages I had a high school teacher like that. We were pretty sure he could speak more than 20 languages, although we never asked. Every year or two he would take up another, learning in part by teaching the extracurricular Language Club. I learned a bit of Swahili and Chinese this way. and once famously declared that the first twelve tongues were always the most difficult, but having mastered them, the following hundred should not pose too much of a problem. I have said the same thing about computer languages. You should know how to express the common algorithms and data structures in LISP, FORTH, APL, Smalltalk, SQL (or better still QBE), and some more conventional language like C or Python in order to understand what it is possible to say, and have some idea how to say it given different kinds of facilities. After that, almost everything is an instance of something you know well. Programmers used to be mostly aggressively monolingual in the days of FORTRAN and COBOL, but you can't operate that way anymore, what with XML (LISP with named parentheses), various scripting languages, and the like. -- Edward Cherlin Earth Treasury: End Poverty at a Profit http://wiki.laptop.org/go/Earth_Treasury The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Doc pages (Was Re: Emulators (Was: Status of the OLPC))
On Nov 24, 2007 3:17 PM, Bernardo Innocenti [EMAIL PROTECTED] wrote: On 11/24/07 13:56, Chad Z. Hower aka Kudzu wrote: I'll post a blog how to easily get it running in VMWare for others. Why don't you just edit the wiki page instead? Despite the scary notices about pages being maintained by the OLPC team, our wiki is publicly accessible! Either create a new page and link it around, or add a new chapter below the qemu one. How can I tell what build it is so I can reference from xxx and up etc? Switch to the console: the build number appears above the login message. If not, cat /etc/issue. Also what are all the other img files? How to know what is what? We have jffs2 images for the flash, a plain tar.gz archive, the crc file, etc. Some more documentation would definitely be needed, but on the front page of the wiki you can find a pointer to the latest updare images. I've started pages on the Wiki for hardware and software reference manuals, linked from OLPC Publications. Everybody should feel free to add or link to appropriate content, or to raise issues on the discussion pages. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Edward Cherlin Earth Treasury: End Poverty at a Profit http://wiki.laptop.org/go/Earth_Treasury The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Fwd: Keyboard switching
On Nov 24, 2007 6:04 AM, Sergey Udaltsov [EMAIL PROTECTED] wrote: Edward, will need to allow for countries that use three or more scripts routinely, for students of history, religion, and other subjects involving historical source documents, and especially for students of languages. FYI, X does not allow to have more than 4 groups in one configuration. If you need more - you have to reconfigure XKB. In 99% it is not an issue - but I know there are multilingual people who are unhappy about it. They have to use some workarounds. We don't have to preconfigure everything in the xorg.conf manner. All we need is a right button menu, like that for SCIM, allowing users to choose a keyboard layout, and possibly an editor for that menu. The menu selection can then invoke a call to setxkbmap. Mongolia would like traditional Mongol alphabet, Cyrillic, and Latin, and possibly Chinese. Certainly if we include Inner Mongolia. Plus Buddhist languages, including Sanskrit and Tibetan. Do they need all these scripts in one configuration? Not everybody needs all of them. Chinese is handled by SCIM, not by X keyboards. But you have to ask teachers and students in both Mongolias what they need. You can't decide for them. China has more than 50 legally-recognized minorities, several with their own writing systems (Tibetan, Mongolian, Uighur, Yi). Do you know many people who would use all these writing system at once? I know of people who would like Chinese and two or three keyboards, and a few who need Latin, Mongolian, Cyrillic, and Tibetan. In general, I'd tend to agree to your point that changing keyboard configuration should be more accessible than it is now. At the very least, it should be properly documented and explained. Probably, simple GUI configuration should be available for that task (by simple I mean it should not necessarily expose all powers of XKB configuration machinery). Yes, it should only offer standard options on standard layouts. Bernardo, I think you concern about making the device screwed by choosing fancy layout is a bit of exageration - there is always touchpad which could be used to find the restore default button. As I was saying, the whole apparatus should be on a right button menu. Cheers, Sergey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Edward Cherlin Earth Treasury: End Poverty at a Profit http://wiki.laptop.org/go/Earth_Treasury The best way to predict the future is to invent it.--Alan Kay -- Edward Cherlin Earth Treasury: End Poverty at a Profit http://wiki.laptop.org/go/Earth_Treasury The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Keyboard switching
We don't have to preconfigure everything in the xorg.conf manner. All we need is a right button menu, like that for SCIM, allowing users to choose a keyboard layout, and possibly an editor for that menu. The menu selection can then invoke a call to setxkbmap. Yes, this way you'd get any layout you want, any number of them. But usability-wise right button menu is a horrible thing. For people using 2-4 layouts, much more usable solution is switching using keyboard (some shortcut). And that's the first thing which should be taken care of IMHO - from both configuration and UI POV. Sergey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
Edward Cherlin wrote: On Nov 25, 2007 10:57 PM, Albert Cahalan [EMAIL PROTECTED] wrote: Mike C. Fletcher writes: If we are serious in our goal of educating children, we need to do a few things, and some of this requires a readjustment and a detachment from the question of which hardware goes where. Does the hardware matter? Yes. Yes, the low power consumption, wireless mesh networking, camera and microphone, and non-toxic construction matter. The known set of ports matters. Knowing exactly how much memory is available matters for some purposes. But those are all nice-to-haves, compared with being able to run the software at all. We can already run a nice subset of the laptop software from a Live CD on almost any x86 computer, including Macs. It would not take much effort to create a new ISO file with an up-to-date image. A closed platform has some advantages. The fact is, though, that we no longer have a closed platform. There *will* be Classmates and EEEs out in the field. Children should *not* be blocked from our educational content just because they got the wrong kind of computer[1]. Despite the special hardware, most of the XO is pretty much bog standard at the coding level. It's an i586 class processor with a web cam accessed via v4l and a microphone. It has a very high resolution screen (which requires a bit of special coding, but the emulators can run at 72 dpi already with a small hack). It has some game buttons, we need to support those, but they're mapped to extended keyboard keys by default anyway. Resource compression ratios and fixed screen-sizing are fine, but to reach a few million extra kids it's probably worth re-running the converter and doing a bit of testing on the screen layout. The most difficult changes to adapt to are probably in the aggressive suspend stuff. Most machines are going to go nuts if the OS tries to suspend and resume them every fraction of a second... so we might have to use a less aggressive suspend... maybe set an integer somewhere... and then as the other machines get aggressive-suspend kernels and test them, we can ratchet down the number for them too. Standardized hardware means I can count on having things, and I can optimize. There is a microphone. There is an input that can measure DC voltage levels. There is a camera that does 640x480. The side of the camera with the user's face is quite predictable. There are 3DNow! instructions. JPEG compression levels can be made appropriate to the display. Images can be in ideal sizes. The kernel and X server don't need to ship a zillion drivers. The control panel can be managable. Again, for a few million children, it's probably worth porting to another machine. It becomes 3 set hardware platforms instead of 1. It requires resources that we're short on, no question, but it isn't a project on the order of a new OS, it's a project on the order of a few weeks of a guru Fedora sysadmin to figure out what's needed and compile and package that. we should port to the other inexpensive laptops, if a country decides to go with EEEs or Classmates, we should be in there offering an EEE or Classmate-optimised Sugar + Activities + Content that they can load onto those machines This is a mixed bag. It dilutes the message. The message is already diluted, or perhaps polluted. Intel and Microsoft have seen to that. It is vital that XO software run unaltered but with fewer features on alternate computers that lack some of its hardware. Then the fact that free software that runs on their machines is actually better on our cheaper XO laptop is a major market advantage. The XO is iconic, and it is powerful as a delivery mechanism for the message of making education available to the underprivileged children around the world. But in the same way as the crank was iconic, and was a powerful delivery mechanism for the message, the XO is just part of the message. The XO is already winning the battle to get inexpensive computers to the forefront of manufacturers' minds. In doing so, it has convinced those manufacturers to build their own machines. We should not be so tied up in a single message (particularly one about selling laptops) that we subvert our own goals. There is something like 50% of the world without reliable power, and the XO was designed for that 50% of the world. The fact is that none of the other manufacturers are going for that 50% yet. There's plenty of room in the pool. For the other 50%, a Classmate or an EEE might be the choice of their government. If we abandon those children's education on the alter of the purity of our message, what are we really about? It's an education project, not a laptop project. That is our proper message. It's right there on the about page. It's the message we should be unwilling to subvert. Choose a laptop model, we have one that is designed for this kind of deployment
Re: WSJ
On Nov 26, 2007 2:47 AM, Edward Cherlin [EMAIL PROTECTED] wrote: On Nov 25, 2007 10:57 PM, Albert Cahalan [EMAIL PROTECTED] wrote: Mike C. Fletcher writes: we need to make use on multi-user machines easy, where Sugar is just a desktop manager session that is run just as one would run KDE or Gnome (so that computing lab situations can let children use Sugar's safe, rich without giving up the ability to run KDE/Gnome) Activities which don't need special XO hardware features should just run, right from the GNOME menu, without anything extra. Activity authors should have an easy way to specify if this means full-screen or 1200x900 in a window. We have Gnome on the Live CD now. What prevents us from installing it on XOs? Well, RAM will get you. I don't believe GNOME is all that important, despite the fact that I use it. I'm using it just for the task bar thing; I even disabled nautilus and all that silly desktop stuff. Having a working window manager is another matter though. I feel like such a conspiracy theorist here, but... The thought that has always come to my mind is Python cabal. At times it feels like things are maliciously non-standard, as if intended to exclude normal Linux software. We need to get that Sugarizing code for non-Python apps like Etoys onto a Wiki page. The crazy thing is that Bert has been a 1-man documentation shop, despite not being the author of the code in question. He's some kind of hero. He shouldn't need to be. APIs need to be documented by the people who create them. There has been a long-term absolute refusal to do this. A simple xterm should work, no matter if it is started from the console or if it is on a separate machine with $DISPLAY set. Switching to and from the xterm should work perfectly. The icon and title should be used for the donut display. I'm sorry, what's wrong with the current standard console and Developer's Console? All it takes is Ctl+Alt+F1 or Alt+0. There are things wrong, but that's not the point. Pretend my example was xclock, or xeyes, or any other simple thing. A simple $PROGRAM should work. That means remote display onto the XO from elsewhere, switching to and from, the icon getting shown in the donut, the title or icon title getting shown in the donut, and so on. (FYI, what is wrong: 4 left pixels cut off on the console, dreadful font on the console, no CJK or compositing on the console, only 256 characters on the console, no UTF-8 at all in Terminal, less than 80 columns in Terminal, screen motion problems with yum in Terminal, etc. The vttest program may help.) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
Mitch Bradley wrote: Mike C. Fletcher wrote: It's not About the Hardware: In principle, that is true. In practice, it is the hardware that has been responsible for all the attention. If the project had been just a software framework to support constructivist education, the worldwide response would have been ho hum, yet another program/operating system/GUI/whatyoumaycallit. Agreed. The hardware was key in forming a vision. The idea of a laptop so inexpensive that it could be given away to the children in the developing world en-mass was an idea that caught the minds of the world. So too was the crank (impractical as it would have been in that position). The hardware captured the imagination, and I'm still of the belief that it's a marvel of engineering. It has generated excitement and enthusiasm and has made the project fly. The physical joy of the design is inspiring. The sturdy presence of the device is comforting. The XO is marvelous. I still think we need to get the XO hardware out to the 50% that the manufacturers aren't targeting. We need the XO hardware to reach the children in the back woods. But I would suggest we need to bring Asus and Intel/Classmate into the project so that we can reach those whom the hardware will not reach. The message we will do what is necessary to give the children access is powerful. We've already shown that, given an absence of a tool, we'll put together a multi-year engineering effort to provide that tool. That's a powerful message, and the XO is the iconic result of that effort. What I'm suggesting is that now what is necessary is to partner/connect/work with these other organizations to make sure we aren't fragmenting our efforts. I love the cute hardware... Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC XEyes
--- Don Hopkins wrote: PLEASE PLEASE PLEASE, somebody sugarize XEyes! It's the cutest X application that runs on the OLPC without any modification. We just need a way to launch it from the frame! http://www.donhopkins.com/drupal/gallery2/v/Devon/IMG_0135.JPG.html Now you can see why my OLPC has tooth marks in the handle: http://www.donhopkins.com/drupal/gallery2/v/Devon/IMG_0144.JPG.html -Don --- end of quote --- Do you have a link to the code for XEyes? - AlexL ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC XEyes
On Nov 26, 2007, at 17:49 , Greg DeKoenigsberg wrote: On Mon, 26 Nov 2007, Don Hopkins wrote: PLEASE PLEASE PLEASE, somebody sugarize XEyes! And then write a tutorial on how you did it. :) Tutorial how to do it in Etoys (SCNR): 1. Start Etoys 2. Click Make a Project 3. Click Supplies in the toolbar (the box icon) 4. Drag out the Object Catalog 5. Select the Just for Fun category 6. Drag out one MovingEye, close catalog 7. Right-click eye, resize using the yellow handle 8. Duplicate eye using green handle 9. Rename to Eyes in toolbar, quit. Voila. Now you have an Eyes project in your Journal ready for endless hours of sillyness. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
Bernardo Innocenti wrote: On 11/25/07 18:58, Mike C. Fletcher wrote: * we should port to the other inexpensive laptops, if a country decides to go with EEEs or Classmates, we should be in there offering an EEE or Classmate-optimised Sugar + Activities + Content that they can load onto those machines o we should also port to the thin-client-style setups seen in e.g. Canonical's deployments of computing labs in the developing world That would be a good idea, but we clearly lack internal resources. Yup. All the code is out there and I bet everybody in the Sugar team would be glad to help whoever wants to port it to the Classmate or any other laptop. Which is where I come in, I suppose. I need to find someone who wants to do the port. Ellis has suggested they're willing to donate an EEE and maybe even do some load it and see if it runs tests for us once we produce an image for them. I just need to find some Fedora Guru who wants to help change the world to do the work. I unfortunately don't know all that many Fedora Gurus (just one, actually, and he's already working on the project). If people know a sysadmin Fedora Guru who they think would be interested, let me know. ... AFAIK, both the mainstream desktops were far too bloated to be usable on the XO. I can easily believe it, as the latest versions are almost unusable on my 1GHz iBook G4, too. Porting Gnome or KDE to the laptop would require help from the respective teams to further optimize them and stripping down some advanced features and some configurability. I seem to have confused a lot of people on that point, I was referring to running Sugar on other machines that normally run Gnome/KDE, not running Gnome/KDE on the XO. * we need to get our installation requirements on non-Fedora Linux down to a package-level installation o (and have this be supported and maintained (preferably internally)) o (also very useful for encouraging developers) I wonder what's the status of Debian and Ubuntu for running on the OLPC. Once the platform part works well out of the box, installing sugar should be just a matter of using alien. Debian and Ubuntu are the farthest along here AFAIK. They have packages. The packages don't seem to like living alongside a jhbuild installation (hosed my laptop when I tried that), but they seemed to run the packaged apps fine. I need a few days I don't have to sit down and test that further. At this point, not even Fedora officially supports the OLPC out of the box! I'd like to see our kernel and platform bits go upstream and appear in all mainstream Linux distros. Even if we cannot afford to put resources on this, I'm sure the core developers would be glad to answer questions on IRC and on this list. Yes, again, we need sysadmin-guru people to do this kind of work. We need to see supporting such people as important, but the core team is likely too busy to do much work on it. If we are serious about educating children, and we truly believe that the software and content we are creating is key to allowing children to learn well, then we need to make that software and content available for all of the projects that are sending computers out in the service of educating children. I couldn't agree more on the general principle, but operating systems and desktops are just a small subset of educational content, and not even a very interesting one for teaching to little children. We shouldn't let ourselves (as OLPC) get distracted in porting 20 different Linux distros to the laptop when we're missing a good astronomy and chemisrtry activity. I'm not suggesting that we need to core developers to do this work. For any given Linux distribution, porting should be just a matter of getting someone from the distro who is interested in porting. Most of the work will be quite mechanical I would think, just a matter of figuring out how your distribution deals with SRPMs as foreign packages and using those to build your native packages. Then all the fun of conflict negotiation and the like, of course. What we might need from the Core devs is a way to kick off a Sugar session as a desktop shell from GDM/KDM/XDM (i.e. the multi-user stuff), and some thought on whether running in a multi-user environment is going to cause problems somewhere. I don't know the mechanics of that interaction all that well, but I'm guessing it's a pretty trivial amount of code in the core. Standardisation and Application Availability: [...] As much as I appreciate software diversity and the network effect it enables, I'm not convinced there's much educational value in providing the full range of Fedora (or Debian) packages. Our target audience is, for the most part, really not interested in traditional GUI applications and even less in UNIX
Please increase stability in joyride...
I note that over the last few days, people (who will remain nameless) have dumped things into joyride without adequate testing, causing regressions. We are well beyond feature freeze, and into only fix the important bugs phase. For the record, I consider a change in how packages are built as risky as invasive changes in a package. While I am as anxious to see our packages rebuild in a consistent environment as the next guy, changing the environment in which a package is built is similarly risky, this can wait until after Update.1. Such rebuilds essentially invalidates all previous testing of that package, as both the compiler, build flags, and libraries might all affect the behavior of that package as rebuilt. Thanks for your cooperation; the release is in sight... - Jim -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
helping the OLPC project with ejabberd
Hello Ejabberd Community,
I'm one of the people at Collabora Ltd (www.collabora.co.uk) working on
the collaboration stuff in the OLPC (One Laptop Per Child,
www.laptop.org) project. We're using our Telepathy
(telepathy.freedesktop.org) framework to present the same APIs to the
shared activities whether or not the laptop is using link-local
XMPP/mDNS/multicast or an XMPP server to communicate.
For the XMPP server, we're using ejabberd running on jabber.laptop.org
(and also a test server on olpc.collabora.co.uk), but in a rather
unusual configuration which is turning out to be quite unreliable. As
our expertise is more focussed on the client side software, we'd like
some assistance on how to improve things on the server side,
particularly some input on making a more scalable solution.
We've written up some documentation explaining how we've configured our
ejabberd:
http://wiki.laptop.org/go/Ejabberd_Configuration
And the server extensions/protocols we make use of:
http://wiki.laptop.org/go/XMPP_Extensions
For more general documentation about how the shared activity stuff
works, see:
http://wiki.laptop.org/go/Activity_Sharing
http://wiki.laptop.org/go/Shared_Sugar_Activities
http://wiki.laptop.org/go/Shared_Activity_Protocol_1.0
Currently the jabber.laptop.org server is running 1.1.3 with Magnus
Henoch's PEP support patched in, and has about 50 active users and 4000
accounts in total, and we *already* have some reliability problems. We
know that in the very near future we're going to get 1000s (or even
10,000s) more users from the G1G1 (give one get one,
www.laptopgiving.org) programme.
We know that the shared roster stuff is a crazy hack and we very
urgently need to stop relying on it, so we're planning to implement an
XMPP component to use as a registry of OLPC activities and buddies, so
that the client can search for or be notified about smaller, more
relevant sets of information, depending on what's being displayed in the
UI. However, while we're writing that, we need to make sure we can keep
our current configuration stable, and if possible make some server
configuration tweaks to help it scale.
(for example, Aleksey has told me a hack in mod_shared_roster to stop
the actual shared roster group from being included in the initial roster
push, although leaving the presence/PEP stuff behaving correctly, which
will help reduce the bandwidth usage at sign-on - we just present anyone
in the UI we have presence/PEP notifications for, rather than using the
roster for very much at all)
So, I've got a few questions which I'd be very grateful for any input on:
1. Does anyone have any ideas why our ejabberd sometimes exits (leaving
epmd behind, but no ejabberd processes) without logging anything, and
suggestions how to debug it?
2. Sometimes we see this in the log (although not recently on
jabber.laptop.org which runs 1.1.3, just on olpc.collabora.co.uk which
has 1.1.2):
=ERROR REPORT 2007-10-09 20:26:00 ===
Mnesia([EMAIL PROTECTED]): ** WARNING ** Mnesia is overloaded:
{dump_log, time_threshold}
What causes it? Does it result in any degradation of service?
3. The XO machines are intended to use just IPv6 at some point in the
future. Currently jabber.laptop.org is just listening on the machine's
IPv4 address even though it has a routable IPv6 address. How do we make
ejabberd listen on IPv6?
4. Thinking of making interim server-side fixes to aid scalability while
we work on an OLPC directory component, we don't actually need to see
*all* of the contacts in the roster. We actually just need a union of a)
the child's friends, b) people nearby on the network (imagine two
children with laptops next to each other, but not being able to add each
other, and c) some other people in case a and b are small/empty. How
hard would it be to patch mod_shared_roster, or make a new module, so
that you could:
a) have a group that had users that were e.g logged in on the same /24
(or equivalent /96 or whatever for IPv6) subnet?
b) have a group that had a random N (say 30) online users in, or
somehow assigned users to groups on the fly when they signed in so that
each user is in a group that has N other online users in?
5. Thinking of our XMPP component, we're no experts in erlang so we're
planning to write it in as an external component, probably prototyping
it Python. This has the benefit that it can be used with other Jabber
servers, reducing the disruption to existing server admins who want to
support XO clients. We'd like to know if there are any ways that an
external component can access any of the information in the server, such
as people's presence, rosters, what PEP nodes they have, or even what
MUC rooms they are in. Anything we can find from the server will help us
reduce the need for clients to report redundant information to the OLPC
server component.
Many thanks in advance for any advice you can offer.
Regards,
Rob
___
Devel mailing list
Testing GIT integration with Pootle
Hi all, Before allowing translators to commit their translations to GIT using Pootle, I have started to test the entire setup for one final time, and for the past few hours, I've been randomly pushing PO files for different languages for different modules into the dev.laptop.org repository. If your activity build process somehow breaks due to errors in the po/ directory (we have ironed out most issues, so this is unlikely to happen) - you know whom to blame :-) Please file a ticket immediately under the component localization and assign it to me (sayamindu). You may also ping me on IRC (my nick being unmadindu). Thanks for your cooperation and help, Cheers, Sayamindu -- Sayamindu Dasgupta http://sayamindu.randomink.org/ramblings ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Networking hangs
Please try Update1, build 641. The latest wireless firmware and kernel changes for the 4470 fix are in this build. It's been up for more than 12 hours. The network is still working. Thanks. -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
Mike C. Fletcher wrote: Which is where I come in, I suppose. I need to find someone who wants to do the port. Ellis has suggested they're willing to donate an EEE and maybe even do some load it and see if it runs tests for us once we produce an image for them. I just need to find some Fedora Guru who wants to help change the world to do the work. I unfortunately don't know all that many Fedora Gurus (just one, actually, and he's already working on the project). If people know a sysadmin Fedora Guru who they think would be interested, let me know. I hear on #olpc that Dennis Gilmore is going to make Sugar a desktop option for Fedora along with KDE and Gnome. Joel Stanley said that Sugar is already available for Ubuntu too, but I didn't have a chance to try it out yet. So you just install one of these distros and then do the additional customizations you need. Seems easy, doesn't it? Well, it's still a lot of work if you care to give your users a good experience. Most of the work will be quite mechanical I would think, just a matter of figuring out how your distribution deals with SRPMs as foreign packages and using those to build your native packages. Then all the fun of conflict negotiation and the like, of course. Yes. I can't get involved at this time, but 'm willing to accept patches for the packages I maintain. What we might need from the Core devs is a way to kick off a Sugar session as a desktop shell from GDM/KDM/XDM (i.e. the multi-user stuff), and some thought on whether running in a multi-user environment is going to cause problems somewhere. I don't know the mechanics of that interaction all that well, but I'm guessing it's a pretty trivial amount of code in the core. Yeah, most of the work will probably involve fixing hard-coded paths, resolutions, and other incorrect expectations we made in the various activities. From what I remember of that code, I'm pretty confident about the Sugar core being quite sensible already. Traditional Activities/Applications Needed: * Vector Graphics (Inkscape) I remember one of the authors of Inkskape saying that he'd be interesting in sugarizing it. But, as useful as Inkscape may be for general users, I'm not sure if such advanced vector drawing would be appropriate for primary school kids. Maybe paint is all they need. * (Full-featured) Raster Graphics (Gimp-class) * CAD Software (PythonCAD?) * Personal Finance (budgets, running farms/shops) (GNUCash? or LedgerSMB?) * Spreadsheets (Gnumeric?) * IDEs/Dev Tools (Eric? Boa Constructor? Glade? SciTE? MIT's Java Tinker-toys?) Again, useful applications for us, not that much for an 8 years old. Note that I'm intentionally avoiding to say not at all useful. I'm usre a few geeky kids may like the CAD or even an IDE. I used to be like that :-) There's certainly some need for these advanced applications, but not as much as there's still need for better educational software bundled with the laptop. If we have spare time, we should try to improve these. * Science (choose any discipline) (KStars, PyMOL, ?) These would be great to have! I'd add Kaltium to the list. We know our users *are* interested in the finance and spreadsheet applications (the pilot program in Nepal explicitly asked for them). Really? I'm very surprised, but if there's really strong demand, then I'll withdraw all my previous statements. I'd be willing to accept that parents and teachers want to use their kid's laptops for other purposes. And maybe we should spend a little (little!) of our time trying to support them too. I guess in some countries we're deploying to, we can't just say parents should just buy a normal laptop for themselves. But I seem to remember that making the XO explicitly a child-only machine was an intentional design goal tailored at removing the motivation for an adult of stealing the laptop from a child. It would certainly be nice if we could at least use them as a fallback. But I'm afraid I too am somewhat ignorant of the issues surrounding it. My dream is that with just a description file (think a .desktop file on steroids) we could have Sugar run any regular Linux GUI application (unmodified code) which is packaged in some way. Yes, I'd like that too. Why on steroids? The XDG specification should be generic enough for Sugar to implemnet as-is. Indeed. We have an xo - rpm converter. I wonder if doing the opposite would be feasible, at least for simple cases. AFAICT you need an overlay system to make this work with the whole-system-image operations. That is, you need to be able to isolate the effects of the RPM to a directory that isn't part of the system image, which means AFAICT you need to use an overlay. You might be able to convince some software to work in a directory with root setting, but it wouldn't be universal. Sounds like too much trouble for too little success rate.
Re: OLPC XEyes
Integrate with face recognition using the camera, solve the trigonometric problem of where the largest face is relative to the centre of the screen, then warp the pointer ... so that the eyes follow the nearest face. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 340
Ooops, looks like all my rpms was reverted... I had made ~/public_rpms/joyride a symlink, maybe that confuses the build system. I changed it back to a real directory, let's see if that works. Please ignore this build. Marco On Nov 27, 2007 1:30 AM, Build Announcer Script [EMAIL PROTECTED] wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build340/ -Etoys-69.xo +Etoys-70.xo -Journal-74.xo +Journal-75.xo -etoys.noarch 0:2.2.1784-1 +etoys.noarch 0:2.2.1793-1 -evince-olpc.i386 0:0.3-1 -fonts-thai-ttf.noarch 0:0.4.4-1olpc1.2 -gtksourceview2.i386 0:1.90.3-3.olpc2 -info.i386 0:4.11-1.fc7 +info.i386 0:4.11-2.fc7 -kernel.i586 0:2.6.22-20071121.8.olpc.72714fb50756a41 +kernel.i586 0:2.6.22-20071126.1.olpc.3cf0ba3149aefdf -ohm.i386 0:0.1.1-5.7.20071124git.fc7 +ohm.i386 0:0.1.1-5.9.20071126git.fc7 -olpc-utils.i386 0:0.46-1.olpc2 +olpc-utils.i386 0:0.48-1.olpc2 -poppler.i386 0:0.5.4-7.fc7 +procps.i386 0:3.2.7-16.1.fc7 -procps.i386 0:3.2.7-16.fc7 +pygobject2.i386 0:2.12.3-3.fc7 -pygobject2.i386 0:2.14.0-1.fc7 -pygtksourceview.i386 0:1.90.3-1.fc8 +sugar-artwork.i386 0:0.34-0.33.20071102git.0763fefc48 -sugar-artwork.i386 0:0.40-0.1.git288e365b29 +sugar-base.i386 0:0.1.1-1 -sugar-base.i386 0:0.2-0.1.git084d55045a +sugar.i386 0:0.70.2-1 -sugar.i386 0:0.75.0-0.2.git9ab0ef9e23 --- etoys.noarch 2.2.1793-1 --- * fix joining shared activity (#3758) * fixes for popup-carets (#2807) * no sandbox and key generation in rainbow (#4787) --- ohm.i386 0.1.1-5.9.20071126git.fc7 --- - Disallow all power management (suspend, dcon power) on pre-C machines. --- Etoys-70 --- * fix joining shared activity (#3758) * fixes for popup-carets (#2807) * no sandbox and key generation in rainbow (#4787) --- Journal-75 --- * Change to activity-start icon, #4825 (rwh) -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/joyride-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
C2 vs. C1/B4/B3 vs B2
There has been some question about what might or might not work on different builds of laptops. The laptops MUST be running the latest firmware (q2d05 or later) and a recent kernel for the following to be true. Everything works on a C2 with the exception of a few items in Trac and some yet unknown ones... On a C1/B4/B3: - There may be occasional crashes (possibly made worse by suspend/ resume) when the battery is running low. Above 25% of capacity, or plugged into a power adapter, you should be OK. (#1835) - There may be times when the WLAN (USB) hangs (possibly made worse by suspend/resume). (#1752,#4476) - Power cycling the DCON is liable to crash the laptop. This power cycling will occasionally happen in response to a DCON bug triggered by suspend/resume. (#4479) - Rare crashes may be caused by other sources during suspend/resume (Camera, SD card, clock settling time), some units (especially B3s) may be more sensitive than others. (#1835) On a B2: - All of the problems listed for C1/B4/B3 are present. - The keyboard/touchpad may not be used to wakeup from a suspend/ resume. (#895) - The DCON will glitch coming out of suspend/resume. (#947) Cheers, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
Mike, but if a country wants to choose Classmates or EEEs, that's fine, we *still* want to help educate those children. Yes, I totally agree with this, and other sections on teacher training and documentation, etc., etc. * we should port to the other inexpensive laptops, if a country decides to go with EEEs or Classmates, we should be in there offering an EEE or Classmate-optimised Sugar + Activities + Content that they can load onto those machines o we should also port to the thin-client-style setups seen in e.g. Canonical's deployments of computing labs in the developing world It sounded in the article, though, that some countries have chosen Classmates because of MS Windows. How about porting parts of current OLPC software that is worthwhile for Windows users? What would such parts be? And, I see that one of the biggest downside of our software is that kids cannot participate the software development effort from their laptops (except...). If we are to look at different platforms, it is nice to think about easy support of on-laptop-development. I don't care if it is on Windows or Mac OS; on top of Windows (or Mac OS), you as an end-user can still do a lot. (Basically the same argument in filtered Internet access is better than no Internet access.) -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
It's not About the Hardware: In principle, that is true. In practice, it is the hardware that has been responsible for all the attention. Alan Kay once said: Reality is a low-pass filter. (High-frequency ideas cannot go through it.) If the project had been just a software framework to support constructivist education, the worldwide response would have been ho hum, yet another program/operating system/GUI/whatyoumaycallit. Thank god our project is not like that. With that hardware and great software and content (that potentially also work on other hardware) will make a kick-ass learning platform. The latter needs more attention to really achieve that. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
