icodestuff

It would sure be useful if the author posted OpenRadar links for each of these bugs... s/he is filing bugs with Apple, right?

I think it largely depends on if the last two items in the list are a natural combination, either in the same category, or complementary things. The former is why you need the Oxford comma for "the strippers, JFK, and Stalin"; the latter is why you need an Oxford comma in "we brought the tent, bread, and butter".

Off-topic, but I like this version of the joke better:

There are two hard problems in Computer Science: cache invalidation, off-by-one errors, and cache invalidation.

Sure, but Netflix did "peer" with Verizon (read: put their servers on the Verizon network). At this point, anything happening is either Netflix's fault (for not buying enough bandwidth) or Verizon's fault (for having a congested internal network), and we don't have enough information to know which.

Could also be that the agreement had an anti-defamation clause, and Verizon was counting on that to avoid upgrading their internal network.

I think the second possibility is much more likely. If it was the first, they wouldn't have tipped their hand, given that the guardian staff would have been among those users.

I'm not generally in favor of government intervention, but it seems this is the perfect case for it - local governments granted Comcast regional monopolies, and they should now revoke them. The "captive eyeballs" concept sucks and will ruin the internet as fast as AT&T-style non-neutrality, exactly as we're seeing it play out.

I wonder if there are any architectures where the naive strlen performs better.

As of earlier this morning Amazon.com was also vulnerable. OkCupid is also on this list.

Apple Extended Keyboard, the "Enterprise" model, not the II. Sadly quite difficult to find them these days, as the II was more popular. Worse, I can't bring my AEK to work because the right arrow key stops working for a few months if I move it much.

> Performing the initial callback manually, avoiding the KVO initiated one, was shown to be a performance improvement under certain KVO configurations.

Please elaborate. I've been re-implementing KVO, and have not seen this. What configurations?

Also, adding a controller ivar/property is rather invasive, don't you think?

"WWDC 2004 Register early and save"

Ah, for the days when you didn't have to register in the first minute to have a chance of getting a ticket.

Looks like it's implemented similarly to MAKVONotificationCenter, except that it doesn't support observation on arrays/array indexes. And why does it need to manually call the shared controller's -observeVFK... when the Initial option is set? That should be called automatically by the KVO machinery. It's a bit concerning.

Also it seems like keeping track of the additional controller objects would be a PITA.

I believe they are suggesting that. The question is who picks up the tab. As long as it's not a publicly funded bailout, I can't say as I really care.

JP Morgan did it. So can Satoshi.

I had an Aiwa stereo/receiver several years ago that could tune the FM radio in 50kHz increments instead of 200kHz. Most stations were weaker 50kHz off, but a few were stronger. More interestingly, there were one or two stations I could only get on the even decimals, usually between two empty odds. Now I wonder if someone's transmitter was configured incorrectly, or whether it was an illegal broadcast.

Huh. I always figured it came from commercial front-loaders, which need a window so when at the laundromat you don't accidentally open someone else's washer.

So I read the actual publication[1], and it appears to be mostly a lot of conjecture, at best. The only actual risk assessment is in the appendix and matches the linked article. The 10% number cited by the article is the risk that this happens within 10 years using those numbers. However even the paper notes that the odds are time-invariant. This is quite unrealistic (which the paper fails to note) given that the geopolitical landscape has changed so much since the sample data used in the risk analysis. Instead we are asked to believe that US-Russian relations have not drastically changed since the sample data was taken. Indeed, "It also assumes that the ex- perience of the first 50 years of deterrence can be extended into the future." Given that the last sample point was 1984, this is, to put it mildly, ludicrous. It's more realistic to say that between 1945 and 1991 the risk of a Cuban Missile Crisis-type crisis causing a nuclear war was 6.5%33%10-50% per year, and since then it's been 0, than it is to say that (as of 2013) it's 3/(2013-1945)33%10-50% per year, let alone that it's .19-99% per year that the publication asserts.

Similarly, the author laments reduced public interest in disarmament because the perceived risk has gone down, but has done nothing at all to show that the perceived risk does not correlate with actual risk!

So what's the takeaway? It looks to me like the call for an in-depth risk analysis is warranted, but that the author is using sensational, cherry-picked, and unrealistic data to try to bolster support for it.

[1] http://www.nuclearrisk.org/paper.pdf

I disagree with a few points in this article, and can provide clarification on a few others. The clarifications first:

Bindings don't exist in Cocoa Touch because they're either slow (e.g. computed properties like @sum) because they're mostly stateless, or memory intensive because... well, dig into the internals of KVO sometime - there are a huge number of caches to try to keep things fast. It's not because KVO is a bad API. Heck, the KVO side of bindings is never exposed at all.

On the topic of infinite loops, yes, you have to be careful not to change an affecting property within an -observeValue... but it's hardly unknowable what changes will cause a KVO notification. Indeed, it's an isomorphic problem to breaking retain cycles, something every Obj-C programmer has to worry about every day, yes, even with ARC. The information is just stored in a different place, namely +keyPathsForValuesAffecting<Key> methods, rather than in property or ivar declarations. One can create a "weak" notification by removing oneself as an observer in the -observeValue, optionally adding oneself back at the end.

As for disagreements: KVO is not the old way. NSNotificationCenter and the delegate pattern predate KVO. Callback blocks don't, and indeed where possible I'd recommend all of the above over KVO, but it's hardly ancient, and certainly not "the old way". It's just a different way that allows you to watch for changes that doesn't require the designers of an API to have provided hooks for you to do so explicitly.

On its implicitness, I can't agree that it's any more implicit than delegates. The same criticism that you can't command-click in Xcode to follow the code flow applies. Same thing with NSNotifications for that matter. That's kind of the point. If it was all explicit, we wouldn't have the dynamism that all of these mechanisms provide.

Re: "An important thing to note is that KVO will throw an exception and crash our app if we try to remove the same observer twice." This is simply untrue. KVO will throw an exception and crash the app if you try to remove the same observance twice, but an observance is created each time you call -addObserver:.... That is, like retain and release, -addObserver: and -removeObserver: calls need to be balanced. Additionally, the author actually misses a part where KVO really is broken: "[Using a static context pointer per observation] helps to make sure that none of our super- or subclasses can deregister us from being an observer." doesn't actually work. Using -removeObserver:forKeyPath: will happily remove the first observance it comes across (the first that was registered, AFAICT, though this isn't documented), regardless of its context; it's not just a convenience method for -removeObserver:forKeyPath:context: that passes NULL for the last parameter.

Lastly, it seems quite silly to have a unique context for each object and key path per class. If they're going to unique the contexts, you don't need to check objects and key paths. Or, you only need one context per class, and then only if your inheritance tree does include multiple observing classes. On a related note, I think the complaint about having to call super if the superclass implements -observeValue... is ridiculous. This is how any method that might be implemented at multiple levels of an inheritance tree must be called. Same thing with a delegate whose superclass also conforms to that delegate protocol. Or -init. Or -dealloc. Or...

.

All that said, I still generally agree with the conclusions about when to use KVO, although is #3 is just a subset of #1, and I wouldn't have phrased it as the author did (see the first paragraph of disagreement). I'd also add #4: Use KVO when you need the old values as well as the new values of the objects, and/or need to be notified prior to the value changing. NSNotificationCenter and delegates can do the same thing, but at the cost of double the number of methods that need to be written, and you'll have to store the state yourself if you need the old value at the same time as the new value. That's a lot of code that gets abstracted away by KVO, particularly if you're observing multiple key paths on the same object and need all their old and new values. Code you don't have to write is code you don't have to debug.

Whether right-shift is arithmetic or logical is implementation-defined in C. The compiler (for obvious reasons) knows what hardware is available, and generally optimizes a divide by a power of two to a right-shift if arithmetic is available (as it is in most architectures), plus a check to see if the number is odd and negative (and to add 1 to the numerator if so). All of which is still faster than using the divide hardware.

I'm reading it, and I'm rereading it, and I'm just not seeing that. In fact, I see the author going to great pains to point out that there really are times you want to depend on the non-hoisted conditional behavior of C. This is a heads up, not a "OMG C is teh worst language EVAR!" rant, not even a subtle one.

Where do you get the idea that the author is ranting against strings in C? I don't see it.

Did we read the same article? I read no rant against `strlen`, but rather against naive programmers incorrectly assuming that it could/should be hoisted out by an optimizing compiler. There was not one word about being pained by an extra variable, rather that it's a clunky-but-correct solution.

And other languages have nothing to do with it; this is strictly a post about C, not a dynamic language, and not C++.

My guess is that the defendant covered his tracks well, so the DoJ couldn't come up with a parallel construction in this case, and felt, based on the wiretap, that this guy was dangerous enough to risk the whole program on.

I hope the challenge is successful, and that they can eventually use legal means to nail this guy later. :\

To be fair, there's no reason you couldn't share pins with a web app, as long as you're logged into iCloud on the web. Of course, once you have the map kit so iPhoto can display maps, well, why NOT make an app out of it?

What FUD. "Oh no, an application doesn't use the web! This must be an attack on the open web!" What a crock. Hyperbolic click-bait. The article does not fulfill the promises of the title, the byline is completely unsubstantiated, and the author's conclusions, such as they are, are completely unfounded. At most, the only correct points of the article are that A) Apple is attacking Google by having a Maps desktop app, B) a desktop app can be a better experience than a web app, and C) information may - and often more by design rather than by technical limitation - flow less freely through native apps than web apps.

From that to "Apple is making an attack on the open web, accelerating its walled garden strategy..." is an illogical leap that someone trying push an angle or sell ads could make.

I conducted interviews at Amazon. Sadly, most of the time that question was about measuring the ability of the candidate to do object-oriented design at all. Usually we didn't care what the final data model looked like, so long as it was logical (and much more often than not, it wasn't) - and we gave candidates every opportunity to explain and justify the classes they designed. But you are correct in that Amazon loves OO, and functional or other approaches wouldn't have been looked at favorably.

Huh. I can't remember the last time I didn't get either one key, or the second key was a valet key. That's _quite_ a nitpick.

They do have a lot of outside hiring.

The Developer to Developer-2 (in Amazon parlance, SDE-I to SDE-II) is VERY limited at Amazon as well. OLR doesn't just hold back managers, it holds back everyone, and it badly hurts their competitiveness in the labor market. After 18 months as an SDE-I there, I received a 4% raise, which was huge, for Amazon (though cost of living in my area went up substantially more during that time). But there was never a chance I was going to be promoted at that time, even though I had been very close to being hired as a II, and if I'd been interviewing then instead of being reviewed, I would have had the II title and compensation. So I left a couple months later (mostly for other reasons, but I won't pretend this wasn't a factor), and got that at my new job. Their loss.

If you're on a family plan, the marginal cost could still be cheaper. For my share of it, it's $10/mo plus however much data I choose (I'll stick with the grandfathered unlimited plan for $30).

That's not how it works. You pay last-dollar taxes on the money that would otherwise go into the 401k. You pay first-dollar taxes it when you withdraw at retirement. The first-dollar taxes are lower up to the tax bracket you'd otherwise be in if you didn't contribute to the 401k, unless you have additional sources of retirement income.

Who says they're simulating it accurately?