OLPC News has just learned that all variants of the XO-3 Moby tablet from Marvell will run the Sugar Learning Platform by default. GNOME will also be an option via a dual desktop - the same setup as the XO-1.5.
Add a little Sugar on it
This is great news for Sugar Labs as this will continue demand for new Sugar development and updates. No word yet on if Sugar for Moby will be different than Sugar for XO-1.5.
Yet, not all XO-3 Moby tablets will run Sugar - other manufacturers using the Marvell reference design may use Android for different verticals.
The trickier question is, will Sugar or Gnome be optimized for touch? Or, for that matter, will Android handle different sized devices well?
"The trickier question is, will Sugar or Gnome be optimized for touch? [...]"
Yes, they will. I am actually useing both on my Tablet. XInput2 is already implemented for Gnome 3 (Gnome 2.31 development) for multi-touch purpose and Sugar will not be that different
Well... I'm sure you can use Gnome with a touchscreen, but the iPad has demonstrated that you really want an entirely different style of user interaction... is Gnome going to do that?
"Well... I'm sure you can use Gnome with a touchscreen, but the iPad has demonstrated that you really want an entirely different style of user interaction... is Gnome going to do that?"
Gnome-shell is an indication about Gnome future which i am daily use. All component necessary for user interactions for either stylus and touchscreen are in place. Hardware 3D might an issue but it should be fine for future XO-3 assuming it can, otherwise the traditional Gnome 2 interface will be displayed as fall back.
I think Nicholas Negroponte talks about Android in the PC World interview.
Sugar learning features could be apps on top of Android.
That kind of makes sense but... no more Python?
Sugar and GNOME will indeed need to be optimized for touch.
Sugar Activities in Python will remain so. Allowing for tinkering, to study and improve the code, is central to Sugar's education mission.
Sean.
Oh come ooon!
A K-6 OS/UI/Platform has "code modification" central to its educational mission???...
Who thought of it? Seriously!
And more specifically do YOU believe that this is Sugar's central educational issue/contribution???
I'm sorry if I wasn't clear. Yes, tinkering - clicking on stuff, making things happen, completing a task... working out a puzzle; looking at code. Fundamentally, a computer is about a person getting the machine to do what she wants. Discovering how it works is part of that. The XO-1 and Sugar were designed to be as open as possible.
So will every child using Sugar become a Linus Torvalds? Of course not. But... some of them will. We'll know in a few short years. If only 1 percent of XO-1 learners become engineers, that means there will be many thousands of them.
Back in the day, I learned BASIC on my first computer easily since it was interpreted and easy to see the code, edit it, and run it. System calls were vectored through RAM, allowing me to insert wedges, for example to trap the keyboard queue. Later, I learned HTML the same way. I still like the view source in Firefox. And... I miss it on my iPhone. That's why we added a View Source button to Sugar. Sure, few will use it. But it's there.
Sean.
Let's do the numbers. shall we?
1,500,000 Sugar usres X 0.01 = 15,000 kids potentially benefiting.
Would you care to point to _1_ kid-tinkering-"product", so far?...
And the story about "when I was kid", is clearly BS. When you where kid, only _certain_ kids in a _certain_ environment got a computer to play with BASIC, and from these a minute fraction was K-6. So let's not extrapolate our personal story to universal truth, because is _totally_ unrelated (not to mention other ways to achieve the same thing).
Here we are talking massive deployment. Like playing soccer or baseball. What is the percentage that actually makes it? 0.001% ? That's your "benefited" target! Future statements, calculations and strategic decisions better consider that number.
The fact is that a) Python is still a developing (see immature) language, b) is a 10-100 fold less efficient environment compared to other compiled and interpreted languages ( http://shootout.alioth.debian.org/u32q/performance.php?test=spectralnorm ), c) has 10-100 fold less developers (sorry no ref, but I could if you care :-), and d) the only serious reason picked over say, java, was the Licensing issue (java is not free-enough even though GPL was not existing when java was released), e?) was the new cutting-edge "thing" to match the hardware innovation (hope not)
AFAICT nothing in Sugar _requires_ python in principle.
I can appreciate there is a huge investment in Python, but SL better realize that their target hardware will becoming more energy efficient rather than more powerful (which makes absolute sense when the target is every kid in the world) and python is not the appropriate development tool. Will always bulge the target hardware. So moving to more efficient language/code should be seriously considered.
Regarding your iPhone :-) I'm sure that you miss immediate code reviewing but a) you can still do it and _most important_ b) if was running on Python would be in the garbage and not in your pocket. Evidence: although Python is free, "super-duper" and available for ARM, no phone OS is using it!
Smart phone-class hardware is really the Sugar target. Not your desktop. To get a better idea what I'm talking about, try to use an XO-1 *exclusively* for a month (as I did it), and then tell me what you think about python, gnome and the rest of the desktop-class infrastructure Sugar is currently using. I would doubt you would even start X... ;-D
So if the Sugar UI can be refactored on Android, C/C++, Java, Javascript or something similar, could only be beneficial for the Project as a whole. The sooner we/you realize it the better. A good start is to stop waving the "educational" aspect because simple does not make sense.
Please do not take the above as polemics or something (is just my style :-). I know from experience that some time we make a certain choice and the more we invest on it the harder is to abandon it. Even if we realize down the road that maybe is not the best way to get where we want to be.
What I'm suggesting is that if moving to ARM as a prime hardware platform requires a considerable refactoring, maybe it should go deeper... We can always hope that Sugar will be used on a lot of different hardware but the fact is the XOs are the exclusive Sugar hardware.
Let's think about it, shall we?!?
When I was a kid, there weren't even pocket calculators, let alone personal computers. I bought my first computer with savings from working in a kitchen when I was 20 ;-)
There are several Sugar Activities, such as Etoys, which are not written in Python. This requires extra work for Journal integration, but yes it is quite possible. Etoys, Scratch, Gcompris are projects which began outside of Sugar and were ported.
Today's thread on the OLPC devel list about porting to QT and Android may interest you. Commenting there will likely have more impact than here.
Sean.
Developers are getting pretty annoyed with "list pollution" when there is not any code included or explicit reference to one. Even more so when this is not Python or Fedora. And if you insist, they come back with: "you do it and tell us about it when you are done".
I'm sure that if they are wondering, they know everything that I said and/or where to find it.
Besides I like cats :-)
It's not an XO-3. Olpc doesn't call it an XO-3, Marvell doesn't call it an XO-3. Just because Wayan calls it an XO-3 doesn't make it an XO-3.
NN does call it an XO-3 prototype. But it isn't the XO-3 itself.