Re: GTK widgets in C# was: Re: WSJ
Alle giovedì 29 novembre 2007, Chad Z. Hower aka Kudzu ha scritto: > Im already working on this. Im working on it in a way though to run more > effficiently than running as a normal JIT and instead working on a compiler > of IL that can use the mono libs. We already have quite a bit working. Sorry Chad, I don't understand what you're doing. Is it like the AOT (Ahead Of Time compiler)? If so, I know that this function works in the mono compiler. I never use it because, when you use the AOT option to compile a program, the metadata are stored the usual way, but the native code for all the functions is also included in the final binary, so the size grows. Ok, you can save the startup time the JIT compiler, but it is generally fast and called only once per each method, do I don't know how much performance improvement you get. Best Regards Torello Querci > > - Original Message - > From: "Scott Cytacki" <[EMAIL PROTECTED]> > To: "Torello Querci" <[EMAIL PROTECTED]> > Cc: > Sent: Wednesday, November 28, 2007 10:33 PM > Subject: Re: GTK widgets in C# was: Re: WSJ > > > Torello Querci wrote: > >> If you're interested in supporting Mono on the OLPC, I can create > >> a wiki where I'll put the code I've already written, because at this > >> time I'm > >> working alone. > > > > I am interested in supporting Mono on the OLPC. One thing I've wanted > > to try is running all of > > Sugar with IronPython. This ought to give C#, Java (through IKVM), and > > any other mono language: > > http://www.mono-project.com/Languages > > full access to the Sugar widgets and APIs. > > > > I don't have time to try this now, but when I or someone else does, it > > would be helpful to know what is > > necessary to run Mono. > > > > Scott > > > > > > ___ > > 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
Re: GTK widgets in C# was: Re: WSJ
Alle mercoledì 28 novembre 2007, Scott Cytacki ha scritto: > Torello Querci wrote: > > If you're interested in supporting Mono on the OLPC, I can create > > a wiki where I'll put the code I've already written, because at this > > time I'm > > working alone. > > I am interested in supporting Mono on the OLPC. One thing I've wanted > to try is running all of > Sugar with IronPython. This ought to give C#, Java (through IKVM), and > any other mono language: > http://www.mono-project.com/Languages > full access to the Sugar widgets and APIs. > > I don't have time to try this now, but when I or someone else does, it > would be helpful to know what is > necessary to run Mono. > > Scott Hi Scott, unfortunately, there are a few problems running existing Python code with IronPython because the glue level between Python and C library is managed in a different way. Python requires a specific C library to handle native calls, while IronPython uses PInvoke to do this. I'm now trying to implement a class library to run any mono program on Sugar, but being compatible with Python class libraries is not a priority at this time. Best Regards, Torello Querci ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
Thank you, Mike, > That said, activities which use the high-level components only might be > able to be ported just by rewriting the Sugar APIs with a Win32 > compatibility layer a port of Telepathy and a bit of bailing wire. That > might let children communicate and access the materials... but that > would be a fairly involved project, and I don't know if we'd find all > that many Win32 developers interested in attempting it. That would be useful for longer term. TamTam on Windows would be cool so you can jam with a Windows user over the net, for example. > > 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".) > > > Yes, we really need to get "Develop" development un-stuck. We currently > have only Pippy (which doesn't do files) and the Squeak IDE available > on-machine. We need that full Python IDE available for the children > ASAP. After all, we've got a whole key on the keyboard devoted to it. > Even if the IDE is just file-open/close/create, file-tabs and syntax > highlighting it would be sufficient to start programming on-machine. Yes. Maybe a Python IDE in Squeak is not a so bad idea. At some time soon, somebody in Etoys/Smalltalk community need to write up how to start Smalltalk programming on XO, such as making writable copies of etoys.image and etoys.changes to a directory and turn "eToyFriendly" preference off, etc. (Ah, that is almost it^^;) -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
Ed Trager wrote: > I have a few comments for this thread: > > -- > (1) Porting Sugar+Activities to Competitors' Offerings : No. > -- > > On Nov 29, 2007 12:12 AM, Mike C. Fletcher <[EMAIL PROTECTED]> wrote: > >> Yoshiki Ohshima 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 > > I disagree. Especially in light of the high profile that OLPC has > because of recent articles like the Wall Street Journal article, the > OLPC team and community should continue to focus their efforts on > their own hardware platform and not worry about EEEs or Classmates. > > To create EEE- or Classmate-optimised Sugar+Activities will only help > Asus and Intel sell more EEEs and Classmates. While Negroponte can > say that OLPC is "an education project" , it is an education project > with some real hardware that needs to be sold. This is just common > business sense that applies to non-profits like OLPC just as much as > it does to profit-making organizations like Intel. > > Since the platform (Sugar + Activities) are all in the free and open source domain, any group of interested individuals can pick this up and port it to other hardware, test it out and iron the bugs etc. be it for Classmate PC or Eee or Dell, or your favorite flavor of the day. I agree with Ed however, that at this point, the platform is more than Sugar + Activities. It is fine-tuned (or is being fine-tuned) for the XO and that's where the focus should be. So many other efforts seem to focus on the hardware and then maybe the OS (let's put Linux on the Eee or Classmate PC and we are done) that people tend to forget that the "platform" works really well as a package: hardware + OS + activities (apps) + network and so, if you substitute any one of the components, you will be distracting from the goals of the project. If Classmate or Eee are interested, they should really work with OLPC to port the stack to their hardware. In so many ways, this approach is like what Apple does or what Sun did and still tries to do. Hardware + OS + Apps. With OLPC, the network (p2p mesh and AP mode) also happens to be very central to the entire effort I am sure Eee and Classmate PC have enthusiastic crowds supporting their efforts. They should set up their mailing lists and get going. Start here http://www.gnu.org/software/mailman/index.html As for "for-profit" vs "non-profit" they both need business plans, which must have sustainable revenue to offset the expenses. cheers, Sameer -- Dr. Sameer Verma, Ph.D. Associate Professor of Information Systems San Francisco State University San Francisco CA 94132 USA http://verma.sfsu.edu/ http://opensource.sfsu.edu/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
Classmate and OLPC was on CNN (Europe) today in Nigeria. No mention of this - but compared Classmate and OLPC and showed schools in use. Slightly more coverage on Classmate - and compared not so much hardware and software but strategies of use, etc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
or option to install ... ) a full-fledged development environment on the XO. But that pool of developers is not the primary schoolers. The OLPC organization and community WOULD DO ITSELF AND THE COMMUNITY A SERVICE TO CLARIFY the different groups of people who will be using XOs and what they will be doing with them: (1) Primary Schoolers : Using the XO for learning and creative exploration. (2) Teachers: Using the XO for lesson planning, creating teaching activities, developing new activities, etc. (3) Middle & High Schoolers: A subset of this demographic will be using the XO to develop new activities for their younger peers. This is a more realistic possibility than thinking that 8 year olds care to look at Python code. (4) World-wide OLPC development community: Primarily an adult demographic, does primary development work for the OLPC project. -- (3) A Suggestion : Create an Enhanced XO Learning Environment for Older Students, (& Teachers, Developers, Etc.) -- Has any thought been given to what kids (i.e., primary schoolers) are supposed to do with their XOs after they outgrow them? As kids get older and reach their middle-school and high-school years, they are going to look at that cute little XO as yester-year's industrial garbage. They are going to want to buy an iPod Touch ($US 299.00 -- isn't that the same price as an EEE? ). Or else they will want to go for the really big kit and get a MacBook. Trust me -- I have a teenager in middle school. Be my guest to do your own research if you don't believe me. But kids in more impoverished nations may only get dream about such fun new electronic goodies around the holidays. (It is absolutely certain that they will have full knowledge of such products as they will have already thoroughly scanned the internet via their XOs). So what is a body to do? Well, here's a suggestion. Why not create an enhanced XO Learning Environment for older (middle and high-school) students? Given the plethora of Open Source software available in the world just waiting to be "sugarized", there is a lot of "low hanging fruit" here which would allow the OLPC project to expand its "market share" beyond what it is currently targeting. For example, an XO Learning Environment for middle and high-schoolers might include a more advanced version of the sugarized AbiWord activity. It should definitely sport a spiffy-looking music and video player -- that will surely appeal to the teen demographic. It could easily include educational tools for learning things like advanced algebra, trigonometry, and science and physics kit like Kalzium (http://edu.kde.org/kalzium/pics/screen1.png). Creation of an Enhanced XO Creative Environment for Learning ( EXCEL -- yes we too can invent catchy marketing terms in our bid to Dominate The World!!! :-) ) may go a long way toward enhancing the appeal of the XO in the eyes of Education Ministers and their colleagues around the world. -- (4) Conclusion -- The WSJ article and criticism of OLPC from such quarters as the independent OLPC News (http://www.olpcnews.com/) make a few things about the OLPC Project abundantly clear: (1) The OLPC Project is sending mixed and confusing messages about it's purpose and usefulness -- See http://www.olpcnews.com/hardware/keyboard/children_view_source.html (2) Negroponte may be his own worst enemy as a spokesperson for OLPC. -- My 2 cents -- Ed Trager -- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: GTK widgets in C# was: Re: WSJ
Im already working on this. Im working on it in a way though to run more effficiently than running as a normal JIT and instead working on a compiler of IL that can use the mono libs. We already have quite a bit working. - Original Message - From: "Scott Cytacki" <[EMAIL PROTECTED]> To: "Torello Querci" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, November 28, 2007 10:33 PM Subject: Re: GTK widgets in C# was: Re: WSJ > > Torello Querci wrote: >> If you're interested in supporting Mono on the OLPC, I can create >> a wiki where I'll put the code I've already written, because at this >> time I'm >> working alone. > I am interested in supporting Mono on the OLPC. One thing I've wanted > to try is running all of > Sugar with IronPython. This ought to give C#, Java (through IKVM), and > any other mono language: > http://www.mono-project.com/Languages > full access to the Sugar widgets and APIs. > > I don't have time to try this now, but when I or someone else does, it > would be helpful to know what is > necessary to run Mono. > > Scott > > > ___ > 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
Re: WSJ
Yoshiki Ohshima 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 >> > > 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? > It would mostly be a matter of porting the underlying software stack... which would be, from what I understand, non-trivial. We are using a large number of system services as the basis of our system, and while those system services are becoming standard on Linux, they are either not available or only minimally available on Windows systems. That is, while it might be doable, it would be far more involved than getting Sugar running on other Linux distributions. That said, activities which use the high-level components only might be able to be ported just by rewriting the Sugar APIs with a Win32 compatibility layer a port of Telepathy and a bit of bailing wire. That might let children communicate and access the materials... but that would be a fairly involved project, and I don't know if we'd find all that many Win32 developers interested in attempting it. > 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".) > Yes, we really need to get "Develop" development un-stuck. We currently have only Pippy (which doesn't do files) and the Squeak IDE available on-machine. We need that full Python IDE available for the children ASAP. After all, we've got a whole key on the keyboard devoted to it. Even if the IDE is just file-open/close/create, file-tabs and syntax highlighting it would be sufficient to start programming on-machine. Take care, 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: GTK widgets in C# was: Re: WSJ
Torello Querci wrote: > If you're interested in supporting Mono on the OLPC, I can create > a wiki where I'll put the code I've already written, because at this > time I'm > working alone. I am interested in supporting Mono on the OLPC. One thing I've wanted to try is running all of Sugar with IronPython. This ought to give C#, Java (through IKVM), and any other mono language: http://www.mono-project.com/Languages full access to the Sugar widgets and APIs. I don't have time to try this now, but when I or someone else does, it would be helpful to know what is necessary to run Mono. Scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: kids cannot participate (was Re: WSJ)
Albert Cahalan wrote: > At bare minimum, the build process should ensure that all the various > *-devel RPMs can be installed. Right now they do not all install. > I'm unable to get SDL-Pango and librsvg. Just a few days ago we were > missing libX11 and even gcc itself. These were just bugs caused by people not uploading all their RPMs to the ~/public_rpms/ directories. In some cases, source RPMs and debuginfo RPMs may be missing too. These problems will be fixed once we complete the migration of all our packages into the Fedora package repository and build them with Koji. Dennis is working on it. > Note that a **very** complete development environment is only 9 MB. > That includes the C compiler, all the standard header files, and > even the odds and ends like libSDL. I believe compiling large C programs with optimizations turned on is not even possible without adding some swap space. > It's a crying shame that the > laptop includes every impractical sandboxed toy out of academia, > but fails to include **the** systems programming language. All of > the important things are written in C, including Python! Does the laptop really have to include development tools on the precious internal flash? Only a kid in one thousand will want to become a hacker. And those who do, are better off learning how to download and install a few packages before they get into harder programming business :-) -- \___/ |___| 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
Re: kids cannot participate (was Re: WSJ)
> > 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".)
>
> The fix is simple.
Cool.
> At bare minimum, the build process should ensure that all the various
> *-devel RPMs can be installed. Right now they do not all install.
> I'm unable to get SDL-Pango and librsvg. Just a few days ago we were
> missing libX11 and even gcc itself.
> Note that a **very** complete development environment is only 9 MB.
> That includes the C compiler, all the standard header files, and
> even the odds and ends like libSDL.
Wow. That is almost too good to believe. I did install gcc while
ago (and tried it now as well) and compiled some stuff. "yum install
gcc" downloads 8.5MB of files (extracted files would be bigger on
disk), and "make" command is about 0.5MB. Other stuff such as X11
headers, etc., etc. were not included in "odds and ends"? How much
disk space do you think we need for making, for example, a .xo file
for a simple app? The svn and git clients are not a part of a
"complete development environment?
> It's a crying shame that the laptop includes every impractical
> sandboxed toy out of academia, but fails to include **the** systems
> programming language. All of the important things are written in C,
> including Python!
Even if it will be additional 50MB or such, it is just equivalent of
dozens of high-res pictures. Yes, it would be nice to have an easy
install of a "complete development environment" for XO on XO.
(Too bad the development of Develop is stalled.)
-- Yoshiki
I don't understand what you are implying in this paragraph ("every",
"impractical", "sandboxed", "toy", and "out of academica" Some
words may apply to some activities we have, but connecting them
together doesn't make a meaningful sentense), but yes, it is a shame
that most of developers even don't try to develop their software on
it.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
kids cannot participate (was Re: WSJ)
Yoshiki Ohshima writes: > 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".) The fix is simple. At bare minimum, the build process should ensure that all the various *-devel RPMs can be installed. Right now they do not all install. I'm unable to get SDL-Pango and librsvg. Just a few days ago we were missing libX11 and even gcc itself. Note that a **very** complete development environment is only 9 MB. That includes the C compiler, all the standard header files, and even the odds and ends like libSDL. It's a crying shame that the laptop includes every impractical sandboxed toy out of academia, but fails to include **the** systems programming language. All of the important things are written in C, including Python! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
C. Scott Ananian wrote: > # olpc-update debian Trying to upgrade from joyride 339, I get an error near the end, "last file /dev/kmem" or something like that. Did anyone else suceed? -- \___/ |___| 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
Re: WSJ (as pertains to AMD Geode vs Intel)
On Nov 26, 2007 1:13 PM, Brian Carnes <[EMAIL PROTECTED]> wrote: > > In the WSJ article, I read: > > "Intel and the One Laptop project, he says, have agreed to work together > to design by early January a new 'Intel-based' One Laptop device." That clearly means an early-stage prototype. Just as with the XO, it will take time to iron out the kinks in such a design. > Can someone more plugged into what's going on let me know what this means > in terms of the AMD Geode in the XO? > > I'm guessing nothing (mass production has started...). I'm guessing the same with great confidence. > What is known about a possible XO (rev 2) platform based on Intel? I would say, Nothing. Not by us, not by OLPC, not by Intel. After the first prototype, and however many other prototypes they do in 2008, the Intel and AMD devices will have to go head-to-head on cost, performance, and power drain to determine which might be the XO-2. > Should any efforts going towards Geode optimization be diverted to other > areas of development which would benefit the project more? No. The Geode optimizers should stick with it. This affects a few kernel modules and the code generators in compilers. Nobody else is involved. When Intel gets some hardware working with Rawhide and Sugar running, then those who are interested can see about tweaking it all for performance. Who says which line of development will benefit the project more? > Between this, and all the talk about getting a full Sugar environment on > the EEE and Classmate and in VMware/QEMU distributions, makes me wonder > where speedups from Geode-targeting on the XO hardware should fit into > everything. Sugar should run on everything. You can currently run the Live CD or the emulator, or compile a lot of stuff for your own system. Pretty soon everything should be in nice packages for each architecture. Somebody will no doubt test the results and publish some findings. > If the writing on the wall is to produce an image that will run in all > these environments, it needs to avoid locking itself to the Geode. What writing on what wall? Every Linux distro has versions of kernels and packages for different architectures. Why would we go monolithic? > Then again, if we tolerate the headache of maintaining a separate image > for the XO, and due to such tuning/targeting it runs *better* there than > on the other machines, at the same price point, > that breathes more life into the XO hardware... There you go. > - Brian -- 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: 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
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
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
Re: GTK widgets in C# was: Re: WSJ
Alle lunedì 26 novembre 2007, Scott Cytacki ha scritto: > Bernardo Innocenti wrote: > > My C# friend wanted to rewrite the Sugar-specific GTK widgets from > > Python to C, so they'd be available to all activities, regardless > > of the language. > > > > I think he lacks time for this project, would anyone volunteer to > > do it? > > Has any one tried using IronPython to use these widgets from within C#? > As far as I can tell, the latest versions of mono run IronPython. > > Scott Hi Scott I tried using Mono alone without IronPython. It can be used to write OLPC specific widgets (such as the menubar using Hippo canvas, for which there's no Mono binding), but not to write the application (in this case, use Python) This week, I'll experiment to see whether to spend some time rewriting this widget in C, so that both Python and C# can use it, or try the IronPython approach. At this time, I'm able to produce an activity bundle working with Sugar, but the DBus integration doesn't work yet. If you're interested in supporting Mono on the OLPC, I can create a wiki where I'll put the code I've already written, because at this time I'm working alone. Best Regards, Torello Querci ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ (as pertains to AMD Geode vs Intel)
In the WSJ article, I read: "Intel and the One Laptop project, he says, have agreed to work together to design by early January a new 'Intel-based' One Laptop device." Can someone more plugged into what's going on let me know what this means in terms of the AMD Geode in the XO? I'm guessing nothing (mass production has started...). What is known about a possible XO (rev 2) platform based on Intel? Should any efforts going towards Geode optimization be diverted to other areas of development which would benefit the project more? Between this, and all the talk about getting a full Sugar environment on the EEE and Classmate and in VMware/QEMU distributions, makes me wonder where speedups from Geode-targeting on the XO hardware should fit into everything. If the writing on the wall is to produce an image that will run in all these environments, it needs to avoid locking itself to the Geode. Then again, if we tolerate the headache of maintaining a separate image for the XO, and due to such tuning/targeting it runs *better* there than on the other machines, that breathes more life into the XO hardware... - Brian ___ 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 par
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: WSJ
Bert Freudenberg wrote: > On Nov 26, 2007, at 16:31 , Jani Monoses wrote: > >> Not all of what is on the XO is ready but it will in time (fix >> xulrunner >> pyxocom traceback, add etoys and csound, and other bits) > > > Etoys should "just work" - what's the problem? It's just that I have not packaged it. I think the Ubuntu squeak package is not the latest either, IIRC there's a separate olpc version of it which is not in a release yet? But I have no doubt it will just work once packaged. Jani ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Sugarizing non-Python apps (was Re: WSJ)
On Nov 26, 2007, at 16:39 , Mike C. Fletcher wrote: > Edward Cherlin wrote: >> We need to get that Sugarizing code for non-Python apps like Etoys >> onto a Wiki page. >> > Indeed! Actually, I spent considerable time on documenting exactly that: http://wiki.laptop.org/go/Low-level_Activity_API - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
On Nov 26, 2007, at 16:31 , Jani Monoses wrote: > Not all of what is on the XO is ready but it will in time (fix > xulrunner > pyxocom traceback, add etoys and csound, and other bits) Etoys should "just work" - what's the problem? - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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
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 subve
Re: WSJ
Albert Cahalan wrote: > Bernardo Innocenti writes: >> On 11/25/07 18:58, Mike C. Fletcher wrote: > >>> * 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) >> 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. > > I think the point is to make a "Sugar desktop" be an choice > on a normal machine. Maybe one could select it at login, or > switch to it via some control panel. It'd be like how people > choose between KDE and GNOME. Sugar would be another choice. > > That would be nice. With the current Ubuntu 7.10 packages I announced a while ago and which are kept quite up to date with git master branch that is possible now. Sugar can be selected from GDM but needs modifications to work well on all screen resolutions. Not all of what is on the XO is ready but it will in time (fix xulrunner pyxocom traceback, add etoys and csound, and other bits) Jani ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
Albert Cahalan wrote: > Bernardo Innocenti writes: > >> On 11/25/07 18:58, Mike C. Fletcher wrote: >> > > >>> * 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) >>> >> 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. >> > > I think the point is to make a "Sugar desktop" be an choice > on a normal machine. Maybe one could select it at login, or > switch to it via some control panel. It'd be like how people > choose between KDE and GNOME. Sugar would be another choice. > > That would be nice. > That was the thrust of the idea, i.e. to let existing "computer lab" environments or new alternate machines include a Sugar desktop environment that a child can log into, while still allowing the manufacturer to ship a "normal" desktop to hedge their bets. > Another thought along those lines is to simply allow Sugar > activities to run on the normal desktops. Depending on what > is best for the particular activity, it comes up fullscreen > (which may be 2560x1600) or in a 1200x900 window. > Some of the activities will already run on a normal desktop, via a bit of shim code. Most of the problems tend to be in the system-setup stuff (there's no Sugar Shell or similar services running, so if you depend on it, you'll fail), which is why I was proposing the "desktop" level accommodation to start with. Have fun, 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
GTK widgets in C# was: Re: WSJ
Bernardo Innocenti wrote: > > My C# friend wanted to rewrite the Sugar-specific GTK widgets from > Python to C, so they'd be available to all activities, regardless > of the language. > > I think he lacks time for this project, would anyone volunteer to > do it? Has any one tried using IronPython to use these widgets from within C#? As far as I can tell, the latest versions of mono run IronPython. Scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
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". ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
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. > 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. > > > 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. > > 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? > 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. > > > 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 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. > 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. > 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. > > > * 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
Re: WSJ
Bernardo Innocenti writes: > On 11/25/07 18:58, Mike C. Fletcher wrote: >> * 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) > > 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. I think the point is to make a "Sugar desktop" be an choice on a normal machine. Maybe one could select it at login, or switch to it via some control panel. It'd be like how people choose between KDE and GNOME. Sugar would be another choice. That would be nice. Another thought along those lines is to simply allow Sugar activities to run on the normal desktops. Depending on what is best for the particular activity, it comes up fullscreen (which may be 2560x1600) or in a 1200x900 window. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
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. 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. > 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. > 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. 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. > 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. 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. 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. 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. > * 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. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
On Nov 26, 2007 1:07 AM, Bernardo Innocenti <[EMAIL PROTECTED]> wrote: > 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. # olpc-update debian > 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. # olpc-update debian-big Enjoy! --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
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. 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. For me, every Sugar installation helps spreading the constructionist educational model of OLPC. As Negroponte says, our goal is not selling laptops. > * 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) 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. > * 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. 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. > 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. The same goes with programming languages: we concentrated on shipping a good Python environment because it's good enough for our educational purpose, but we're of course not opposed if people want to make any other language available for the laptop and use it to write new activities. In fact, we help where we can. I have a friend who is porting a game written in C# to the XO, and the Sugar developers have been very helpful. > We need to see ourselves, and communicate our vision of, being an > educational project which is trying to grant access to children. > Selling our particular hardware is useful because it has a few > features that make it uniquely suited to many areas, but we need to > expand our vision to achieve the goal IMO. Again, I totally agree. > 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 command line tools. I'm not saying we should be actively prevent them from installing TeX if they want to. In fact, I believe you can just type "yum install tetex", wait a few hours, and... presto! yum crashes :-) Seriously, my point is that we shouldn't push too much in this direction because we run the risk of loosing focus on the real educational software we need. > * 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 dialog
Re: WSJ
Hi Michael and all,
i agree with your thoughts about MikMik, it would be a nice tool to do
feedback , although yet its not entirely sugarized. i did an early work
that's on
http://dev.laptop.org/~rafael/MikMik-8.xo
but is not yet finished. so would be nice if somebody could help out with
this porting.
Cheers!
On Nov 25, 2007 8:32 PM, Michael Burns < [EMAIL PROTECTED]> wrote:
> James, you might have heard of this software, but I'll share for the rest
> of the list that might not have seen in in the pipeline...
>
> On Nov 25, 2007 4:33 PM, James Cameron < [EMAIL PROTECTED]> wrote:
>
> > +1, insightful, useful. Some of the feedback mirrors what some of the
> > recent Wiki questions have covered, and I agree, we seem to lack
> > involvement in the Wiki from the trial deployments, the teacher
> > training, and the software re-use groups.
>
>
> It might not be the proper fit, but Mako's MikMik [0] wiki software should
> go a long way to solving this problem. Essentially, it is using distributed
> version control (via BZR. Similar to the linux kernel development process
> with Git) and merging it with wiki software. With it, when teachers (or
> Peruvian high school students) start to documenting their work (either for
> lectures, coarse outlines or general tips on XO support, etc), those commits
> to the school server's wiki software can trickle 'upstream' to regional,
> country or global OLPC wikis for others to use and further edit. Even
> Wikipedia article edits (a portion of which we include on the school
> server's content library) could be filtered and vetted (or fast-tracked,
> depending on user experience) from a grammar school in Peru all the way over
> to the florida colo servers of the Wiki media foundation. But it is a
> longer-term project to make a process like that streamlined.
>
> With that software (or the future iterations a work flow that MikMik
> allows), getting feedback from the deployments will be a natural part of the
> process.
>
> [0] http://wiki.laptop.org/go/MikMik
>
> --
> Michael Burns * Student
> Open Source {Education} Lab
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>
--
Rafael Enrique Ortiz Guerrero
One Laptop Per Child
[EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: WSJ
James, you might have heard of this software, but I'll share for the rest of
the list that might not have seen in in the pipeline...
On Nov 25, 2007 4:33 PM, James Cameron <[EMAIL PROTECTED]> wrote:
> +1, insightful, useful. Some of the feedback mirrors what some of the
> recent Wiki questions have covered, and I agree, we seem to lack
> involvement in the Wiki from the trial deployments, the teacher
> training, and the software re-use groups.
It might not be the proper fit, but Mako's MikMik [0] wiki software should
go a long way to solving this problem. Essentially, it is using distributed
version control (via BZR. Similar to the linux kernel development process
with Git) and merging it with wiki software. With it, when teachers (or
Peruvian high school students) start to documenting their work (either for
lectures, coarse outlines or general tips on XO support, etc), those commits
to the school server's wiki software can trickle 'upstream' to regional,
country or global OLPC wikis for others to use and further edit. Even
Wikipedia article edits (a portion of which we include on the school
server's content library) could be filtered and vetted (or fast-tracked,
depending on user experience) from a grammar school in Peru all the way over
to the florida colo servers of the Wiki media foundation. But it is a
longer-term project to make a process like that streamlined.
With that software (or the future iterations a work flow that MikMik
allows), getting feedback from the deployments will be a natural part of the
process.
[0] http://wiki.laptop.org/go/MikMik
--
Michael Burns * Student
Open Source {Education} Lab
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: WSJ
On Sun, Nov 25, 2007 at 06:58:29PM -0500, Mike C. Fletcher wrote: > [...] +1, insightful, useful. Some of the feedback mirrors what some of the recent Wiki questions have covered, and I agree, we seem to lack involvement in the Wiki from the trial deployments, the teacher training, and the software re-use groups. I suspect this is mainly due to the enthusiasm of the open source community pushing out unpopular ideas. I think people like me (FOSS enthusiasts) might need to be kept clear of those other development threads. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
Eric wrote: > The WSJ article and video post were what one would expect from them: > focused on the financial, and not cultural or societal, aspects of the > project. The thrust seemed to be how it would affect the Intel and/or > AMD stock price, and the implication was that since the XO price is > NOW not "$100" the project has somehow failed. Pure bullsh*t from a > reporter that clearly doesnt get the larger context. Obviously conflict sells stories best[1], so I won't attack the author for playing it up. That said, there were issues brought up that we should discuss rather than simply dismissing because the person bringing it up (in this case) had to sell a few papers. The best friend you have in a design project is the harshest critic available. As long as their critique is fair, we should listen carefully to it. Much of the stuff I'm discussing below has already been started, or is under-way. I'm just suggesting that we keep it in mind a few things that the article points out... It's not About the Hardware: The XO hardware is wonderful, but in the end, it's not the key thing. While it may be able to go into areas that another machine can't go, there are lots of areas that any machine can go into. We are an educational project, and while the screen makes a superlatively good textbook reader, the case is reasonably weather-resistant, and the battery life is good (but not yet so good that it's a killer feature), it is not true that every ministry of education will choose to go with "our" hardware. Our hardware may have advantages, but it is just a (fairly generic) vehicle for accessing software, content and people, and if countries want to choose another project's hardware, more power to them.[2] 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? Sure, there are areas where the XO is a better choice because of some metric, but if a country wants to choose Classmates or EEEs, that's fine, we *still* want to help educate those children. Sure the segmentation of the market means that we can't hit the economies of scale we want, that sucks for us and means that our children will be getting less for their money. That sucks, and we'd like to get to the point of selling lots and lots of the XOs to make it as cheap and useful as possible, so we're going to continue to try to get more "sales". By the time we're looking at a 'generation two' of the XO we would like to be able to order the hardware off-the-shelf to our spec and have companies produce dozens of different models. To make that happen we need to reach out to the hardware developers already working in this space and make shipping our software and content a no-brainer decision when they are selling into the educational market. Addressing the Issue: * 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 * 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) * 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) 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. We need to see ourselves, and communicate our vision of, being an educational project which is trying to grant access to children. Selling our particular hardware is useful because it has a few features that make it uniquely suited to many areas, but we need to expand our vision to achieve the goal IMO. Standardisation and Application Availability: We aren't shipping Windows. If countries want to use &
WSJ
The WSJ article and video post were what one would expect from them: focused on the financial, and not cultural or societal, aspects of the project. The thrust seemed to be how it would affect the Intel and/or AMD stock price, and the implication was that since the XO price is NOW not "$100" the project has somehow failed. Pure bullsh*t from a reporter that clearly doesnt get the larger context. -- eric "You're either serious about what you're doing, or you're not serious about what you're doing, and you can't mix the two, and life is short" - Bob Dylan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
