sern

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).

Cool, maybe now it'll be possible to obtain Atmel chips in quantity without ridiculous lead times.

Censored manual for the Exynos 5 SoC: http://www.arndaleboard.org/wiki/downloads/supports/Samsung_...

Paranoia, maybe? But yeah, it's rather pointless. Even more so since GPS vendors have access to the algorithm.

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.

The offset is still there on ditu.google.cn, it's just that they've also munged the satellite imagery to have the same offset.

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.

This is incorrect. https encrypts everything.

Here's how Ceefax used to be used for computer programs: https://www.youtube.com/watch?v=ctxZWEVJ1S0

Not particularly - ARM instruction encoding is rather distinct. Repeating "always" values of the ARM condition field really stand out.

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.

The comment I was referring to is under this G+ post: https://plus.google.com/105051985738280261832/posts/intiB73F...

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!)

No CDN caches content for that long, even if the origin tells them to. (Services like Akamai's NetStorage excluded, which Facebook most likely does not use.) It's quite obvious that Facebook is actually keeping the images on their origin servers long after they have been deleted.

The purpose specification principle of the OECD Privacy Guidelines (which all substantial privacy laws are based on - EU, NZ, HK, etc.* ) says this:

"Finally, when data no longer serve a purpose, and if it is practicable, it may be necessary to have them destroyed (erased) or given an anonymous form. The reason is that control over data may be lost when data are no longer of interest; this may lead to risks of theft, unauthorised copying or the like."

Keeping an image URL online three years after it was requested to be deleted almost certainly counts as keeping personal data for longer than is necessary. When you upload a photo, it is usually for the purpose of sharing (as the case may be). When you decide to stop sharing, the data no longer serves that purpose and hence should be removed as soon as practicable.

* The US and Australia notably have not implemented the OECD guidelines.

I've never been able to take them seriously with Comic Sans in their logo.

The BBC Micro was actually quite expensive compared to the other micros of the time. (I don't think the IBM PC was ever considered a "micro", and other micros were probably more capable anyway.) If I remember correctly, the goal was not to produce a design that would compete mostly on cost but rather one that was British and would do the flashy stuff the BBC wanted to show on their computing series.

I agree that the Raspberry Pi will be revolutionary, not because it will rejuvenate computer science teaching, but simply rather because it's a cheap computer.

They absolutely don't need special hardware to start programming.

I'm sure I'm not alone in saying that my first exposure to coding was when I typed "10 PRINT BUTT 20 GOTO 10" into BBC BASIC. I didn't need anything more than the computer I had at school. The modern-day equivalent - typing "python" into the terminal - isn't much different, and still a lot easier and cheaper than getting something to run on an external Linux board.

The community can't maintain the patches, thanks to Broadcom's policy of not releasing documentation unless you commit to ordering a hundred trillion parts or are employed by them (as the Raspberry Pi folks are).

If the point of this thing is to promote computer science education, then it's already dead. Remember, not everything happens in userspace. For example, there are advanced operating systems courses out there that are focused very closely on the low-level side or are based on non-GPL-compatible operating systems where they can't simply lift stuff out of Linux.

It's nobody's loss but Broadcom's: the educators will go for platforms like BeagleBone instead (which, although more than double the price, is still cheap), the students will have the benefit of well-documented hardware, and TI will be happy that many of those students who grow up to work in the embedded space will be specifying TI (rather than Broadcom) SoCs.

You can fetch web pages and you'll appear as coming from a Google IP, but your user agent header will contain "AppEngine-Google".

Not to mention that chips are already 3D with multiple metal layers.

Nevertheless, it's still possible to jam (see LightSquared). I actually think this is how Iran did it.

The key management system (SAASM) indeed uses RSA, but not the GPS itself.