One Laptop Per Child is planning to end the production of its XO-1 laptop as well as drop AMD’s x86 Geode processor. OLPC intends to replace these with a low-powered ARM alternative in the XO-2 laptop, which is slated for release in about 18 months. Even though the current XO-1 model consumes a mere five watts, OLPC feels thats the biggest problem. “We’re seeing some very impressive system-on-chip designs that provide both fundamentally low-power demands and the kind of fine-grained power management … in the XO-1,” said Ed McNierney, chief technology officer at OLPC. Though using ARM architecture will reduce power consumption, it puts using the full-fledged Windows OS on their laptops in jeopardy. The company is currently wrestling Microsoft in order to try to get them to develop a full version of Windows to be able to run on ARM processors. It’s not likely Microsoft will budge on the subject as ingrained as x86 is and how seemingly little there is in it for them, but we’ve been surprised before.
I am all for ARM chips in netbooks and laptops. They consume way more power than CISC processors, the most annoying feature of any laptop/netbook is the fact that the batteries die too fast. I work 8 hours a day not 2.
Edited 2009-03-12 06:11 UTC
Me too.
Actually, why only “in netbooks and laptops”?
Urh, I think you mean less power?
Yep you’re right! My bad…
I agree with your sentiment completely. We need portable computers that last more than 2 – 3 hours.
As far as OLPC goes, I think the organization is a joke. The whole idea behind it was originally supposed to be to provide impoverished kids with a computer; whereas they would otherwise never have the opportunity.
These children aren’t saying to themselves, “gee, I’d really like a computer, but I don’t want a crappy OLPC because it won’t run all the Windows software I have.” That seems to be the focus of the OLPC organization though.
Considering the intended audience, who cares what Microsoft does, since Windows would actually be a hindrance to these children obtaining software and learning how to use a computer?
Edited 2009-03-15 19:24 UTC
What would be the point of porting windows across?
None of the software by third party vendors would run on it anyway.
Perfect time to take advantage of Free Software’s general support of a wider variety of hardware platforms.
True!
If they ported the .net vm a great deal of software would run. Programs (no matter what language as long it has an .NET compiler) are compiled to CLI-code. That CLI-code is interpreted by the CLR (Common Language Runtime) to machine readable code.
If they port the CLR all programs written for .NET automatically (without recompilation) become ARM compatible.
A lot of .NET has already been ported to Linux.: look for Mono. Most of Windows Forms has been ported, but unfortunately .NET programs seem to either use the part that is missing, or do direct calls to the Windows OS, which means that hardly any Windows .NET code runs on Linux. At the same time, Linux .NET code is written for GTK#, not Windows Forms, so running it in Windows, while theoretically possible, is far from immediate.
With the latest patent salvos coming from MS against Linux, goodwill and interoperability look ever less likely to improve.
There is Windows CE and the compact .NET framework, but I don’t think WCE is really a good choice for a personal computer, and again, there’s not that much software written for it.
It seems that OPC2 will be Linux only, if it ever comes to happen, which won’t be a bad thing anyway.
As yes thats lovely in theory but isn’t really true for one major reason: the windows.forms library (and probably others), which nearly every Windows based .NET app uses, has dependencies to native Windows compiled dlls.
The upshot: you can’t just port the vm and forget about it because those dependant libraries also need to be ported. This is the major difficulty with non-Microsoft implementations of .NET such as Mono and why they were even investigating using Wine to execute these native libraries!!
Edited 2009-03-12 12:29 UTC
If they ported the .net vm a great deal of software would run.
Out of all the programs I run on windows, I can think of exactly one that uses .NET (Paint.NET). There aren’t that many popular programs written _completely_ in .NET.
And ceven if there were lots, _completely_ is the key term here, because most .NET projects use some existing native libraries to get a feature not in the .NET class library. All those programs would need porting effort to make run on ARM, even if the CLI and basic class library was done (not a trivial task).
Porting just the CLI and .NET class library would not give us any significant app for free. Similar to how we have Mono, but still can’t run most windows .NET apps on linux.
The problem with having Windows software running on a non-x86 system can’t just be solved by .NET or by recompiling software. No way.
.NET applications frequently use native code. P/Invoke calls to DLLs provided by the OS should be fine, but anything else could be a problem, and would require the native DLL be ported.
What about older versions of MSVC? Or Visual Basic? Or any of Borland’s stuff like Delphi? How about GCC – most OSS Windows applications either use GCC directly, or rely on Cygwin (which is built with GCC) for some part of their build system. Or any one of the dozens of other tools Microsoft and others have put out over the years. What’s the chances of them being supported on an ARM version of Windows? Or how about software that relies on third-party components?
Basically, you’d end up being limited to pure .NET applications (which essentially don’t exist), and the small number of applications which are written using Microsoft’s latest C / C++ compiler, don’t have any assembly code, don’t use third-party components, don’t have any legacy baggage to cart around, and are developed by a company with enough money to justify development and testing on an ARM version of their software.
That basically leaves you with some of Microsoft’s software (but not Office), whatever comes with the OS, and pretty much nothing else.
Emulators are out of the question – even running native code, the fastest ARM CPUs you can get are many times slower than low-end x86 chips. Unless the software you want to run could run comfortably on a 386, there’s just no way.
Edited 2009-03-13 14:56 UTC
Funny, I’ve been writing them for the last three years now… check out http://www.codeplex.com, it is the sourceforge of the .net world
Caveat lector: I’m not a .NET expert.
As far as I can tell, the P/Invoke layer can be made to work cross-ISA. As long as you have the libraries in place compiled for the actual native architecture of the machine (or for the WOW64 cpu compatibility layer) the .NET JIT should be able to hook up your P/Invoke calls with the correct DLL.
But pure .NET is definitely likely to be a lot easier to get running faster.
why not dumping windows, too — who needs windows anyway?
Microsoft isn’t going to port windows to anything bug x86 for a while.
Maybe, if they are bored, the adapt Windows Mobile (Windows CE). But there is no way they are going to adapt Windows XP or 7.
The OLPC people seem to be missing the point that the main and possibly only reason to use Windows on netbooks is to be able to use all the apps that people are accustomed to. Simply porting the OS to ARM will bring next to nothing, as there won’t be any apps.
And that won’t change, at least for closed-source software. Open-source software might get away with a recompile, a lot of projects will probably be depending on MS to deliver an ARM compiler and toolset…. All of which would take time and money while not being especially rewarding for Microsoft.
Sure, Microsoft is capable of and has plenty of experience in porting Windows. They ported Windows to the DEC Alpha back in the day, it was hailed for all of two seconds and then proceeded to be a complete flop. They ported Windows to Itanium, but the only reason that’s halfway workable is that Itanium supports x86 apps. And they ported Windows to PowerPC for the XBox 360, but we’ve never seen a desktop/server OS version of that, persumably because they realize that it’s unmarketable without legacy x86 support.
So basically this proposal is incredibly unrealistic. My guess is that this is the OLPC guys’ way of pretending to play nice while actually shoving it in MS’s face. Either that or they actually believe MS will bring Windows to the ARM platform… in which case they’re hopelessly naive.
Windows NT ran on MIPS, PowerPC, Alpha and x86. The NT codebase is made to be portable. They didn’t have to port it to run on the xbox 360, as NT already ran on PPC.
Again, who cares if W7 could run on ARM, when no Windows applications would? If it has to be ARM, then it it has to be Linux or BSD, for which there’s loads of software that is in general free as in freedom.
There was a compatibility layer for x86 apps on PPC and Alpha, as well as the one on Itanium. MS has plenty of practice doing this, there is no good reason that they couldn’t do a similar compatibility layer for ARM.
That was a long time ago – I’m betting that the Windows codebase isn’t as portable as it once was. But, even if it was, Microsoft tends to be somewhat reactionary outside of the standard desktop/laptop/server market.
If someone comes up with a cool device that doesn’t run Windows or Win Mobile, then they’ll take a serious look.
The best thing I can see coming out of the rise of the Netbook market in the short term is that Microsoft might keep enhancing XP.
Not really, they use a similar (but i would assume simplier) compatibility layer right now for running 32 bit apps on win64 (wow64).
Not to mention that with pockets as deep as MS’s, they can easily hire the necessary developers to help them get back up to speed.
true but running it on other architecture would most of the time require an x86 emulator due to the fact that most windows applications were and still are targeted at x86 ( I really wanted one of those alpha workstation at that time) .
though I think that .net could solve that problem, but what makes windows popular is its ability to run legacy apps (would be difficult on such platform).
A large portion of .NET applications use P/Invokes to access processor-specific native Windows DLLs. This pretty much kills the prospect of cross-CPU compatibility.
It might be possible to develop managed applications with Mono, since the runtime exists for other CPU architectures–including ARM?
But how many popular commercial .NET applications are 100% managed (no access to unmanaged libraries) and target or even support the Mono runtime?
Edited 2009-03-12 15:40 UTC
yes that’s why it’s a hell to try to install .net v1 on nt4 and, difficult to install .net v3.5 on windows 2000(sic).
I also think that people need to target alternate runtime ( Mono or even dotGNU ). But lastest feature always look nice in the eyes of a developper.
Maybe we should stick to java
.
Kudos for making that clear. So many anti-Win folks forget or never knew that Windows NT was designed to be architecture-independent (that’s what the HAL is for). Windows only supports x86/64 now because MIPS, DEC Alpha and (non-X-Box) PPC died off.
The HAL is not really for the purpose you think it is.
Basically just think of the HAL as the motherboard driver. And not even the whole motherboard (there are separate drivers for the individual buses, like PCI, USB, 1394, and others).
Haven’t I read that NT is called NT because it was originally developed on/for the Intel N10 processor? When it became clear that N10 was going nowhere, it was ported to x86 and others. Yes, as has been pointed out many times, NT is “portable”, actually getting your apps to run is a whole other thing though.
Which is why we are talking about software compatibility layers. MS has quite a bit of experience with such technology, and could do such a thing, whether they would is another story.
MS most certainly did not port Windows to the PPC platform for the X-Box; it’s run on PPC since the mid-’90s. It wasn’t ported to DEC Alpha, either; it was simply recompiled for it – and what a hell of a server platform that was!
Please read up on the Windows HAL. All the RISC/CISC / endian stuff is encapsulated there. Windows was originally developed on MIPS, so as to not be tied to Intel. That’s why we had boot.ini & NTLDR (etc.) for all those years. It’s not MS’s fault that all the other architectures failed as products. I’ll betcha that MS already has Win running on ARM.
Correction: Itanium does not support x86 applications, unless Windows has an emulator?
Also, Windows NT was ported to PowerPC for servers, but I don’t think anyone used it.
Please sir, can we have a real link?
Hmm not sure what happened when I submitted the story. Anyway, http://www.goodgearguide.com.au/article/279958/olpc_set_dump_x86_ar… .
Here it is: http://www.goodgearguide.com.au/article/279958/olpc_set_dump_x86_ar…
And apparently I’m incapable of even posting comments properly
It was getting a good deal of support and momentum, but they went to bed with Windows before and it all but killed the project. Microsoft and Intel both working against them, in order to promote the Classmate. Developers left OLPC in droves. They totally lost Sugar.
Now they still want to pal up with Microsoft. I just don’t get it.
I thought that they irreparably damaged the project when they made the decision to stop consumers from buying it on whatever terms they liked. If OLPC had listened to a bit of advice, they could have had one hell of a project on their hands.
It’s not just a windows lock-in, but an architecture lock in as well. Linux running arm and using WINE will not even be able to use a lot of the applications that a lot of people rely on because of the different architecture.
Sure, Linux has a lot of compatible basic software (office, audio, internet, etc), but there’s still a lot of custom software out there that people use often that simply isn’t available for Linux – and until there are compatible replacements linux will not take off at all.
To be fair, even mac users have these issues.
Well, I doubt that the objective market for the OPC2 relay on any Windows apps at all, or on computers in general, for that matter.
Little poverty-stricken children don’t often use a lot of custom Windows software, but they would surely appreciate not having to pay for their basic software far more than their house is worth.
ARM and Wine? Wine doesn’t do any kind of hardware emulation, that would be as silly as using Windows itself.
Wine + qemu-user, perhaps? Sounds like a painful performance hit, mind… Still, the Darwine project was looking at doing something like this to get Windows apps running on PPC Macs, so it’s not like it’d be the first time someone tried it.
I can’t think if any custom software missing on Linux that the OLPC target audience would depend on.
Millions of users worldwide would beg to differ there.
In fact, I’m constantly suprised with just how many non-geeks I know that run Linux these days.
In what specific industries?
Macs are the industry standard in DTP / photographic work
Macs are the industry standard in video editing
Macs are increasingly the industry standard in music production.
Granted Mac’s aren’t on most office desktops, but they run MSOffice so they’re not even lacking in software for general office work.
Are you sure?
MS would no doubt port MS Office & IE & probably other stuff of theirs too, which wouldn’t be hard for them. Then there’s open source windows software, like:
Open Office
Firefox
Thunderbird
Gimp
Inkscape
Pigin
Cygwin and all the tools that brings.
Apache
PHP
MySql
Not to mention other open source applications for which windows versions exist, that would probably be easy to port. With that lot, and a little more, that’s a decent starting point from which to build upon.
Microsoft has been working on a new compiler backend for years, called Phoenix:
http://www.infoq.com/news/2007/08/phoenix-dotnet
It will support x86, x64, CIL for .NET and also ARM. It’s mentioned here as a research project but in reality it’s already been taken over by dev div (who will almost certainly integrate it into VS at some yet unknown point in time).
The x86/x64 backends are _very_ mature by now, and they will be used to compile the final version of Windows 7. That doesn’t tell you anything about the state of the ARM backend bits of course but given the business pressure I can imagine that Microsoft is definitely considering throwing some money at this.
So basically the “ARM triumph card” that OSS currently holds must be played NOW; do not count on Microsoft sitting idle on this one.
The best thing would be if OSS did an agressive land grab in the ARM netbook area, proving that it can deliver a nice desktop experience (with Flash, Firefox, Skype and decent video playback perf etc). Once the netbook vendors have experienced the power and freedom of the OSS toolchain they won’t let it go.
this is beinfor WinCE mostly for WinCE 7. No version of the desktop version of windows will go to arm. In version 6 and 6.1 (vista and 7, but mostly 7) stipped out the old Alpha/MIPS/PPC/ and a few other suported code bases from the old NT4 days (they started that process in win 2000 there was still some legacy stuff if you dig deep enough). Win 2000’s NT core ran the xbox 360 (if i recall correctly).
the windows kernel is rather portable, but we won’t see it on arm unles x86-64 magicly dies out, or we wind up in a parallel univers. “like that drop trip i saw while I was on that drug trip” (close enough, Futurama)
Wine and Crossover wont help ARM-powered netbook users access Windows applications because they are essentially Win32/DX API re-implementations with a WinPE binary executer not emulators.
Running Windows on a processor emulator (QEMU) would be feasible but the performance will be pretty bad; plus it appears ARM host CPU support is still in the testing stage.
http://www.nongnu.org/qemu/status.html
I don’t think Microsoft really cares because they have upto 90% marketshare on x86 netbooks now. It was bound to happen when OEMs chose crappy distributions like Linpus or Xandros with highly unusual desktop environments. IIRC, these distributions repositories are limited and contain outdated packages. In addition, little awareness of software like WINE, Crossover, or Cedega was present among new netbook purchasers.
http://www.netbookdigest.com/2009/03/03/sad-day-for-linux-windows-n…
Edited 2009-03-12 15:18 UTC
The whole thing is frankly bizarre.
* How come nobody else is putting large dual touch-screens in their low-cost netbooks? The clue is in the question, surely.
* Why are they worrying about CPU power consumption, then putting two large full-colour screens in the thing?
* Forgive me, but it doesn’t look very rugged. Is that still a core design goal?
* Did they only just decide on a CPU? Have the people doing the hardware never met the people who do the software?
* Does this project really need to concern itself with revolutionary user-interface design, particularly given that the last time they tried it, they crippled the machine in the process?
* Is this user-interface (and everything else) going to be ready in 18 months when they can’t even decide what OS it’s going to run on?
* What’s Microsoft’s deadline for getting Windows + apps + software update and other mechanisms running and tested on this ARM machine that doesn’t exist?
* What apps would run on Windows for ARM? Are they expecting an Office port too, or will it run a bunch of apps like OpenOffice, which run fine on Linux?
* Isn’t there just a little bit of vanity and ego behind these strange decisions? Speaking of which, why not ask Bono if you can use Palm’s WebOS? That runs on ARM.
Edited 2009-03-12 17:01 UTC
For a XO: 5 Watts, are 5 Watts too much.
OLPC management has good reasons for believing that ARM is a better solution.
But, technically speaking, the architecture is much near a mobile than a desktop.
So, forget about huge Framework or Emulator, hungry for RAM and CPU.
Forget about tons of applications, gadgets and enormous APIs.
To choose a reduced footprint OS is just patently obvious.
… And if the child has not to pay for it…
As I asked above, why then, the two screens?
I agree with you on the OS – it meshes perfectly with Google’s plans for Android.
Isn’t the iPhone OS ARM based. And isn’t LLVM able to produce ARM code?