Maybe I'm alone here, but I honestly think this is a really good idea. I personally own a Windows 8 tablet as well as an android tablet and android smartphone and have found myself thinking on several occasions how much more useful the Win8 system would be if I could run Android on it as well.

I agree with other posters here that Android 4.x as it exists today isn't a good desktop OS... but honestly it would not take a ton of extra work to make a desktop friendly interface for it. The Android 4.x UI changes slightly depending on if the device is a smartphone or a tablet, why couldn't it have a "desktop" UI mode?

Honestly all Google has to do it get rid of Chrome OS as a separate entity, merge the desktop functionality of Chrome OS into Android while keeping the ability to use 3rd party software sources and call it Android 5.0. If Google makes such a product honestly I think it would be devastating to Microsoft as well as the Windows ecosystem.

If that's the criteria then its pretty much impossible for these laptops to meet it. That coreboot firmware is going to carry microcode updates for the CPU which are encrypted and signed by Intel so it would be impossible to replace them with free microcode. I bet the EC and the bluetooth and the hard disk controller are still running the original binary blobs too.

But don't tell RMS, he hasn't realized how much embedded firmware has proliferated in the modern PC compared to the 1990's when the LinuxBIOS (now coreboot) project started.

I think your LED knowledge is a bit dated. I personally own a very nice 1680 lumen 100w equivalent LED bulb:

see here

I'm just as happy as very other Linux user out there about the Intel drivers starting to get competitive... but I'm pretty sure the reason Intel's management is dropping big bucks on Linux graphics driver development is Andriod not SteamOS. SteamOS is probably a pleasant nice to have they they get without any large amount of extra investment.

Yup absolutely. Bitcoin isn't money, its more like a virtual commodity that people speculate on.

Lets look at the 3 properties of money and see how Bitcoin stacks up:

• A unit of account
• A store of value
• A medium of exchange

For #1, very few banks offer BTC checking accounts and when I go to any store near my house, all the goods I see there are priced in USD, not BTC. So BTC doesn't meet #1. Next lets look at #2, BTC fluctuates in value so rapidly that as you point out, it can't be used as a reliable mechanism for storing wealth. Finally for #3, there are some very specific online markets where very specific goods can be bought with BTC, but overall BTC doesn't really cut it. Lets look at my basic human needs: food, water, shelter. When I buy food at the grocery store, they expect me to pay them in USD. The water company expects my water bill to be paid in USD. When I bought my house, the transaction was conducted in USD.

If the USD price of red apples goes up by 50% next time I go shopping, I can reliably use that as a signal that red apples are in short supply right now and opt to buy yellow ones instead. If the price of red apples goes up by 50% in BTC, I would think it was a reflection on BTC exchange rates, I wouldn't see it as a signal of a red apple shortage.

I know I'm gonna be down-voted, but seriously BTC isn't money. And it never will be until its possible to do the things I describe above using it.

Actually check out Haswell's die configuration, the integrated graphics takes up about 2 times more area than the L3 cache. Also, look at how dense the transistors are in the GPU area, looks as dense or maybe even more dense than the cache. It wouldn't surprise me if graphics are a source of manufacturing problems in addition to L3 at this point.

Actually it appears that Intel removed the A20 line starting with Haswell.

Check out page 271 of the Intel System Programmers Manual Vol. 3A from June 2013. Notice the following excerpt: "The functionality of A20M# is used primarily by older operating systems and not used by modern operating systems. On newer Intel 64 processors, A20M# may be absent."

Now check out page 368 from the May 2011 version of that same document. In the same paragraph, the statement above is not present.

From this, we can infer that between May 2011 and June 2013 some new Intel chip dropped support for A20M#. In that timeframe, Ivybridge and Haswell are the only 2 chips that were released. Since Ivybridge is the same architecture as SandyBridge just manufactured on 22nm and we know that SandyBridge did have A20M#, I think its a fairly safe assumption that Haswell is the first x86 chip that has _finally_ done away with A20M#. That said, it would be nice if Intel actually said in the manual which chip was the first to remove it.

Does someone have a new Haswell system that they can do a quick DOS ASM program on to verify this? Even better, if someone has an Ivybridge system we can narrow this down.

As someone who has written and maintained complex commercial Windows software recently I can say that since Windows Vista the backwards compatibility story with Windows is not nearly as good as it used to be. Pretty much every new version of Windows since then has brought some serious changes in behavior.

With Vista the big breaking change was of course UAC which I'm sure everyone here knows about.

Windows 7 on the surface did not introduce a large amount of breaking changes when compared to Windows Vista. Probably the biggest breaking change was the need to use a new GUID in your application manifest if you didn't want your customers to be annoyed by the "Program Compatibility Assistant."

However, Win7 was the first version where 64 bit OS installations really took off. Depending on the application, making an existing 32 bit Windows application work on a 64 bit OS can be a lot of work. I'm not talking about recompiling to 64 bit here either. There are a fair number of breaking changes with regard to COM objects, esp. if you are mixing .NET and native code anywhere.

Win8 brings us Metro/Modern apps which most Windows developers have been ignoring because of lack of backwards compatibility with Win7 and a strict sandbox that makes it almost impossible to write anything other than silly casual games (Cut the Rope/Angry Birds) or an "app" that does nothing more than access a website which you could access with your web browser anyway ("Facebook app"/"Netflix app".)

For the people who write applications (not "apps") Windows 8 has a couple things that make life difficult as well. One of the big ones is how difficult it is to perform an automated installation of .NET 3.5. For those doing driver development, the addition of connected standby to Win8 has really complicated life as well.

All this adds up ever since Vista we have always had to make changes to our software to support a new OS release, wierdly enough binary compatibility between OS releases on Windows is actually becoming comparable to a typical Linux distribution. With the release cadence of Windows becoming quicker ongoing support and maintenance for commercial Windows software is quickly becoming as expensive as commercial Linux software support.

I live in Portland, OR area and got this message at about 11pm that day. I think that puts the radius more around 1000 miles. My carrier is Sprint.

I starting to fell like a broken record here but seriously Slashdot, I would have thought that this Myth that x86 ISA somehow makes it impossible to build a low power part would be dead by now. ARM is a rather complex instruction set now that they have added SIMD and floating point support. If you look at the number of op-codes it has versus x86 they are roughly equal. Both ISAs have variable length instructions (all recent ARM designs support THUMB) so the decode logic complexity is actually pretty comparable. Also much of the decode logic is implemented in software via microcode on both ISAs.

There is nothing magical about ARM that makes it lower power. The real reason why x86 implementations are so much hotter is because designers of x86 processors have been targeting high compute performance for decades, whereas ARM has been targeting low power for decades. A quick look at Medfield benchmarks show that it is comparable in performance to ARM processors that were current when it was released. Medfield is ~4W active TDP... same as a Exynos 5 Dual ARM CPU. From what we have seen from Merrifield/Bay Trail/Haswell the next gen x86 parts are continuing along this trend.

We already have that in the UNIX world... its called Python with the dbus-python package.

ISA is pretty much completely abstracted that this point.

It would take almost zero actual silicon modification to take a Cortex A-15, switch out the microcode and have a x86 processor. You might have to add some new features to the instruction decoder logic but that's it. You wouldn't sell such a chip until after you optimize the A-15 design to efficiently execute x86 instead of ARM of course :)

Same thing on the Intel side. They could take an Ivybridge chip, write some new microcode and poof, its an ARM chip.

In essence, ISA really doesn't have much impact on power vs. performance anymore, its essentially the "API" that sits on top of the actual processor. What DOES matter is the chip design itself, and the process technology. ARM has spent 20 years optimizing their design for power, whereas Intel has spent 20 years optimizing their design for speed.

Now that the two markets are starting to overlap, Intel's designers are optimizing for power, and ARM's designers are optimizing for speed. The big question is which company is going succeed in the other company's home market first?

Seriously, lets stop pretending that the current state of affairs has anything to do with ISA. /. is acting like a bunch of old techies that remember the CISC vs. RISC war and want a rematch.

MSFT's net income for 2012 is 26.6% lower than it was in 2011. Subscription Office is about 1 thing, bringing the income numbers back up.

Office 2010's home and student edition was $140, which licensed 3 PCs, and gave you the latest version for about 3 years. That works out to $46/year assuming you upgrade (which you don't have to do). Now they want $100/year with forced upgrades. This is for software that does the same thing it did 3 years ago.

Unfortunately this article lacks detail, it seems that Bernstein Research considers Intel's latest smartphone designs to be as energy efficient as competitors. Intel's latest smartphone chip is Medfield, which is 32nm. Unfortunately the article does not say what chips they compared... but it would be surprising if they didn't include the Qualcomm (Snapdragon S4 @ 28nm node) in their comparison. So we at least have some indirect evidence that even when they are at the same technology node, Intel's design is still close to ARM's. It will be interesting to see what Silvermont (22 nm) brings in 2013, at which point Intel SoCs will have LTE capability (instead of 3G GSM only) as well as Ivybridge graphics (instead of PowerVR), and they will be Quad-core. The smaller technology node paired with the new design features is probably going to yield an awesome smartphone/tablet platform.

Actually there was a bit of a fire sale on the Kin.

The Kin ONE went from $50 to $30 after a month. The Kin TWO went from $100 to $50 at the same time. The devices where then discontinued shortly after.

Verizon then sent the remaining unsold units back to Microsoft. After a year, that same inventory of unsold devices emerged with a firmware update that turned them into feature phones, named the Kin ONEm and the Kin TWOm.