I think a better reason than "not wanting to play fair" is that the Apple implementation preserves the correct operation of the mic even while the remote is being pressed. Apple does it using a custom chip within the remote that superimposes an ultrasonic tone on the mic signal which can be cleanly filtered out, whereas resistor-based signalling works by shorting the mic signal to ground which either mutes or attenuates the mic (depending on the specific button and resistance involved).
Not quite the same thing, although they do have some similarities.
The Selective Availability "feature" of GPS worked by fuzzing the time readings output by the GPS satellites. The fuzz was time-varying but only changed every few seconds. Because it affected nearby receivers with similar amounts of error, if you had access to two receivers in the same area you could quite accurately measure their positions relative to each other.
The Chinese map obfuscation scheme is basically a secret map projection (it's not a constant offset, it varies over locations). GPS coordinates go into a black box and out come obfuscated coordinates, which you then use to plot on the map. Because there wouldn't be much point to GPS receivers that constantly show your location on the wrong point on the map, receivers sold in China actually incorporate the algorithm, and it probably wouldn't be too difficult to reverse engineer.
Interestingly, the Retina MBP has a combo Ethernet MAC/PHY + memory card reader chip of which they're only using the latter function. I would guess that either the decision to drop the Ethernet port was made pretty late in the process or the board designers were kept in the dark about the mechanical design until it was too late to pick a different part.
Also, a PCI-E lane actually is 4 pins :)
Edit: reply to dead - standalone memory card reader ICs are standard components. The USB SD ICs they used in earlier models would have been easier to route (than the PCI-E combo chip) and probably cheaper.
Proposals to fragment the Internet generally do not go down well, for obvious reasons.
The proposal is needlessly complicated, notwithstanding the poor quality of writing. The authors' rationale is to "realize autonomy", yet AIP suffixes are globally namespaced and still need IANA assignment, which is really no different to the current situation in relation to TLDs. It breaks backwards compatibility when applications need to cross AIP networks and also introduces the issue of conflicting AIP network-internal names. The authors make no attempt to discuss these obvious issues or any others, and also blindly wave off security considerations, saying "there is no additional security requirement".
Also, the authors are on Yahoo/QQ free webmail addresses, which isn't very professional.
It's not an RFC, it's an Internet Draft (which anyone can submit without review), and anyway it's offensive and incoherent enough that nobody will take it seriously, and it certainly won't make it as an actual RFC.
Yes, this is actually what they meant by "no glass layer".
The integrated display isn't really a miracle of engineering. In my opinion it's more a miracle of business that they convinced their display manufacturer to make the retina display modules in the shape of the MBP's display assembly. This sort of thing has actually shown up in smartphones for a while but this is the first time we've seen it in a notebook computer.
No, it's true. The possible geometry of visible GPS satellites at any given moment (namely that they're all above you and none are below) means that the vertical error is pretty bad in comparison to the horizontal error.
The current version of Xcode, released yesterday (two weeks prior to the sandboxing deadline), contains no code signing entitlements and hence is not sandboxed.
I don't think it's helpful to refer to VHDL as "not programming". It is programming, just in an inherently parallel, declarative fashion rather than an imperative one. My favourite metaphor for programming in an HDL is to think of it as building a computer or writing a program using expressions in a spreadsheet.
Look - as I said in my other comment, the issue isn't that it uses a tonne of memory. The stock browser does so too. The issue is that it is using that memory in such a way that it is evicted too late. The app is multi-process, but they're putting background services in the wrong process - they run in the main process that you'd expect to be heavy on memory usage. So instead of the memory-heavy UI stuff being evicted shortly after the UI goes away, it is evicted after all other background (multitasking) processes - including the launcher - have also gone away.
Note that my screenshot shows the active (i.e., not background processes that can be thrown away at any time) section of the running processes screen.
I should have qualified my statement by mentioning that the Chrome app process runs a couple of background services - this causes it to be killed for low memory after normal background processes (the actual behaviour is a little more complex than that, but that's the gist of it), which could potentially impact the performance of multitasking. The proper thing to do is to run background services in a separate process from the UI or whatever uses the most memory so that the latter can be evicted more quickly.
I stand by my assertion that optimising for memory isn't a priority at Google. An Android engineer poignantly put it (sorry, can't remember who) when they bragged on G+ that Android 4.0.3 was the first time since Gingerbread that they'd run the OS on a <1G RAM device (namely Nexus S). Then again, as an actual embedded engineer (none of this gigs of RAM crap!), all I care about is memory usage...
And in typical Google fashion, they have assumed that devices have an infinite amount of memory: https://imgur.com/zkh7C (this is with the app in the background!)