Intel Confirms That Android 3.0 Is Coming To x86 Tablets

timothy writes "Considering that x86 and ARM have been playing leapfrog in at least their future *promised* efficiencies, and that there are a ton of x86 tablets in the works, it's good to see cross-platform OS choices. The most popular Linux distro (Ubuntu) as well as several other conventional Linux options, Windows (even if so far confined to tech demos), and Android — interesting mix."

Comments

What about Meego?

[Anonymous Coward]

Meego is really dead, then.

Re:What about Meego?

[Microlith]

To head off the stupidity before it infects Slashdot, no.

Intel sells processors. Any OS that will run on their processors is OK by their standards.

Of course, contributing to Android is to undermine open source as a whole, seeing as how they continue to hide the Honeycomb source but deliver it to Intel. If you truly appreciate open source and want it to succeed in the mobile space, you should support and push for MeeGo (and stop buying shit from companies like Motorola.)

Re:What about Meego?

[hedwards]

Intel doesn't manufactures any ARM processors, do they? Which is probably what's going on there. An attempt to derail the OS by adding in support for their own processors. Given how they've been behaving, I wouldn't be surprised if they started leaning really hard on anybody using ARM chips with Android.

Re:What about Meego?

[Microlith]

Intel can't do that though, they don't control the OS. And they have no real foothold in the mobile space to do that with just yet.

Re:What about Meego?

[DrgnDancer]

You mean like every single phone manufacturer in the world? Intel doesn't even have horse in the race below the tablet level, ARM is pretty much the only game in town for ultra mobile deceives like phones and PDAs.

Re:What about Meego?

[Anonymous Coward]

Intel still holds a full ARM license. They sold the XScale to Marvell, but retained a license. Why couldn't they build ARM again?

Re:What about Meego?

[Microlith]

I think you mean, an OS developed under the banner of the Linux Foundation with support from SuSE and Intel that can't be arbitrarily taken and held closed on a whim. Nokia is mostly peripheral, though they were decent up until the point that MS "bought" them.

Please, make stupid statements elsewhere.

Re:What about Meego?

[Kjella]

You mean like every single phone manufacturer in the world? Intel doesn't even have horse in the race below the tablet level, ARM is pretty much the only game in town for ultra mobile deceives like phones and PDAs.

Yes, pretty much. It's no secret that Intel wants to get into ARMs market, having Android run on x86 is a start. Or at least make sure the battle lines are as far towards ultra mobile as they can. I imagine they're looking at a reverse iPhone -> iPad, first get their CPU in tablets then bring out a smartphone version.

I know ARM has and probably ever will have an advantage in the ultra-low power dumb phone game. But "entertainment" phones have a much higher power budget when playing, it's not certain ARM will be equally superior there. Or if they are, it won't be for Intel's lack of trying...

Re:What about Meego?

[Microlith]

Intel still builds ARM processors. Their entire line of "IO Processors" are basically dual-core ARM chips used for RAID cards. Adaptec and Highpoint both use these chips, for example.

Re:What about Meego?

[icebike]

Of course, contributing to Android is to undermine open source as a whole, seeing as how they continue to hide the Honeycomb source but deliver it to Intel. If you truly appreciate open source and want it to succeed in the mobile space, you should support and push for MeeGo (and stop buying shit from companies like Motorola.)

Really? http://www.androidcentral.com/gpl-portions-honeycomb-entered-aosp

Re:What about Meego?

[Microlith]

Yeah, probably only related to changes made to the kernel as everything else is Apache licensed. Nothing of use or real value, seeing as how little of it ever gets into the mainline, and nothing contributed to any other parts of Android help any other open source software.

Re:What about Meego?

[symbolset]

The thousands of engineers who worked on in to care.

Re:What about Meego?

[Anonymous Coward]

I guess it comes down to can intel beat a dual core 2 Ghz ARM?

Intel just wants to take away a piece of the market from ARM processors. Once the netbooks went down the hill intel was fucked and a lot of their roadmap was relying on the netbook market, which is now dead. The new tablet and high-end smartphones market doesn't even remember who intel is.

Re:What about Meego?

[erroneus]

That is a short-sighted perspective. There are some "real world" considerations to be think through.

Open Source, the way we know and love it today, is filled with projects that struggle with direction. GNOME, KDE and other extremely well known projects suffer from having too many people in charge. Meanwhile, commercial projects have the advantage of having stronger direction which is great from a perspective of getting a project planned, built and "completed."

(I know, I will catch hell even for talking about this but go ahead... say what you're gonna say.)

Google is attempting to keep the project as open as it can while still maintaining its direction. As has been said, Honeycomb was designed for a higher resolution display and offers functionality intended for a specific set of capabilities. So in addition to being an OS, it is also an "experience" that needs to be consistent and reliable. It WILL be released. Of that I am certain, but I believe Google is trying to maintain a strong direction element in the project so that this open source project will have the same advantages as Windows and Mac OS X.

And keep in mind that this tablet computing is a new format of computing. It is one in which Microsoft cannot successfully participate at this time. Therefore, this time is crucial for the development of this OS platform and for the tablet market in general. If ever there was a way to take Microsoft down, it is through a market in which they cannot compete and interfere. They can't do tablets and they can't do phones (tiny tablets).

I think Google is doing the right thing at the moment. But I guess time will tell.

Re:What about Meego?

[0123456]

In fact it wouldn't be a stretch to say that Linux/BSD/et al just isn't suitable for phones.

Doesn't the iPhone run on a modified BSD kernel? If so, it would seem odd that pretty much every smart phone runs on an operating system that isn't suitable for phones.

Re:What about Meego?

[hairyfeet]

The bigger question would be "why would they need to?" as people are expecting their phones to do more and more AND MORE which means that whole "ultra low power' thing is quickly becoming passe'.

Apple with the iSliver batteries that everybody and their dog are ripping off are training people as we speak to carry a charger with them everywhere, the EU getting the OEMs to agree to standards (mini USB I believe was the final verdict) means that if you forget your charger somebody else will have one, phones are quickly becoming full on gaming rigs in your pocket. HDMI, 3D performance, multimedia, these are the spaces AMD and Intel have ruled and there is no reason to think they both can't get in and be competitive.

Hell just at what AMD has been cooking up lately with Bulldozer and Bobcat. We are talking full dual cores with full gaming quality 3D GPUs, all in a less than 20w envelope for most of the chips. And that is just the first gen, the next gen with the new cores with specialized hyperthreading should be even better. And you can be sure with their R&D budget Intel has been cooking up equally low power integrated chips, their only weakness is GPUs (which is why I still wouldn't be surprised if Intel ends up buying Nvidia) but that can be fixed.

So the bigger question would be why would they bother. there is nothing in the ARM design that guarantees low power, especially if you are bolting more and more performance and functionality onto the chip. Remember that ARM was originally built for the ancient Acorn desktop, it was a very primitive chip that they have worked to slowly build more and more functionality onto. There is no reason, especially with the move to x64 where one can lose the old 16 bit baggage that one can't cut down X64 in the same way one built up ARM.

Re:What about Meego?

[Microlith]

Open Source, the way we know and love it today, is filled with projects that struggle with direction. GNOME, KDE and other extremely well known projects suffer from having too many people in charge. Meanwhile, commercial projects have the advantage of having stronger direction which is great from a perspective of getting a project planned, built and "completed."

Which is beside the point, as the kernel itself has a small number of people that decide which way things go, but is wildly successful at achieving goals laid out despite having thousands of developers. It's also completely open.

Google is attempting to keep the project as open as it can while still maintaining its direction.

No, they're keeping it open in such a fashion that they can absolutely control which way it goes while giving an advantage only to the device makers that have partnered with them, while also breaking ties (not that they had any, since it was originally a closed-source project) with everything else in the open source community.

So in addition to being an OS, it is also an "experience" that needs to be consistent and reliable.

Which is beside the point.

And keep in mind that this tablet computing is a new format of computing.

No it isn't. That statement is a lie being fed to justify lockdown and DRM. It's a computer with no keyboard and only a touchscreen, the only new thing is developers being forced to think out their UIs better.

But none of this has anything to do with how completely divorced from the rest of the open source world Android is.

Re:What about Meego?

[dfghjk]

As though that were in any way unusual.

Re:What about Meego?

[Microlith]

Contributing to Android undermines open source because that little-known failed 'Honeycomb' variant is closed source.

Honeycomb is just an example of how Google could arbitrarily close the source of their AND YOUR changes. Android, as a whole, takes from opensource but does not contribute, and is incompatible with the rest of what exists in the open source realm solely due to the fact that it was supposed to be closed source an proprietary.

AOSP rocks!

The AOSP, really, is a disaster. When you have to download files for your device from sites like rapidshare, something is fucked.

Re:What about Meego?

[Microlith]

Don't know about you but no one sane wants changes optimized for always-off cellphone usage in their server distribution.

What kind of ignorant comment is this? Can you say why? I'd be shocked if you can.

In fact it wouldn't be a stretch to say that Linux/BSD/et al just isn't suitable for phones.

Point blank: bullshit.

Google only chose Linux because they have no experience writing operating systems; that and they always settle for inferior solutions when it means shipping a product earlier.

Actually, the company developing Android before Google bought them chose Linux for the same reason TiVO and many other vendors do: opportunistic leeching on the community, while none of their changes ever make it back into the core.

Re:What about Meego?

[Microlith]

Unusual, no. Crap, yes.

Re:What about Meego?

[Kjella]

I guess it comes down to can intel beat a dual core 2 Ghz ARM?

Yes, easily. Can they beat them in the same power budget? Will the ARM do as much per clock cycle as the Intel? Those are better questions. ARM has a lot to learn about high performance chips. Intel has a lot to learn about low power chips. I wouldn't be so quick to wager ARM can learn Intel's tricks faster than Intel can learn ARM's tricks.

The Atom wasn't targeting ARM, it was more about choking AMD by creating a very low cost, low power chip that'd steal a lot of the "value" market from AMD with battery life AMD couldn't match. In that I would argue it was a success and has been a thorn in AMDs side until the Brazos platform launched this year. It is of course a stepping stone on the way to competing with ARM, but it's hardly the best Intel can do.

Re:What about Meego?

[larry bagina]

How many android linux changes have been accepted back into the mainline linux ?

Re:What about Meego?

[drinkypoo]

AMD has Athlon 64 processors on a power budget competitive with Atom, but they gave up on them. I'm typing this comment using a machine powered by one right now. The only operating system it supports properly is Vista. AMD never bothered to even contribute support for its power saving to Linux, and they don't make downloads for the processor or the chipset available, you have to get them through your OEM. And the only support files are for Vista. The machine has a pretty peppy ATI integrated GPU, which again, only works 100% with Vista. Works great in Windows 7 except suspend/resume only works once. Does not work reliably except in text-only mode under Linux, you get trashing from simple things like scrolling even with renderaccel disabled.

I have an Atom netbook too and this thing beats the living crap out of it in the performance category and gets similar battery life per wH if you run Vista. This actually has the "five hour" battery which was nominally true with Vista. I get about 2.5 hours with Linux running just an xterm, and about 3.5 in Windows 7 x64.

Re:What about Meego?

[Desler]

Actually, the company developing Android before Google bought them chose Linux for the same reason TiVO and many other vendors do: opportunistic leeching on the community, while none of their changes ever make it back into the core.

Then they shouldn't have released the code under a license that allowed people to do so. If you want people to be obligated to give back you should have written it as an additional clause in the license. Being butthurt after the fact and then trying to impose a whole bunch of unwritten rules on people on tends to make them either go away or just ignore you even more.

Re:What about Meego?

[Desler]

Honeycomb is just an example of how Google could arbitrarily close the source of their AND YOUR changes.

Outside of the Linux kernel (which they did release the code for) how many contributors who have actually had their changes incorporated into the other parts Android weren't part of the OHA or already partnered up with Google?

Re:What about Meego?

[IICV]

Open Source, the way we know and love it today, is filled with projects that struggle with direction. GNOME, KDE and other extremely well known projects suffer from having too many people in charge. Meanwhile, commercial projects have the advantage of having stronger direction which is great from a perspective of getting a project planned, built and "completed."

Really? Do you have any statistics on the ship rate of commercial projects vs open source projects?

Because even though it is readily apparent that open source projects are abandoned quite frequently, I would wager that commercial projects are abandoned at comparable rates, the only difference being that the wreckage of commercial products doesn't litter the Internet, unlike closed source projects.

It's like the old question, if a tree falls in the woods and nobody's around to hear it, does it make a sound? If a commercial project fails and nobody ever knows about it, does it still fail? If an open source project fails and remains on Freshmeat or Sourceforge for years to come, does it still fail?

Re:What about Meego?

[hairyfeet]

Because like it or not Apple is setting the pace and their whole mantra is form over function, ala the iSliver batteries and the ultra thin designs like Air?

Just like you I would prefer a lower powered device that got insane battery life, but nobody listens nor cares about us. It is pretty obvious just looking at what is coming down the pipe the future is thin thin thinner, which means batteries so damned small you'd be lucky to get two hours out of the things.

Now if the only goal is how thin can you go, while cranking out the bling bling? AMD and Intel will have NO problems in that dept, as I said the new sub 20w Bobcats and BDs have that in the bag. Intel has shown with the Air that they too can go ultra thin, and sadly that is what the future is like it or not. It also helps the OEMs as it makes everything proprietary as hell which means their devices can be "designed for the dump" thus giving them great turnover while making it so support life on a device gets smaller and smaller. Hell most phones are lucky to get even a single update anymore, in the future they will just tell you to shitcan and get a new one.

So while I wish you were right friend, I truly do, I just ain't seeing it. What I AM seeing is device after device trying to top Apple in the "thin and sexy" dept, which means shit battery life, no ability to fix or upgrade squat, and design for the dump. Is it stupid and wasteful? Yes but as you said you take what you can get, and marketing has seen Apple's numbers and frankly don't give a shit about you or I.

Re:What about Meego?

[exomondo]

Actually, the company developing Android before Google bought them chose Linux for the same reason TiVO and many other vendors do: opportunistic leeching on the community, while none of their changes ever make it back into the core.

You just said wrt the changes made to the kernel that there is "Nothing of use or real value, seeing as how little of it ever gets into the mainline" but then you call it 'opportunistic leeching'? So it's only not leeching if they contribute back something that you deem to be of value? In any case since they abide by the GPLv2 under which Linux is licensed their changes are available. So i'm not sure how you can call it 'opportunistic leeching'.

Re:What about Meego?

[davester666]

Intel has been announcing their low-end CPU will "soon" be a similar size and use similar amounts of power as ARM for more than 5 years. And that once they release it, the cell phone market [and now the tablet market] will abandon ARM for the superior Intel chip.

And every year, they are nowhere near ARM in power usage. I guess now they finally use less than double the power that ARM uses in 'on but using low-power', which is the state the CPU is in most of the time, and are desperate for somebody to use it.

Unfortunately for Intel, they will bolt their crappy GPU to it, whereas ARM can weld much better GPU's with their CPU and totally kick Intel's ass.

Re:What about Meego?

[exomondo]

Honeycomb is just an example of how Google could arbitrarily close the source of their AND YOUR changes.

No they can't, your changes are still open. It's just that derivative works can be closed - which is obvious given they used a permissive Open Source license - that does NOT change the license on the code you submitted in the slightest.

Re:What about Meego?

[ZosX]

Actually IOS runs on darwin which the Mach kernel makes up the foundation of. The rest of the system is BSD based though. Oh hell, to clarify here is the wikipedia entry on it:

"Darwin is built around XNU, a hybrid kernel that combines the Mach 3 microkernel, various elements of BSD (including the process model, network stack, and virtual file system),[5] and an object-oriented device driver API called I/O Kit.[6]
Some of the benefits of this choice of kernel are the Mach-O binary format, which allows a single executable file (including the kernel itself) to support multiple CPU architectures, and the mature support for symmetric multiprocessing in Mach. The hybrid kernel design compromises between the flexibility of a microkernel and the performance of a monolithic kernel."

Answer your question? Basically the core of IOS is the same as the core of OS X. Hence all the rumors that the two will eventually converge.

Re:What about Meego?

[ZosX]

Its probably only a matter of time before the android kernel is forked from linux outright......

Re:What about Meego?

[exomondo]

Honeycomb is just an example of how Google could arbitrarily close the source of their AND YOUR changes.

Outside of the Linux kernel (which they did release the code for) how many contributors who have actually had their changes incorporated into the other parts Android weren't part of the OHA or already partnered up with Google?

Regardless of that, google can't just close the source of those changes, all they can do is stop re-distributing them.

Re:What about Meego?

[exomondo]

Unfortunately for Intel, they will bolt their crappy GPU to it, whereas ARM can weld much better GPU's with their CPU and totally kick Intel's ass.

You mean their GMA graphics? Like the ones that use the Power VR? The same Power VR architecture that is used in many ARM devices including the ipad and ipad2?

Re:What about Meego?

[ChunderDownunder]

On the other hand, the Android embedded 'Linux fork' and the dalvik VM may become irrelevant when the class libraries are decoupled from the platform, as in IcedRobot.

Out of Order Execution

[tangent3]

ARM has it since Cortex A9
How is it coming along for the Intel Atom?

Re:Out of Order Execution

[Richard Dick Head]

OOO requires a huge silicon footprint, and it is tricky to avoid increased power consumption. Not exactly an embedded-friendly feature.

Intel

[BasilBrush]

Easy to see why Intel thinks it's worth using X86 for Android devices. Hard to see why anyone else would think it's a good idea - except perhaps AMD.

Re:Intel

[LWATCDR]

Well with Android I just don't see the value but with Windows I do. At least with a Windows X86 tablet you will look like a PC so idiotic websites like Hulu and CBS.com will not restrict content because you are on a "mobile" device or on an "embedded device" and not a laptop or PC.
I can watch Big Bang Theory on my laptop but not on phone because??? And if I hook a box to my TV like Boxee it is different than watching it on my pc because???
Other than that I would agree but I do wish that we where seeing more native Linux on ARM devices and not so much Android.

Re:Intel

[CastrTroy]

Might be nice to be able to boot into android on a standard laptop, or just run it in a VM (not an emulator). I would like to be able to use android, without having to buy a dedicated device.

Re:Intel

[DarkOx]

Don't know about your phone, but as far as boxee goes...

You're still allowing direct egress from clients on your network, which is wrong, and our your http(s) proxy is for some reason not striping information that could identify a specific client behind your gateway like user agent strings, which is wrong.

Re:Intel

[gumbi west]

I'm surprised even Intel is interested. Nobody is interested in non-Apple tablets. RIM's playbook was a dud, the XOOM sold basically nothing, the Galaxy did okay, but only if you don't measure it against iPad sales.

Re:Intel

[Tom9729]

You can do this now, albeit with Android 2.2.

Re:Intel

[DdJ]

Likewise, it'd be nice to be able to run DOSbox on a tablet with good performance. I've got DOSbox on my iPad, and its emulated x86 CPU is good enough for some old DOS software, but performance is not spectacular.

Re:Intel

[LWATCDR]

And the average consumer.. Of course it is hackable.
I don't have a Boxee I got a ROKU which is really cool and cheap.

Re:Intel

[c]

There's the Android-x86 Project. I had an older build booting off a USB key on my netbook. Quite frankly, all I found it good for was as a reminder that a UI designed for a 3" touch screen is a poor, poor fit for a 9" screen with a trackpad and keyboard.

Re:Intel

[camperslo]

Easy to see why Intel thinks it's worth using X86 for Android devices. Hard to see why anyone else would think it's a good idea

What's the point of running it on x86 when all the app out there are compiled for ARM? Unless they're planning to ship with both families of CPU in one device and support both Windows and Android apps, it really doesn't make much sense. If x86 has been too power hungry, emulating ARM or something would likely be pretty poor in the performance per Watt department.

Re:Intel

[Wild_dog!]

Yeah... I have it on my parallels 6.0 running as a VM on my Mac. Still haven't done much with it, but I thought I would like to play with it.

Re:Intel

[gumbi west]

Just look at google news. Bank's stock market analysts have the numbers now. here is one that describes sales as "light." It is not surprising because all the reviews appear to say the product is not done (you will have to google for those yourself).

Re:Intel

[ZosX]

You do realize that android runs on the dalvik virtual machine and that most of the code is basically java right? They are therefore compiled for dalvik as bytecode. 2.2 added support for JIT. In my experience with a G1, JIT doesn't make a huge difference in the real world because there are penalties for using it as well, especially when it comes to opening apps. There are also examples of native code, say C++ compiled for arm v6 processors, but I would imagine every app out there is running purely on the VM because it would be a lot of work to support the various major versions of arm architecture that are out in the wild. Some of the core OS parts are certainly running natively, but as far as I know, just about everything else is dalvik.

Re:Intel

[Man On Pink Corner]

Give me a break. They released a tablet that works only when tethered to one of their embarrassingly obsolete smartphones. Who would expect a scheme like that to succeed against Apple?

Blackberry brought a flashlight to a gunfight. What sort of drugs they're smoking in the executive suite is anybody's guess.

Re:Intel

[gumbi west]

You wrote, "It's funny people are still in denial about the success of Android. Sure, uptake of Android tablets is not as spectacularly crazy as the iPad's (not even close)"

Who is in denial again?

Before Android tablets: as soon as there are Android tablets the iPad is gone.

After first Android tablets released: these are so much better, the iPad is gone.

After real sales numbers returned on Android tablets: in just a few generations the iPad is gone.

I agree that the iPad (or any other Apple product) will probably not be THE tablet in 5 or 10 years, but I doubt it will be an Android tablet that displaces it.

Atom vs. ARM

[darjen]

I have an ARM based tablet running Android 2.3. Why would I want to use Android on x86? Is it really that much faster?

Re:Atom vs. ARM

[jcombel]

the point isn't that you can use android on x86 (chips will always leapfrog eachother season to season on performance capabilities)
 
the point is that once android does support x86, theoretically there could be more tablet homogenization - a company could release the same model running both android and, say, windows, or you could purchase one and install your favorite linux distro, customized to suit the tablet

Re:Atom vs. ARM

[vivek7006]

YES

Re:Atom vs. ARM

[LWATCDR]

But it will lead to app fragmentation because you will have to include X86 as well as arm in the binaries for any program that uses the NDK. Which will increase the size of the apps or you will have to include an ARM to X86 JIT compiler or maybe an ARM to X86 install time compiler.

Re:Atom vs. ARM

[Anonymous Coward]

Since most *apps* are compiled to Dalvik bytecode, most developers won't care. Not many features/apps require use of the NDK. Durr.

Re:Atom vs. ARM

[oakgrove]

That's interesting. I have an Acer Aspire One with an Atom N270 running at 1.6 GHz and a Motorola Xoom with a Nvidia Tegra2 overclocked to 1.4 GHz. The AAO is running Ubuntu natively and the Tablet has it installed in a chroot environment. Every benchmark I have ran, the tablet has inched out the netbook by a few percent. If anyone has an idea for a benchmark, I'd be happy to run it.

Re:Atom vs. ARM

[Belial6]

I would hope that it actually helps by discouraging anyone from using the NDK that doesn't absolutely have to. Hardware banging is a pretty bad idea in this day and age. It isn't always avoidable, but it should be avoided any time it can be.

Re:Atom vs. ARM

[Locutus]

and the point ends up enabling Microsoft to come in and pay vendors to put Windows on the device at the expense and exclusion of the other OS's. ARM means you'll have vendors adapting and competing while x86 means you get Microsoft's vision of the world and you only get Windows unless you are creative enough to install another OS yourself. We know most of the world does not install their own OS and couldn't if their lives depended on it.

We are already seeing Intel paying vendors to push out x86 devices so they'll also be taking Microsoft's funny money because on x86 they can throw Windows while on ARM they can not. Consumers lose because of the lack of choice and they'll lose because the x86 and Windows solutions will not have the staying power in the portable device segment because of the bloat. IMO

LoB

Re:Atom vs. ARM

[npsimons]

Hardware banging is a pretty bad idea in this day and age. It isn't always avoidable, but it should be avoided any time it can be.

As a past embedded, kernel, and driver developer, I'm always tempted to laugh at people who think they "need to program closer to the hardware", but I usually refrain and ask them these questions instead:

• Are you writing embedded/kernel/driver code?
• Have you profiled your code and found the hot spots?
• Have you analyzed your design to find a better algorithm?

If the answers to all of the above is "no", then they don't need to be programming closer to the hardware.

Re:Atom vs. ARM

[LWATCDR]

That depends how low you feel you must go. Now that Dalvik is a JIT there is probably less need but still not zero. And yes I agree with you that one should do all of the above but the leap from Dalvik to C++ using OS calls is not exactly what I would consider bit banging the hardware. Now bypassing the OS and going to the hardware... Well that is just not what one should do on a Mobile device IMHO.
I am pretty sure that a lot of games use the NDK and OS calls for a bit more speed.
Oh and I have worked on Linux driver code. I was shocked with just how much you can do at such a high level. I was afraid I was going to have to brush off my assembly but I added the features I needed with just c.

Re:Atom vs. ARM

[the_humeister]

I would suggest linpack and povray.

Re:Atom vs. ARM

[thetartanavenger]

I have an ARM based tablet running Android 2.3. Why would I want to use Android on x86? Is it really that much faster?

Most consumers don't give a diddle about arm vs x86, they just want a tablet that works. Intel wants in on some of the tablet money running around and this is their only way in. Meanwhile it'll also give the consumers more choice and nvidia/qualcomm/arm/whoever more competition keeping innovation running. Wins all round as far as I can see.

Re:Atom vs. ARM

[Desler]

Or you know you have code already written in C or C++ that you don't want to have to spend time and money rewriting. Not everyone who wants to use the NDK is doing it for stupid reasons.

Re:Atom vs. ARM

[npsimons]

Or you know you have code already written in C or C++ that you don't want to have to spend time and money rewriting. Not everyone who wants to use the NDK is doing it for stupid reasons.

Ah, I didn't see the GP; I was assuming they were referring to coding things in assembly; to me, /that's/ low-level. One of my big gripes with Android has always been that they want you to rewrite applications in Java. There's so much open source out there that's not Java that I think that approach is foolish. Heck, in my fantasy-land, Android was going to be Linux on a phone where at worst you had to redesign the V&C, and at best you could just recompile for ARM. Too bad it didn't turn out that way.

Re:Atom vs. ARM

[npsimons]

Oh and I have worked on Linux driver code. I was shocked with just how much you can do at such a high level. I was afraid I was going to have to brush off my assembly but I added the features I needed with just c.

It is lovely and at the same time scary just how much OO has creeped into the Linux kernel, just out of pure necessity. It's been awhile since I've had to hack on the Linux kernel, but I'm glad to hear things have continued to improve.

Re:Atom vs. ARM

[grouchomarxist]

Well, Microsoft already announced that they're doing ARM for Windows, so looks like it's going to happen either way.

Re:Atom vs. ARM

[Locutus]

Microsoft saying they will do something does not mean it will happen or it will be desired. They would much rather the whole ARM platform went away just like they worked hard to limit the netbook segment by bloating the hardware requirements to run Windows and bloating the price if you wanted an OS which wasn't artificially limited. Look at all the past tablets based on Windows and you'll see they were big, heavy and expensive. It was not because of hardware limitations so Windows for ARM is currently a marketing placeholder and nothing more. x86 is where they would rather be and you can bet money they will pay OEMs to do x86 over ARM every time they run across it.

LoB

Re:Atom vs. ARM

[ZosX]

Yuh. The atom should decimate when it comes to floating point.

Re:Atom vs. ARM

[laederkeps]

What makes you think that won't happen on ARM as well?

Re:Atom vs. ARM

[badkarmadayaccount]

As someone with experience in the subject, what traits do you think the system programming language of the future needs?

Re:Atom vs. ARM

[Locutus]

it could but it will require a product from Microsoft so compelling that the ARM vendors would put the Windows based product above all others including Android which would already have a good running start. The other problem is that on ARM, native Windows( win32 based ) will not work so Microsoft has to establish a software base for the platform and prevent the confusion people would have trying to run their x86 based programs on Windows for ARM.

So they could but lots more ducks need to get lined up before Microsoft would have the power, influence, and support to pull it off. On x86 Microsoft already has everything they need to market what looks like a usable product so the Intel push helps Microsoft and is detrimental to the others. IMO

LoB

Re:Atom vs. ARM

[npsimons]

As someone with experience in the subject, what traits do you think the system programming language of the future needs?

Actually, I don't think I'm all that qualified; I've never written my own OS. But looking at people that have (Torvalds, Tannenbaum, Ritchie, et al), I would have to say that a programming language that wants to be used for OS implementation will have to displace C. That is, it needs to have the power of C (low-level HW access at a minimum), but also have that something little extra that gives it an advantage. The more expressive and succint you can make a language, the more powerful it will probably be.

Oh, and never write a programming language for someone else to use; make sure any software you write is something you would want to use, otherwise it will probably suck.

and how will this work

[peragrin]

Adobe already requires each phone manufacture to send their phones to adobe to make sure flash might work on the platform, with a whole other processor to support for the same OS adobe will never be able to keep up.

Re:and how will this work

[geek]

Who cares? If Adobe can't keep up (entirely their own problem) then they will fade away.

Re:and how will this work

[gig]

Already faded.

Re:and how will this work

[hansamurai]

Keep up looking out for the little guy for us all. Thanks!

Re:and how will this work

[alostpacket]

Huh? Isnt x86 the arcitecture they know best? And agreed with the other poster, what does Adobe have to do with this? heh. I'm generally a fan of their products (even though ./ isn't) but kinda off topic, no?

Re:Meego?

[rumith]

Meego wasn't Intel's Linux stack, it was Intel's and Nokia's. And now that Nokia has *ehem* changed its strategy to become a Microsoft-only vendor, Meego is dead.

Re:Meego?

[rumith]

Sorry, I must've been in a hurry to bury MeeGo. The correct answer to the question "where is MeeGo" is "in the next article".

Perhaps Ubuntu for phones would be better

[mschaffer]

I would rather have a slim Ubuntu on my phone than have Android on my x86 box/slate/tablet/whatever.
There are plenty of good operating systems out there and I would rather not have Google's also-ran, closed-source OS in front of me.

Re:Yeah, and OS X

[mschaffer]

How long until they sue someone.
Who haven't they sued yet?

Failure

[Archangel Michael]

.. to realize that mobile is the new desktop. And devices that do one thing really well are better than devices that try to do everything not very well.

Re:Failure

[LWATCDR]

???
A desktop does a large number of things not one thing really well. mobile is the new desktop... So mobile must do many things well and not one thing really well? Or it isn't really the new desktop and should stay specialized mobile device that isn't as flexible as the desktop?
You are really contradiction yourself.

Intel as main MeeGo supporter

[zdzichu]

So it means that MeeGo is even more dead? Intel was last standing supporter if it, and now Intel is interested in different, competing OS. Sad.

Re:Intel as main MeeGo supporter

[Microlith]

Go read my response near the start of this topic. No, MEEGO IS NOT DEAD. People should think before they vomit all over Slashdot.

What benefit of out-of-order?

[tepples]

What is the benefit of out-of-order if your binaries were compiled with the optimizer set to Atom? In that case, the compiler will already have reordered the instructions to fit Atom's microarchitecture. And what is the benefit of out-of-order compared to simultaneous multithreading?

Re:What benefit of out-of-order?

[AcidPenguin9873]

In that case, the compiler will already have reordered the instructions to fit Atom's microarchitecture.

Sort of. There's not much a compiler can do when you have a last-level (L2, L3) cache miss, which takes hundreds of clocks to service. Even an L1 miss hurts somewhat. OOO processors can execute other, independent instructions for which it has data available in registers or in the L1, and which are in the processor's OOO execution window. In-order processors can't do much. Atom does have some limited ability to hide cache miss latency via some bypassing around L1 misses, but not as much as true OOO.

And what is the benefit of out-of-order compared to simultaneous multithreading [wikipedia.org]?

SMT gets you throughput on multiple threads, for a cheaper area/power budget than just stamping another core down on the die. Obviously it's not as good as another real core, but for some applications that lightly load the processor, for example memory-bound or I/O-bound apps, it is pretty good. It does nothing for single-thread performance however; it can even hurt it single-thread IPC, in fact.

What HTTPS proxy?

[tepples]

your http(s) proxy is for some reason not striping information that could identify a specific client behind your gateway like user agent strings, which is wrong

What HTTPS proxy? A proxy is a man in the middle, exactly the sort of thing HTTPS is designed to prevent. In order to make an HTTPS proxy work, one would first have to add the proxy's root certificate to the device so that the proxy can sign its own TLS certificates. And as I understand it, tivoized devices are designed specifically not to allow this.

Applications ported from another platform

[tepples]

Say you have an application designed for both PCs and Android devices. The core logic is identical for all versions of the application; they just have different front ends. Now say the application wasn't written in the Java programming language to begin with but instead in standard C++. Can one compile standard C++ to Dalvik bytecode? Or would it involve a line-by-line rewrite by hand into the Java programming language? Such a rewrite would likely introduce errors, and it would require all future changes to the application's logic to be made in parallel in both the standard C++ version and the Java programming language version.

Re:Applications ported from another platform

[badkarmadayaccount]

If you use a strongly pointer typed dialect, like C++/CLI, writing a compiler wouldn't be and issue, but generic C++? With advanced program analysis, and a lot of debugging, yes, otherwise, no.

Re:Yeah, and OS X

[confused one]

They learned this from BSD, which is a grandparent of OS X

How do I make SVG cartoons?

[tepples]

So you claim that Adobe products have "Already faded", and I presume this means in favor of HTML5 technologies such as SVG. So what graphical authoring tool should one use to create SVG+JS animated cartoons with synchronized audio, like those found at sites like Albino Blacksheep, Homestar Runner, and Newgrounds?

Re:Yeah, and OS X

[DrXym]

Great to see Apple's architecture agnosticism is catching on.

Android has always been reasonably portable. The kernel is Linux after all, and most of the user land doesn't care too much aside from JIT / interpretter code. Indeed Android has been running on x86 and MIPS processors for a while now.

Biggest issue are probably native apps. I don't understand why there is no LLVM target so that devs don't have to care or worry what processor is running in the tablet / phone / box but still benefit from native runtime performance. Curiously Renderscript (a new API) in 3.0 does use LLVM but not the NDK.

ugh

[Anonymous Coward]

No offence linux fans... but who the hell is going to buy a x86 tablet. Are they going to suddenly start changing compilers to produce intermediate code only so that they can be compiled upon execution and work everywhere? This is the same problem microsoft has here too.

Yes an x86 tablet can be made, but it's going to be nowhere near as efficient as ARM. How does Intel propose to solve this? Bring up the old pentium pro architecture at 32nm? Great, put two cores in? Great. Put all the extra features that it added since it abandoned the p4 architecture? Great. Now what.

I think the x86 architecture is not the right choice for a battery powered device. It's good enough for low-powered devices like nettops and thinclients where the x86, but that's all it's good for. At the high end, Intel makes these overpriced joke chips like the "Extreme Edition" that stupid people buy, and at the low end they make CPU+GPU's that are good at neither. Please Intel stop making crap just to compete with AMD and ARM. We know these chips are junk.

In the grand scheme of things, Intel should instead be putting power consumption on the top of their priorities and bring the TDP down to make the x86 architecture competitive in price. Instead we've been seeing TDP increase with every generation. What I want is a 10 watt TDP with the performance of an i7 at 3Ghz. and 1watt TDP at 1Ghz. Then maybe Android on x86 makes sense. Right now any tablet made on x86 is not what anyone wants. People want the iPad.

Re:ugh

[ZosX]

Am I the only one that is excited at the prospect of say like a dual core atom running at 2ghz in a tablet form? I mean think of all the emulation you could do with that, and likely get at least 4-5 hours to boot. You could even dualboot to windows for some stuff, as well as run ubuntu more than half decently. Just include USB so you can plug in a mouse and keyboard..... I mean seriously. How is this not full of win? Arm makes a lot of sense in, say a phone, or an embedded device, but a tablet might as well be a netbook without the keyboard. I think you geeks out there are in love with arm just because its different and RISC and not boring x86. The fact of the matter is that you could take an x86 tablet and probably even get OS X running on it, and that's pretty cool. Way cooler than some ARM tablet that only runs android. I'll probably get modded to hell for this, but that's what I want in a portable slab. I want photoshop and google chrome for real, not some cell phone OS that was stretched to a larger screen. I mean don't get me wrong I love android, and on the run it is fast and works really well, but when I sit down a coffee shop the first thing that comes out is my notebook. Battery life isn't the biggest concern for me. Heck my crappy notebook barely gets 1.5 hours anymore. If I got 5-6 hours out of a device before it died, that would be pretty good.

Android w/Scalable Window Managers to MID/Desk/Srv

[keneng]

Android has its place for Mobile Internet Device Tablets and that is Android's niche market. Full-capability Linux is the best place to be for everything at home and the office. Having Android x86 for x86-based MID's is ok, but GFLOPS/WATT rankings are yet to be seen on x86 and ARM MID's. If that happens, people will want full-capability Linux and not some restrained version of it such as Android. I find the full-screen touch menus on 5 inch display ok, but on 10 inch Android devices it seems cumbersome and immature because of the pure fact that they take up the entire touch screen real estate when they appear. That isn't necessary. People don't have 10 inch thumbs or at least not yet. The display screens are large enough, but the menus seem targeted for the smaller PIM devices. Work needs to be done to simply bring touch to full-capability Linux and make the menu/button sizes scale proportionally to bigger and smaller touch displays similar to the JAVA's GridBagLayout container and XWindow/X.org/GTK's container xoptions/yoptions to stretch different widgets proportionally to the size of the window. Window managers can work on bigger touch displays. It would be nice that Android could give the option to run the gnome/kde/unity window managers once the bigger displays are detected. If Android integrates gnome/kde/unity, odds are Android will also dominate the desktop for every supported architecture eventually. Android could simply be the consolidated (FEDORA/DEBIAN/UBUNTU) name-brand for the different Linux flavors. It would be easier to keep the Android Devices updated if they were using the repository update tools that already existed. Why it's not already in place is political I'm certain, but common-sense dictates this capability will happen whether the telecom companies like it or not. DIGITAL FREEDOM to the user. These devices currently have enough RAM and storage to be able to handle these capabilities.

Multi-core mobile tablets will continue grow with more cores. I don't believe it will simply replace the desktop though. Desktops with all their accessories and hardware upgradability are KING for the Do-it-yourself crowd.

Ditto for MEEGO...they should scale up and include window managers if they envision Meego/touch/scalable window managers on every device.

Cheers

Syntax error

[tepples]

If you use a strongly pointer typed dialect, like C++/CLI, writing a compiler wouldn't be and issue

Compiling a program written in the verifiably type-safe subset of C++/CLI in a compiler for standard C++ invariably produces a parse error. This is due to the different syntaxes for declaring pointers, references, arrays, and possibly other core language features that I can't think of at the moment. This would mean every software developer would have to write its own C++/CLI compiler for those target platforms that don't already have a C++/CLI compiler.

Re:Syntax error

[badkarmadayaccount]

Mono has an LLVM backend.

Re:Syntax error

[tepples]

But does Mono support Dalvik? Apart from the $399 "Mono for Android"?

Re:Syntax error

[badkarmadayaccount]

Android has an NDK. If you want cross-platform JIT, use LLVM bytecode.

Re:Syntax error

[tepples]

Android has an NDK.

I was referring to what Belial6 wrote: "I would hope that it actually helps by discouraging anyone from using the NDK that doesn't absolutely have to."

Re:Syntax error

[badkarmadayaccount]

What's wrong with it?

ARM NDK vs. x86 NDK

[tepples]

An earlier post explains what's wrong with relying on NDK and languages that currently don't target Dalvik: your apps relying on ARM NDK won't run on a machine with only x86 NDK, at least until Google introduces a portable NDK that recompiles LLVM bitcode to native code on the device, much like proposed PNaCl.

Re:ARM NDK vs. x86 NDK

[badkarmadayaccount]

The ELF specification allows for pointing to an interpreter for the execution of a binary, as as long as you can install executable files, you can use a JIT of your choosing. If the system linker supports it.

Re:ARM NDK vs. x86 NDK

[tepples]

I think the point of earlier posts is that one should not assume that Android-powered products with an x86 CPU will come with such a JIT engine. If it does end up coming with a JIT engine, I'll believe it once I read about it in reviews, but I'm not holding my proverbial breath.

Re:ARM NDK vs. x86 NDK

[badkarmadayaccount]

You don't need one - install it somewhere, and set the appropriate field in the application binary to point to the interpreter path - regular dependency tracking will do. (Android has a capable enough pkg manager, right?)

Antecedents please

[tepples]

You don't need one - install it somewhere

I don't need what? Install what somewhere? I'm having trouble figuring out to which of the nouns in my last post each of your pronouns refers. Do you mean "I don't need an interpreter - install an interpreter somewhere"? That doesn't make sense. Or are you trying to draw a fine distinction between a purely interpretive interpreter, which is likely to be unbearably slow at executing legacy NDK applications, and an interpreter that also has JIT recompilation?

set the appropriate field in the application binary to point to the interpreter path

Where might the interpreter happen to be?

Re:Antecedents please

[badkarmadayaccount]

Gahhhh, you really need it spell out, don't you? You don't need (an interpreter (JIT compilation) built-in to Android), because you can install one as a package dependency. And the interpreter will be where you put it. And it will be the LLVM JIT. Got it?

Re:Antecedents please

[tepples]

Now I understand. An application using the NDK doesn't need Google to provide an interpreter because the application can include it or require a third party to provide it. But that would still require someone to 1. create the interpreter, and 2. make it affordable.

Re:Antecedents please

[badkarmadayaccount]

http://llvm.org/

Re:Antecedents please

[tepples]

Even if LLVM can generate the x86 instructions, someone still has to do the effort of making a translator from ARM instructions to LLVM bitcode. I don't necessarily expect Google to.

Re:Antecedents please

[badkarmadayaccount]

VM Toolkit (LLVM subproject) allows compiling JVM bytecode to LLVM. Skip the conversion to Dalvik, and you're done.