Ice Cream Sandwich Ported To X86 202
angry tapir writes "Google's open-source Android 4.0 operating system for smartphones and tablets has been ported to work with x86 processors. The port means that tablets with Android 4.0 based on x86 chips could be on the horizon. Intel is the top x86 chipmaker, and the company has already said it is working with Google to bring Android 4.0 to smartphones and tablets."
Singularity (Score:5, Insightful)
Re:Singularity (Score:5, Funny)
Re:Singularity (Score:5, Insightful)
This sound like Microsoft's strategy all over again. Anyway you cut it a single platform ecosystem is ugly, as it just lets another monopoly.
New boss same as the old boss
Re:Singularity (Score:5, Insightful)
Re:Singularity (Score:5, Funny)
Microsoft's strategy in an alternate universe where large swaths of the Windows core are gpl2 or apache, every x86 whiteboxer has their own "Windows Distribution" and their primary leverage consists of the licensing requirements to ship Office out-of-box..
RMS went back in time to stop Microsoft before they could begin, but it went horribly horribly wrong, Microsoft sent their best man back in time to stop him...
Balmer still wasn't good enough.
Re:Singularity (Score:5, Insightful)
This sound like Microsoft's strategy all over again. Anyway you cut it a single platform ecosystem is ugly, as it just lets another monopoly.
Sure, Microsoft's strategy, only with an open source OS being built in this case by hobbyists and enthusiasts. Definitely sounds like monopoly building at work to me ...
Re:Singularity (Score:4, Insightful)
Android is nice but don't kid yourself: it is not built by hobbyists and enthusiasts. It's very tightly controlled by Google -- I really appreciate them making source releases when it suits them, but that doesn't change the fact that it's still controlled by them.
In case you were referring to the kernel: linux is partly built by hobbyists but it just isn't a major part of the Android strategy so I don't see how that applies here... Google will keep their linux fork and could even swap the kernel if kernel developers really started being difficult -- it wouldn't be painless but it would definitely be possible.
The point is: Android is tightly controlled by a single entity. Letting them become a monopoly (or even close to one) would be bad. It would be different from Microsoft but still bad.
Re: (Score:2)
Why is this post modded Insightful and not +5 Retarded.
Re: (Score:2)
This is not what the singularity is (Score:5, Insightful)
It's called a singularity because like the singularity of a black hole it's impossible to see what's beyond it. We can see what's beyond this: more progress and more competition. More diversity, more sales, more fitness of technology to our human needs. More connectivity between people.
We've gone beyond moving the buttons around on the word processor to sell it again to the same people who bought it before. But we can still see the future from here and it looks grand.
The Singularity is an even bigger deal, and further out.
hmm... (Score:5, Insightful)
x86 never was a champ in power efficiency. It excels in instructions (performance) though, that's why it has come to dominate the "productive computing" market. The architectures Android was tailored towards both in backend and in api were designed and utilized with instruction frugality and hardware limitations in mind.
Making Android available on the much more powerful x86 ecosystem and its hardware net is counterproductive at best. Why imped a device with the limitations of a toy OS when you can utilize a complete desktop environment?
Re: (Score:3, Insightful)
Re: (Score:2)
ohh!
Now who would have guessed that?
Re: (Score:2)
Anybody who read the summary?
Re: (Score:2)
You missed my sarcasm...
Re:hmm... (Score:4)
It's strange to be being sarcastic to someone rebuffing your original post, as that implies that your whole first post was stupid..
Re: (Score:2)
Consider this. Tablets are getting quite battery efficient, and then you've got combined devices like Asus Transformer that can last up to 16-18 hours on a single charge. That's already way more than most people practically need. Suppose, now, that there is an x86 version with only 10-12 hours of battery life, but runs all existing apps. I bet there would be a market for that.
Re: (Score:2)
x86 is a huge power drain, very inefficient ... so you can now get a tablet that runs hot and has rubbish battery life ...
Re: (Score:3)
The architectures Android was tailored towards both in backend and in api were designed and utilized with instruction frugality and hardware limitations in mind.
Is that why they used Java?
Re:hmm... (Score:4, Interesting)
Re:hmm... (Score:4, Insightful)
Re: (Score:2)
Is your desktop OS touchscreen savvy?
A potential use case for this is to run Android on mains power from your couch using 'desktop' components. e.g. Remove the stand from your Win7 multitouch monitor and 'couchsurf' using Android in full 23" glory!
Re: (Score:2)
It seems our technology continues to expand in all directions and then collapse into a single device. TVs, PCs, and phones are becoming part of the same thing.
You missed out the next step. The lawyers & marketing bods get involved, realise they are losing money, and split the hardware and software up into discrete items again, that they can sell to you individually. Rinse, and repeat.
Power? (Score:3, Interesting)
Re:Power? (Score:5, Insightful)
Yes, but on the other hand, even an Intel Atom is significantly faster than even the fastest ARM... pity Intel insists on supplying their own GPU with Atoms, because the NVidia Ion + Intel Atom.combo was actually pretty sweet.
Re:Power? (Score:5, Informative)
Actually the Cortex A9 found in Tegra 2 and Ti's OMAP 4 series are at the same clockspeed marginally faster than even the top end Atom cpus, IONised or not, even at their standard speeds the differences in performance are not that huge.
http://parisbocek.typepad.com/blog/2010/11/arm-outmuscles-atom-on-benchmark.html [typepad.com]
Re:Power? (Score:5, Insightful)
Clock speed != performance. Especially not between such divergent systems as x86 and ARM. Even comparing clocks between Atoms and Cores is an unreliable indicator of relative performance, let alone comparing different fundamental architectures.
Re:Power? (Score:5, Informative)
True. But did you read what the post you were replying to, which said that ARM Cortex A9 is *faster per clock* than Atom. The Atom is an in-order, dual issue processor with no speculative execution. The Cortex is a reordering dual issue with speculative execution. And the lack of register renaming on the Atom means its 6 general-purpose registers compare particularly badly with the Cortex's 15. Of course it's faster.
Now, OK, the faster A9's I've seen clock at 1.3GHz, compared to the Atom's 1.8GHz, but that means the two are in similar ballparks, and the A9 is *much* cheaper and *much* lower power. And a quad-core A9 typically draws less power (about 1.3W with all 4 cores running flat out) than a single-core Atom (about 2.5W). And there are no quad-core Atoms as of yet, so the A9-based systems (eg Tegra 3/iMX6) are clear winners in total peak performance in a mobile chip.
Re: (Score:2)
Re: (Score:2)
Re:Power? (Score:4, Informative)
Pretty sure things like the tegra 3 would blow away any atom.
But, even things like the omap4 and tegra 2 might be pretty close. Memory bandwidth sucks on the omap, so for some things like large transfers of data atom may excel over omap but not really cpu speed issue. Tegra doesn't share this flaw with the omap.
I never did / read any benchmarks, but I have a dev board with an omap4 on it, and it "feels" just as fast as my netbook. The dev board is currently doing duty as the guest web browsing machine, wifi access point (two radios), radius server, ldap server, firewall, squid proxy, webserver, dhcp server, dns cache, network USB server (serves up a dvd writer to my netbook over wifi this way), and fileserver (laptop hard drive) for the house. It is running Debian wheezy armel (need a few more things to work on armhf before pulling that trigger, but armhf will make it even faster).
As for power, even with all the peripherals (radios, spinning hard drive, USB hub, doing a native build), it is pretty rare to see system power hit 5 watts. Atom is left in the dust here too.
Re: (Score:2)
Interesting post are you using a wifi connection to connect the dvd writer, are the transfer speeds reasonable? I've got an iomega Iconnect which could be running debian rather than the stock firmware.
I ran into a bit of a brick wall with that as it needed faster ethernet to configure it and there was no default wifi address set up in the installation which left me needing to buy a ethernet card or fast router.
Having a writer and a more complete os could be very handy and economical.
Re:Power? (Score:5, Insightful)
Re: (Score:2)
More like that relative to ARM, everything has a rep for being powerful.... The Atom was good a few years ago, but right now the E-350 is a better deal in pretty much every way. Intel's Cedar Trail should have been out in September, then November and right now it looks like January. AMD isn't the only one with delays.
Re: (Score:2)
Re: (Score:3)
That was my thought too, but according to this chart the E-350 is pretty much on par with D525.
Benchmarks, eh?
This benchmark seems to be very favourable to the atom. Not to say that the benchmark is bad, but YMMV, especially depending on the task. It is possible to squeeze quite a bit of performance out of th atom since it clocks quite fast and can issue two instructions per clock. But lacking out of order execution makes it very hard to keep the ALUs busy, which is why hyperthreading helps relatively mor
Re: (Score:3)
Comment removed (Score:5, Insightful)
Re: (Score:3)
One alternative use for this is to use it as a "simulator" for developing Android applications.
The emulator that is included in Android SDK really emulates ARM code (it's actually running QEMU with ARM v5 code). The problem with this is that it's rather slow, even on high end computers. Anything that runs opengl is extremely slow and not usable.
The Android X86 project makes it possible to run Android in eg VirtualBox. You can then test applications in a much better environment. (Well, currently OpenGL still
Re: (Score:2)
nothing more than a recompile Android doesn't automatically download associated native binaries based on cpu type? If NDK is anything like JNI, it's a question of loading the right shared lib.
Re: (Score:2)
While slightly off topic - if you like ion, try amd fusion (e350m series)... very much like atom, but actually worth having (faster, and generally better hardware).
I liked the idea of atom, until i got one and compared to a (at the time) 8 year old epia (N10k)... the atom was about 1.5 times the speed and sucked down more juice... I was really disappointed with the atom processor... ION made it worth while, but in reality the atom is a POS bang per W is very low on the platform and the atom has had several
Re: (Score:3)
Re: (Score:3)
But isn't the x86 instruction set inherently silly? I thought modern processors run RISC cores with shenanigans wrapped around to implement the x86 legacy. Surely that means that they are inherently less efficient even if it's only marginal.
Looking at the 4+1 thing that NVidia has done with Tegra3 I think it may be too late for x86 and it may finally die a death. We can only hope.
Re: (Score:2, Informative)
Re: (Score:3, Informative)
All major processors except Itanium use microcode, including most ARM implementations. It's not an x86-specific thing.
The second sentence is true. The first one, well, do you consider SPARC and Power Architecture processors to be "major processors"? If so, where's a citation to indicate that they use microcode? Even if not, where's a citation to indicate that most ARM processors use microcode?
Also, what "run RISC cores with shenanigans wrapped around to implement the x86 legacy" means is that, on at least some modern x86 processors (dunno about Atom, but Intel's other processors since Pentium Pro, as well as, I think,
Re:Power? (Score:5, Insightful)
The X86 instruction set was silly, then it stopped being silly as instruction bandwidth became a limiting factor for RISC processors. Ideally you want a kind of huffman coding for instruction sizes, so that the most frequent instructions are the smallest. Traditional RISC makes all the instruction the same big size, so you get the worst bandwidth through a limited instruction bus.
In today's world, where on chip busses are so much faster than off chip busses and instruction bandwidths are limiting, having compact instructions over the pins, being converted on chip to regularized RISCy instructions makes complete sense. So X86 stopped being silly a while back.
If you wanted to design a new instruction set today, you'd optimize for things like instruction bandwidth minimization, security, parallelizability and important application loads (e.g. more DSP). In that light, X86 might be a bit messy, but it is far from silly, especially after the 64 bit cleanup.
Re:Power? (Score:4, Interesting)
I hear this thing about instruction compression quite a lot.
On high end CPUs like the core iWhatever, basically the decoder makes little difference. The power budget goes into the massive array of parallel execution units and a honking great out of order register renaming unit to keep the execution units busy. The transistor and power budget for the decoder is minimal.
On lower end CPUs, especially the Atom, ARM and so on, you still need the same size decoder, but now the overall transistor budget is much smaller, so it takes up a much larger fraction of the transistor and power budget.
It certainly does offer some compression, though it is wildly ad-hoc. However, one could essentially replace the decoder with an equivalent number of transistors in the instruction cache. That would probably help a lot. Expecially as the small instructions that do complex things are not favoured by compilers (hard to use) and so little effort has gone into making them fast.
Also, the ARM chips have the thumb instruction set which is purposfully designed to be compressed. It is much less ad-hoc and I would suspect it gives better compression than x86. Also, because it's been designed with compression and simplicity in mind, it doesn't have all of the variable length with evil dependencies nastyness that x86 has.
On the very low end in today's world, you have something like the PIC 12F675 which heroically squeezes a RISCy instruction set into a 14 bit wide bus. Quite entertaining to program as you have to work around the hoops they jumped through for extreme cheapness and low power.
Re: (Score:3)
16 registers and no register-limited instructions mean that you have far fewer register-register moves than in x86 (the x86 register-memory instructions offset this somewhat). This is one of the big improvements that x86-64 brings to the table.
Predicated instructions mean that you can avoid a lot of short branches. This is grea
The CISC vs RISC issue is dead (Score:4, Interesting)
Don't mix your memes.
Long ago CISC vendors implemented RISC as a sublayer, and the two merged. This flamewar is officially over.
The 4+1 thing is a different flamewar: SMP vs AMP (Asymmetric vs Symmetric MultiProcessing). This one is still hot because AMP is fairly new. I'm a big fan of AMP, but the SMP camp is rightly concerned about complexity of compilers and tools, race conditions and what not. Too soon to tell, but here's a thing: we dealt with the transition to 486 pretty well, and that was a merging of heterogeneous cores - a processor and a math coprocessor. We integrated GPUs and physics coprocessors pretty well, and I/O offloading too. I think we'll weather this change and come out the other side for the better. But the outcome remains uncertain. The problems involved are certainly challenging.
Re: (Score:2)
Perhaps I'm being naive, but the AMP thing in the style of Tegra (5 compatible cores with one much slower than the others) is the OSs problem, not the compiler or anything else. The main problem for race conditions is that IIRC, it is not cache coherent with the other cores, but it seems that is the problem of the OS to never schedule threads/processes sharing memory onto different units.
Even in a regular cache coherent SMP setup, one cannot rely on the cores all running at the same speed, since process wil
Re: (Score:3)
Processors are not atomic physical units -- or, put another way, the "laws of physics" don't get your software running as anything besides first principles.
Processors are one of the most complicated engineering feats of the human race, and performance characteristics of same are very, very complicated. Even such detailed factors as the relative size of an instruction word in the chosen instruction set have tremendous implications for power consumption and processing speed. In addition, even between proces
Re: (Score:3)
Yes, interesting question, but difficult to ask correctly. x86 power consumption is all over the map, varying with features, and the same can be said for ARM. More interesting numbers are MIPS/Watt, FLOPS/Watt, and MACS/Watt. Then of course, MIPS don't translate directly into whether or not the platform "feels snappy". Some of those Watts might be better spent on fast display updates than on MIPS when you look at the total platform experience.
Re: (Score:3)
Re:Power? (Score:5, Insightful)
Intel's not the only foundry on 22nm. Obviously not, since they buy their lithography equipment from third parties that must have more than one customer. They're investing heavily in this area it's true. Trigate is slick, but there are a lot of up-and-coming technologies Intel can't prevent. Apparently Intel forgot to patent the 90 degree rotation of trigate.
Intel's problem isn't their hardware, it's the software that runs on their hardware. In the executive suite they've got a Windows habit that's hard to kick. That worked for a while, but that day is coming to an end. People are starting to look from their WinTel PC to their iPad, iPhone, Android tablet or phone and ask: WTF? Why is this all-day battery-powered thing more capable and responsive than the half-kilowatt new desktop before me? For a lot of years the proclivity of Windows to consume all of Intel's Moore's law progress in hardware with slower software was a good thing. It moved a lot of units - encouraging people to upgrade both hardware and software, but Apple and now Google have spoiled that game. It was a trick and now the trick is told, all bets are off. It's a new game now.
Truth be told I was always amazed that people with a 3GHz dual-core processor just accepted that to get a desktop they should fire it up and go get coffee because they knew it took five minutes. That's performance we wouldn't have stood for in 1984 when processors were less than 0.01GHz and storage was slower still. A 3GHz single core Intel processor from 2005 retiring 4 instructions per clock retires 3.6 trillion instructions in five minutes. A modern SATA hard drive can deliver something like 4.8GB in five minutes. A modern gigabit network connection passes 6GB in five minutes. A reasonable desktop environment takes about 3MB and a few million instructions to present. Do you get what I'm saying? The hardware isn't the problem and it hasn't been since about 1993. Just abandoning crap software isn't going to get Intel out of the woods though now. That might have worked in 2003.
Intel's software partner Microsoft got the clue first, and now the word is that Windows 8 will be expressive and performant even on Windows XP machines, and run on ARM too. That's not going to move a lot of Intel CPUs any more. By all reports the WinTel marriage is on the rocks and could be over soon.
In the executive suite Intel's focused on exactly the wrong things: improving what they're doing, not cannibalizing their current markets. That was a good strategy for a while, but it's not going to weather the current changes - as I tried to tell them seven years ago. Now they need something... different.
So now Android runs on X86. That's a good thing. It can run in a VM on your modern Windows desktop in W7 with Microsoft Virtual PC, and give you the Android apps from your phone in a window on your PC. They can share accounts and data in the cloud. HP should have (and I believe planned to) done this with WebOS, but I believe caved when MS explained the consequences. But Intel's focus is still on the widget, not solving the real problem. Android on x86 is just going to move people to ARM faster if Intel doesn't get their software religion under control. This should be dead simple. Intel doesn't sell Windows and they should not care whether Windows lives or dies. They sell platforms, and help software vendors implement those platforms. They need to shift from that to delivering experiences, and controlling those experiences to a limited extent.
There are others without Intel's history and established markets who are ready to solve the real problem. Intel can join them or get out of the way. This is going to happen very fast, so Intel doesn't have forever to dither about figuring out where the road ahead might be.
Re:Power? (Score:4, Informative)
Why is this all-day battery-powered thing more capable and responsive than the half-kilowatt new desktop before me?
Really depends on what one is doing. Generally the all-day battery powered things can't do all that much, otherwise they start to loose the all-day thing. I wouldn't dream of replacing one with the other though. The idea of a locked-down single tasking workstation is terrible.
Truth be told I was always amazed that people with a 3GHz dual-core processor just accepted that to get a desktop they should fire it up and go get coffee because they knew it took five minutes.
It's a mix of things. The bootup is slow for three main reasons. The first is that PCs do a lot of stuff before even getting to the hard disk. Things like self-testing, running weird ROMs of random PCI cards probing hardware, firing up USB so you can change BIOS settings, checking RAM, probing disks and so on. I've had workstations before than between the SCSI and network cards could take about 10 minutes to boot. Of course that is all great because it means that they CAN support all the weird and wonderful crap that PCs support.
The second is that the OSs have to do rather careful hardware probing. You can dumo a random linux kernel on a random PC and it will probably boot whatever the hardware. PCs provide a rich mechanism for discoverable hardware that allows for wonderful possibilities for expansion. There is also a lot of cheap hardware thancan do very silly things if you are not very nice to it, so the probing has to be rather conservative.
The final stage is between kexec("/sbin/init") and the desktop (or equivalent). That's generally inexcusably slow. A lightweight system (like my eee) can do that lot in about 3 seconds. People seem to be working on solving the speed problems for fatter systems.
But the first two problems are a blessing and a curse. Devices like phones etc have fixed hardware, and so don't need to do the first two stages in any meaningful manner, massively speeding boot. It also means that a lot of per-system hand hackery has to go into the kernel (and there are some good rants on that topic).
So PCs are slow to boot but you get a lot of benefit for that slowness. But I really don't care much. My laptop comes out of sleep in under half a second. My workstation stays on 24/7. Boot time has pretty much ceased to be a problem.
And your memories of yore are (as is often the case) rather rose coloured. Take, for example my faithful BBC, running at a glorious 0.002 GHz. So you switch it on and...
ZWOOWWW BOOP!
>
booted in about .5 seconds! Great now what? Well, you either have to start typing BASIC, crank out the ole' tape drive or floppy drive and wait a very long time or a bit of time for the software to load.
If you were posh and had a master, then it came with things like an editor in ROM, so you could do ome fairly limited stuff instantly. Well, ASUS motherboards seem to be able to boot to some cut-down desktop Linux before doing most of the biosy stuff, just like that.
But I never use it since I never reboot.
Re: (Score:2)
they start to loose the
oops. I hate when people do that. Now i have. :(
Re:Power? (Score:5, Informative)
"The release isn’t fully stable — missing sound, camera, ethernet, and hardware acceleration for Intel chipsets. What will work however is Wi-Fi, sound, and hardware acceleration for AMD chipsets."
Re: (Score:2)
because intel releases press infos every 12 months about moving to handhelds.
do they ship intel slabs to these guys for porting? not really.
Re: (Score:2)
I loaded Android 2.2.2 from the site in a virtual machine in my Asus AMD laptop and found networking (wifi) not working.
(Almost) same here.
I loaded a previous version on my Intel/nVidia netbook and it was working very well.
Unfortunately, like in your case, wifi wasn't working, so it wasn't much use.
I'm really looking forward to trying ICS, since it's the first Android version which natively supports input devices, including mice.
I'd like to try using it as a permanent netbook OS. I think it might make sense there.
Re: (Score:2)
An ATOM-based tablet might not be ideal now, but maybe Intel has already plans to offer something more competitive to ARM. It makes sense to have an already ported OS available once that comes out.
Apart from that, I think an x86 version of Android might be interesting for a TV settopbox. Together with a WIImote instead of a touch screen it would provide a nice user interface, and you could use standard processors for that, not just Atoms.
Samsung Slates (Score:3)
Emulator? (Score:5, Interesting)
Does this mean i can run the apps natively without using an emulator on a windows box?
BlueStacks (Score:5, Interesting)
You could already do that [bluestacks.com].
Well, more or less. It's a port of the Android libraries to a Windows JVM, which is sufficient to run many/most Android apps (much like what RIM are doing). It's not a port of Android itself. But it does run Android apps in windows on your desktop (or fullscreen).
Re: (Score:2)
Re: (Score:2)
Can someone walk me through this? I've tried getting ICS 4.0 to run on virtual box with no luck so far.
Re:Emulator? (Score:4, Informative)
There is a guide for Android X86 on VirtualBox on their wiki (http://www.android-x86.org/documents/virtualboxhowto).
I've tried Gingerbread and Honeycomb before and they work reasonably well. (OpenGL isn't well implemented yet, so Honeycomb and likely ICS will have some performance problems.) I haven't tried to use them as emulator replacements though, not sure how much work it is to actually make it possible to get ADB working with Android X86 in VirtualBox.
Just make sure you disable "Enable absolute pointing device" in the VirtualBox motherboard settings to get the mouse to work.
Previously I've used the Eee PC build of Android to get it to work, I haven't tried getting the ICS port to work in VB yet (there isn't a Eee PC build of it yet).
Re: (Score:2)
Ah, ok - the lack of an Eee PC build is probably what I am missing. I get to some sort of clock comparison check and it sort of stalls during load on 4.0; 3.2 loads flawlessly. I guess I'll just have to wait!
It's a shame that there's no Virtual Box fix to pass off a wired connection as a wifi connection so you can try some of the internet functionality of Android(!).
Misleading title (Score:2, Insightful)
Re: (Score:3)
Intel! Make me a sammich!
Ah-ah-aah! You didn't say sudo. [xkcd.com]
Comment removed (Score:3)
Re:Desktop Distro? (Score:4, Funny)
I vote for a desktop distro. I take back everything I've said about LibreOffice, I shouldn't have judged it by its stupid name. I discovered that it can use .docx the other day, I was somewhat shocked since that was the only reason I was hanging onto MS Orifice, which, as pretty as it is, is getting quite annoying these days. I would definitely try an Android desktop distro! I've been using Mint 12 for a couple of days and I'm still experiencing quirky behavior. It was pretty bad with Gnome 3, and MATE is not much better, oh well, back to Gnome Classic (No Effects). Installing an Android desktop would be like Christmas morn. It would be oh so sweet to see laptops available "like your phone" for consumers....with free Microsoft compatible office software!!
I wonder if one day we'll see MS Office sold with "Compatible with Google Apps" on the box...
Re:Desktop Distro? (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Somehow it missed all of the racist rants.
And I saw none of "naked", "petrified", "hot", or "grits" in there.
Re: (Score:2)
Or the I for one welcome that in Soviet Russia all of us belong your bases ...??...profit
It is an interesting point though - has Slashdot groupthink got to the point where a reasonable chatbot could work -- I'm not thinking of a full Turing test - just be enough to fools a reasonable percentage of skim readers?
Some years ago I wrote a "Canonical Daily Mail Letters Page" generator which used phrases and a few key topics -- it worked (sort of) but I got bored and never quite got it polished enough to try out
Re: (Score:2)
Not this shit again. (Score:2)
x86
smartphones
barring any major improvements in batteries, that just isn't going to be feasible.
The fast ARM phones are brutal enough on batteries, as it is.
Anyone try it in VirtualBox yet? (Score:2)
Re: (Score:2)
The question is... (Score:2)
Why?
When will the Linux layer be replaced another OS? (Score:2)
When will the Linux layer in Android be replaced another OS?
I don't trust Google in this matter since they don't use the standard kernel.
Re: (Score:2)
By Google? Highly unlikely that we'd ever do that. We're pretty heavily invested in the Linux kernel and it's been working well for us in Android.
By some other entity? Could happen, but the mid and lower layers of the Android stack depend pretty heavily on running on a Linux kernel. It'd be a bunch of work for questionable gain.
Thanks for the answer! (Score:2)
Brian, thanks for the answer and the important perspective - questionable gain!
It would also be nice to hear some perspectives on future Android compatibility with GTK/Qt/etc. :)
If I run this on VB... (Score:4, Interesting)
Can I spoof Carrier IQ?
What is it when you feed fake data to someone stealing/selling your personal business; we need a new word?
In any event, here's to poisoning the cache.
why x86 tablets/phones? (Score:2)
I don't understand the point of trying to run the x86 architecture on a device where you want efficiency and low power use.
Android native on every computer ASAP (Score:3)
You need to get Android apps running on every desktop computer, at the same snappy speed they run on cell phones.
Microsoft is looking to sneak this in the back door by forcing Windows 8 users to become Windows Phone users. You can counter this by putting a full Android runtime into Chrome, and perhaps even making it dockable in Linux/Mac/Windows as well. With the full catalog of Android apps available on every desktop, Android will become the de facto new standard operating system for everything, everywhere.
Do this now. Before Microsoft does.
Re: (Score:2)
Re: (Score:2)
Re:So 2012 is the year of Linux/Android desktop? (Score:4, Insightful)
This was a direct response to Windows 8 on ARM.
Not quite. There have been projects adding x86 support to Android since 2009. There have even been devices that used x86 chips, such as the Cisco Cius. This move is more along the lines of Google supporting as many chips as possible to open up the opportunities for manufacturers and developers. So far, the focus has been on ARM chips since they are low power and well suited for mobile phones.
If anything, Windows 8 is on ARM as a direct response to Android and iOS.
Re: (Score:2)
Re:So 2012 is the year of Linux/Android desktop? (Score:5, Funny)
Every build of Android since, as I recall, 1.5, has been ported to x86. It's part of Intel's (silly) strategy to put Atoms in cell phones and tablets.
I'd like an Atom in my cellphone. Then I could use it as a hand-warmer in the winter.
Re: (Score:2)
I'd like an Atom in my cellphone. Then I could use it as a hand-warmer in the winter.
You can do it with any ARM Android phone - just open any web page with Flash on it. You can bookmark it on the home screen for your convenience.
Re: (Score:2)
not really just intels.
this is community driven thing. that's why they manage to get releases _out_.
anyways - ndk as x86 support as well so that's the real proof.
Re: (Score:2)
it's about being able to play angry birds on a laptop, not about being able to play commander keen on a phone.
Re: (Score:2)
don't even need to install chrome (Score:2)
It runs fine in firefox on linux
Re: (Score:2)
It's about not keeping all your eggs in one basket. What happens if ARM suddenly dies? Or say Intel finally comes out with a 1W, quad-core, 2gHz x86 processor that kicks absolutely every ass ever known. Being able to immediately use that gives them an edge over Apple and the rest.
Besides, Android is Linux-based. The effort to make it run on x86 is probably not too significant, certainly not as hard as porting from scratch. It's a case of "why not?".
Re: (Score:2)
So, is this the death of ChromeOS?
Re: (Score:3)
Google stated that they intend the two codebases to merge at some point in the future. They wanted to start at the two ends and meet in the middle. So, it's not so much a death as an assimilation.
Re: (Score:2)
you could run chromeos on android, eventually you would like androids browser to do the native-code thing of chrome anyways. or you'd like to have android widgets and android apps on your chromeos.
chromeos is pointless as an os of it's own. everyone knows that, even the guys working on it.