Absolutely true, but this is also possible with just about every other technology today. "Bad Apps" can report information about Beacons, GPS, or any other sensor on the phone they have access to.
I think the technology here is so deceptively simple and generic that it's hard to say what the true killer use case is yet. It's definitely unfortunate that the "ads" examples are the most prevalent. Despite that, I'm betting devs will find cool and novel uses for it.
These kind of experiences are entirely up to the app developer to implement properly in a way that's not annoying like you describe. It can be done in a way that is nice (i.e. not notifying over and over). Not saying they'll all do it right at first, or even for a while.
It's a tradeoff. Packing more data into the beacon would mean more spectrum used per beacon - also, changing what the beacons are saying is much harder than flipping a switch on a cloud server.
Also it's not required that you go talk to the internet after hearing a beacon - if you already knew what beacons to look for and what to do about them, you wouldn't need to use the internet at all to create "local notifications."
For region monitoring (typically used for the "notification" case) the limit of "fences" is indeed 20...it gets into a bit more detail about "what's a fence" [edit: most of the time you can assume one monitored beacon == one fence]. But for "ranging" meaning "what beacons with this UUID are around me", the system gives you a report of visible beacons every second with no (defined) upper limit.
It was surprisingly challenging to come up with just those two examples to be honest. I don't think we really know what the killer location-based notifications are going to be yet.
Wifi-Beacon interop is quite new; it turns out the Wifi network at Levi's is really dense so it does have insane coverage. Also the Beacons are surprisingly visible even without further interop tricks - you can see them across the stadium at times.
Absolutely ... this wasn't an entirely new "invention," although Apple's technique of cramming their metadata in the spec is definitely novel, although nonstandard.
I think the general source of frustration with Sparrow's acquisition is the feeling that something beautiful just got end-of-lifed. And of course that this is just the latest in a line of could-have-beens like PushPopPress, Tweetie, etc.
And I had a similar train of thought as the OP: "I wish Apple could make the App Store even more profitable, so we can have more great independent developers like Marco and TapTapTap that continue to make great apps without being gobbled up by large companies eager to put talent into unrelated areas."
I don't know if it's possible, and of course no one can fault Sparrow for cashing out. But there it is.
This. His writing was life-changing for me in many ways. Incredibly accessible, useful discussion of various human logic fallacies. Fundamental misattribution error FTW!
Ah ha, yes, you are correct - but packfiles combine multiple blobs together to benefit from additional compression that you couldn't achieve by compressing each individually.
Git actually starts compacting your object database and creating super-efficient delta-compressed packfiles after a bit. You can still throw object files in there afterwards though, and it doesn't change the basic principles of operation.
Part of it was that SVN was the last service running on a server I wanted to shut down. The other part was simply momentum. Github (and therefore Git) were too exciting to not want to be a part of. I didn't want to be left behind. That said, SVN was perfectly serviceable, though I don't imagine I'll ever use it again.