The only problem I have with BitCoin at the moment is that it isn't something you want to hold on to.
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
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
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 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.
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.
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.
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.
Remember that Microsoft is shipping Windows RT with Office 2010 included... as in the DESKTOP version of Office running in the "Desktop app"! Windows RT is truly the complete Windows 8 stack from top to bottom with Win32 and everything else. The big difference is that Windows RT will only run code that is signed by Microsoft. As Mozilla has pointed out to quite a bit of fanfare Microsoft refuses to sign any 3rd party ARM desktop application.
Windows RT has been intentionally nerfed in the name of boosting Metro application development. Why you ask? Because Microsoft wants to leverage their dominant position in the PC market to create an ecosystem of applications for Windows Phone and the upcoming Xbox.
Have you noticed that they have gone to painstaking lengths to make is so Metro applications that use the WinRT API cannot access the win32 API or the full featured preemptive multitasking OS which WinRT is implemented on top of? Check out the WinRT API reference sometime, it gives you access to a very limited subset of what the full operating system can do. This is intentional, Metro applications are designed to be boxed in to only what Windows Phone 8 supports. Also, all Metro applications must be distributed by Microsoft's app store. How much you want to bet that once Windows Phone 8 comes out Microsoft suddenly announces that all your Metro apps for Windows 8 will run be instantly be available for download and use on Windows Phone 8 via the Microsoft app store?
Microsoft is up to the same tricks as usual. Trying to leverage their core Windows/Office monopoly to gain a dominant position in emerging market segments.