There was no need for them to "band together," as Apple Pay allows each card issuer to individually choose how much verification to do.
Apple Pay is built on top of standardized front-end payment infrastructure, and competing systems can be (and are being) built on that infrastructure as well. It's analogous to being able to visit, say, either Google or Bing from the same computer; the world doesn't need to agree on a single standard search engine if multiple search engines can be accessed via the same front-end (in that case, the web browser and user's Internet connection), and in fact user choice is better enabled if it doesn't.
To be clear, the fraud here isn't in the technical implementation in Apple Pay, it's in the card verification procedures, which Apple deliberately leaves entirely up to banks. Each bank can do as much or as little verification as it wants, or even do different amounts of verification on a card-by-card basis if they like (based on a risk profile of a particular customer or whatever). So, bailing on Apple Pay isn't really in the cards here. Some banks clearly misjudged what the rate of fraud would be if they only did minimal card verification, but they can change that whenever they want to.
Literally every time there's some new bit of Mac malware, we see a chorus of predictions in the form of "This is it, now the floodgates are going to open!" This has been going on for years, and these predictions have all been wrong. There are a couple of a new threats a year, and there isn't actually any particular reason to believe we're on the cusp of a dramatic non-linear increase.
As for accessing Microsoft's online services... a huge fraction of the apps in the app store access various companies' online services. I'm not sure what you see being the problem there. The only real restriction Apple has with respect to this sort of thing is that if you provide a link to a web site to subscribe to a paid service or purchase paid content, you have to also sell that subscription/content via in-app purchasing (and give Apple its cut). But if you don't link, you don't have to do this, and you can still give your customers access to that subscription or content if they find your web site and purchase on their own.
It's true Apple probably wouldn't let Microsoft support scripting in Office for iPad. Apple allows developers to embed scripting engines now, but all the code they run has to be bundled in the app package so Apple can review it; apps can't load code later, which is what would be happening with scripts embedded in Office documents. But honestly, scripting is kind of an edge case. Yes, some organizations use it extensively, but realistically 99% of Office documents in the world make zero use of scripting functionality. Microsoft shipped Office 2008 for Mac without VBA, and while they did bring it back to the Mac in 2011, this clearly demonstrates they don't consider lack of scripting a release showstopper.
This is kind of the point of the linked article, actually. The business world built up this notion over a couple of decades that any device (or software alternative to Office) that didn't provide 100% compatibility and 100% of the feature set was useless. The widespread adoption of iOS/Android devices that don't run Office has provided a significant amount of first-hand experience that this isn't true -- that a lot of routine business tasks work just fine without Office. This realization is dangerous to Microsoft.
Yeah, this article badly misunderstands what iCloud is for.
First, it's a backup service for iOS devices that eliminates the need to sync them with with a computer, effectively untethering iOS devices. And yes, if an app stores PDFs, images, movies, whatever, within its data store, iCloud will back them up. Once your iOS device is backed up to iCloud, if you happen to drop it in the ocean, you can go buy a new one, sync it to iCloud, and all of your stuff (with the exception of non-iTunes music if you don't have the $25/year iTunes Match) will simply come back.
Geeks like us have trouble understanding the value of a service like this to average end users, but it's huge. Most consumers, to this day, still don't have backups of any kind, and virtually none have off-site backups. Apple reportedly had lots of people coming into Apple stores who hadn't synced their iOS devices since first setting them up, and would therefore lose considerable amounts of data if device replacement was required. iCloud simply makes these problems go away for people. It makes off-site backups simply happen by default, rather than requiring the user to understand the importance of them and go out of his/her way to make them happen.
Secondly, iCloud a seamless sync service designed to be integrated into apps. With an iCloud-enabled version of Pages or another iWork apps, you can be working on a document on your Mac, grab your iPad and run out the door, and keep working on that document there -- even if you didn't explicitly save your most recent changes. You can add a reminder in the new Reminders app on your iPad, and seconds later it will also show up in the equivalent app on your iPhone. You can start playing a game on your iPhone, and your progress can be seamlessly synced to your iPad, so you can keep playing there from exactly where you left off. Third-party developers can add features like this to their apps using a trivially simple API, with no need to own/rent their own cloud infrastructure or write a single line of server-side code.
Comparing iCloud to Dropbox doesn't really make a ton of sense. The services are designed to do very different things. The only real overlap is in the instance of things like syncing iWork documents... but even there, the approach is conceptually different. Dropbox is "a folder that syncs" iCloud is a data sync service intended to be integrated by developers.
Describing iCloud as "underwhelming" is effectively a compliment to Apple. It's supposed to be invisible. A decade from now, non-savvy users will simply take it for granted that their data is magically propagated between their devices, and it won't even occur to them to think about the mechanism through which this occurs.
For that matter, do we really need another round of people who don't like company X attacking company X for filing a patent on something they object to, pretending not to understand that tech companies never implement 90% of what they patent? Seriously, remember those articles about Apple patenting OS-level advertising that locked people out of their computers until they watched it? Seen any Macs or iOS devices doing that lately?
$1/watt is a sensible target price for PV panels. Installed systems, with mounting hardware, inverters, etc. will obviously cost more. Also, this system generates power throughout a larger fraction of the day, and a bunch of mirrors pointed at a big concrete tower probably have a useful service life many times as long as PV panels -- replace the turbines and possibly some tanks and pipes every now and then, and it's hard to see why this system couldn't last practically forever.
The difference between this accident and Chernobyl, they say, is that at Chernobyl a huge fire released large amounts of many radioactive materials, including fuel particles, in smoke. At Fukushima Daiichi, only the volatile elements, such as iodine and caesium, are bubbling off the damaged fuel.
That's a really important difference. It means the total release of radioactive material is far smaller. And the iodine, at least, is a lot less scary than the sort of stuff you get from fuel particles -- it has a half-life of only 8 days, so there's no real long-term environmental threat from that. (The cesium is rather worse -- half life of ~30 years.)
Fortunately, you don't have to bother reading past the first page, because it contains a dead giveaway that the article is essentially just shallow filler content designed not to offend anyone.
The iPad, with 60,000 + tablet-optimied apps, scores a nine for application support, while the Xoom, with a handful of tablet-optimized apps, scores an 8? Seriously? And all the arbitrarily chosen criteria are equally weighted? Meaningless nonsense.
The OS has built-in parental controls that apply to Safari. And to the Mac App Store. Had Opera not been given a 17+ rating, a parent could have set restrictions on Safari, set the Mac App Store not to allow installation of apps allowing access to adult content... and little Johnny could have still installed Opera and gotten himself unrestricted web access.
The idea that this is some plot by Apple to undermine Opera is absurd. Apple gives the same 17+ rating to any app that allows access to sufficiently unrestricted Internet content, including things like Wikipedia apps, which last time I checked Apple wasn't competing with.
Do some people buy MacBook Pros as status symbols? I'm sure they do. But some of us work in pro video. There are people who legitimately need high-end laptops, and a lot of them, because of Apple's strength in the creative pro market, use Macs.
With quad core processors and tons of external bandwidth over Thunderbolt, these new MBPs are game changing for pro video, or will be once a couple of TB devices hit the market. For instance, TB is fast enough to hook up both a RAID capable of handling multiple 1080p video streams and a video interface capable of doing uncompressed HD output to a broadcast monitor. This makes these pretty much the first laptops ever (outside of crazy hack jobs, maybe) that can plausibly replace towers for working with uncompressed HD video formats. That's pretty handy.
I think the point he's making is that if there's no standards-based mechanism for delivering DRM-protected video, content providers will simply keep using Flash to do it, reducing interoperability and leading to inferior user experience.
Which is a fair point.
Also note that the GPL isn't compatible with the iOS store due to restrictions placed on what the user can do with the software (can't copy the binaries and send to a friend).
Yes, you can. The binary is synced to your computer, from where you can copy it anywhere you like. It's true that the binary is linked to a specific iTunes account, but first off, GPL doesn't actually say you have to be able to execute a binary on any given device (all sorts of embedded systems would run afoul of the GPL if it did), and secondly, there's technically no limit to the number of iOS devices a purchased app can be installed on, so long as they're all authorized on the iTunes account that purchased it. (And an iOS device can be authorized on multiple iOS accounts simultaneously as well -- I think up to five.)