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 and is available at cost, but there are others if you prefer. Have the manufacturer flash this image on them. Work on your curriculum and deployment plans (here are samples and here are experts who will work with you if you like). Set up your country-level infrastructure (here are sample specifications if you like)." We help give children access to the social and intellectual resources of the world by making computers act as educational tools. We help educate children. >>> 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? > This is *not* the thrust of my suggestion, rather, I want Sugar running on *other* machines, machines such as those found in thin-client labs (and other inexpensive laptops). I rather like the Sugar desktop as an environment for 7-11 year olds, it's reasonably simple and very elegantly designed. It is also currently the only place that many of our activities will run. We want Sugar to run *everywhere* if possible. >> The ultimate goal should be to have activity isolation be a >> normal part of the business desktop. Sugar can melt away as >> the ideas get put into regular software. >> Certainly, but for today and tomorrow, there's still a lot of stuff that the regular desktop just doesn't have and which will prevent our activities from running outside Sugar. >>> For the other countries, we need to address their concerns. It >>> seems that at least some of the concern is because we have >>> introduced a huge barrier to entry for application porting. That >>> means we have a pool of dozens of applications instead of hundreds >>> or thousands of activities/applications. Even compared to other >>> Linux-based solutions, we have a tiny pool of available >>> applications, many of which are still in reasonably early stages of >>> development. We are missing whole classes of application/activity. >>> > > It's much easier than Debian packaging of apps that come out first in > RPMs. We could organize a bunch of schoolchildren to do it for > hundreds or thousands of apps. We could probably automate most of the > process. > I'll have to take your word for it. I haven't yet seen an elegant method for such packaging that produces a launch icon and doesn't require arcane command-line operations to install or run the activity. I am *really* interested in this, though I have to confess I've been working elsewhere and may have missed a simple recipe showing up. I just spent three hours yesterday trying to get it to work with the overlay system as originally described in Bitfrost and had no luck. I realise we can use RPM to install, but to create a re-installable package that we can share with other users, that creates an icon, that doesn't require futzing about on the file-system level... it has as of yet eluded me. Please, share. >> 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. >> It's those darn Python programmers. Kill them a.... oh, wait. I would suggest that it has been more the siren call of thinking of the platform as a closed "embedded-style" platform where backwards compatibility is considered of secondary importance. When you start from that position it's fairly predictable that you will come up with something (slightly) non-backwards-compatible. There has (luckily) been a strong countervailing force in the project that has tried to push *the technologies* into the underlying desktop OS, so most of the compatibility issues are way up at the "desktop shell" level. The desktop shell being in a fairly flexible high-level language it should be possible to (and is, from my understanding a current project to) add support code to let those X applications run with a bit of magic. > We need to get that Sugarizing code for non-Python apps like Etoys > onto a Wiki page. > Indeed! >> 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. > I think he was using it as an example of a "dirt simple X application", rather than as a *particularly* needed application. Taking the icon and title from the X icon and title has (I think) already been added (would have to ask about that), but the installation and specification of the activity so that it shows up in the launch bar doesn't AFAIK work yet. >> Shipping full-screen programs does not mean that the window >> manager should be incapable of handling anything else. It may >> be good for the window manager to automatically attempt to >> size a window to fill the screen, but the window manager needs >> to handle the case when that doesn't work. >> Yeah, I'd agree on that one, despite the fact that I personally *always* work full-screen on everything. Excluding applications just because they want e.g. two top-level overlapping windows seems arbitrarily restrictive. Probably too late to change that one, I'm guessing. In the grand scheme of things it's probably not a huge issue compared to the application/activity count in total. >>> * we need some way for a regular, non-Sugar-fied application to >>> be installed (easily) and run (with reasonable support) on a >>> Sugar desktop. We should at least have the application-depth >>> of a *Linux* desktop available to our students. >>> o Even if they don't integrate nicely and they have file >>> dialogues instead of Journal dialogues (so you'll have >>> to switch to the Journal and add the file manually)... >>> practicality beats purity >>> >> Hack every common toolkit. Shared libraries are great. >> If you change the toolkit library, you get journal support. >> If I'm recalling correctly, that was the original design spec for Bitfrost's minimally invasive support level. Not sure if it got abandoned, pushed back, or reconsidered. Have fun, Mike [1] Companies which want to sell hardware haven't got the kind of massive content and software development project we have. If we don't make our results as widely available as possible, then the children using those machines will be stuck with edutainment software and a pot-luck of random content that can be thrown together. -- ________________________________________________ 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