alexkcd

Apple should migrate from x86 to LLVM IR. Then JIT down to native code upon program installation. That way they can switch the underlying architecture as much as they like.

I'm surprised they haven't adopted this scheme with iOS already when they deprecated GCC.

All modern C++ compilers support RVO, so there will be no copy given how this function is implemented. If by "safer" you mean "probably faster", then that's not true: http://cpp-next.com/archive/2009/08/want-speed-pass-by-value...

The author's version is more idiomatic modern C++, while your version is something you'd write for a decade old compiler.

Same here. It would be great to get end-to-end encryption, but I don't think that this is currently practical.

Some recent research [1] has shown that it's theoretically possible to delegate the ability to process your data, without giving away access to it. But from what I remember, in practice the computation becomes orders of magnitude slower than on the unencrypted counterpart.

[1] http://crypto.stanford.edu/craig/easy-fhe.pdf

My guess is that Apple asked Facebook not to use the same name as the built in camera, and Facebook complied to avoid damaging their renewed relationship.

Check out apigee.com if you want something more refined.

I keep hearing this argument. But physically traveling there is pretty stupid if you think about it. It's much simpler to set up a communication channel.

Sure it'll have a 50 year latency, but we could easily stream all of youtube (or the entire internet really) to them, and so could they. Assuming they're more advanced and their cameras capture the environment in spherical 3D, we could recreate what it's like to stand on their soil pretty accurately from home.

Besides just browsing their extranet would be amazing in itself.

There must be a different underlying issue there. Showing a keyboard view should have no performance implications on a web view. Similarly drawing text into a texture tile should not take "multiple seconds of delay".

Jonathan Blow (creator of Braid) has an interesting rant on social video games: http://www.youtube.com/watch?v=SqFu5O-oPmU

The gist being that games like Farmville are A/B tested to maximize addictiveness and profit, rather than maximizing fun.

I don't think it will matter if they do. The integration of Google+ with Google's other products is what will drive the adoption. It's basically impossible to avoid. I can imagine even tighter integration with Google's offerings down the road. Like accepting an invite to an event could automatically add it to your Google Calendar. Or allowing you to sync your contacts with your circles.

That said, I also don't think Facebook is going anywhere any time soon. But it'll certainly be interesting to see Facebook's first moves in response to G+.

They have a point. OpenGL was not designed with security in mind (same goes for Direct 3D). Prior to WebGL there wasn't really a need for security, since applications making use of OpenGL would typically be considered trusted.

Index buffers into vertex arrays, for example, are not bounds checked in OpenGL. This makes perfect sense in terms of efficiency, but can lead to code execution in adversarial settings. I'm sure there are many more cases where choices were made in favor of speed, and where security was simply not a concern.

Having said that, all these things can certainly be fixed. For example, Microsoft could add a security layer that does all the bounds checking prior to passing on the commands to the driver (so securing all the drivers is not necessary). Makes me wonder how Chrome or Safari handle this. Anyone know more?

Indeed. I write a lot of Objective-C code, and still drop into C++ for the CPU heavy tasks. Swapping out NS* containers for std::* alone gives a fairly high boost in performance.

All the C++ hate is blown way out of proportion. C++ is a great tool when you need performance. Tuning C++ isn't that difficult either. Contrary to what a commenter said above, steering clear of C++ at all costs is not what you should be doing. You should know when and how to use C++. It's useful more often than many people here seem to think. Especially if you develop for mobile devices.

That's how Apple's SDK works. Existing photos in the camera roll might be annotated with location information. So for security reasons 3rd party apps need location permission to access the camera roll.

SteadyCam does not collect any location information. We respect your privacy, the HAL 9000 icon notwithstanding ;)

Oh man, I had this "brilliant" idea to make SteadyCam free to try, by inserting a watermark in the demo mode and limiting recording time to 15 seconds. The full version can be unlocked via in-app purchase.

That was the theory, anyway. In practice this has created a lot of confusion as to whether the app is free or not (spoiler: it's not). I'm trying to fix that by making it more clear on startup that you're in demo mode.

If you guys have better suggestions, I'd love to hear them :)

Yup :)

Steve Jobs tried that a while back. Of course, Apple wasn't as large then as it is now.

Yes all my arguments apply to my hypothetical codec. Where did I imply otherwise?

If you want your codec to be adopted despite lack of hardware/software support, you really need to offer something worth the hassle. Notably reduced buffering wait times for consumers, and lower bandwidth costs and ease of distribution (encoder/decoder) for pirates would be such needs worth the hassle. WebM is worse in all these cases. Very few people care about royalties, so it's simply not enough to ask everyone to swap out all the hardware and other infrastructure for mostly ideological fluff.

You actually need to make a better codec. And so far there is nothing out there (H265 and VP9 don't have a usable encoder/decoder).

Actually, mp3 is widely used because that's what the pirates chose back in the dial up days, when a lossy codec met their needs perfectly. You might still remember a time when mp3 was not supported by many players.

H264 meets the pirates' needs perfectly now. It has the best quality per bit-rate out there. And pirates don't care about royalty fees.

"One of the most important properties of my media formats is it's accessiblility."

Great! H264 is what you want then. It's not only supported, but also hardware accelerated, on most devices out there. WebM isn't, and won't be for a long time.

"What business wouldn't pay a slight file-size penalty (to maintain the same quality) in order avoid being bound to some per-seat licensing agreement with all its associated administrative and reporting obligations?"

Every business that would rather pay royalty fees than for extra bandwidth required by a shitty codec. You probably also want the majority of your customers to actually be able to view your content. So there's also that "minor" inconvenience. But aside from that, what business wouldn't go the WebM route, right? :P

"Do the math."

Actually, I'll let you do it.

WebM is an inferior codec to h264. As much as I'd like a patent-free alternative, it's unlikely that consumers will be willing to take a step back in video compression/quality. The fact of the matter is that large companies can afford to pay royalties, and end users don't have to. There's very little incentive to move to something new, let alone inferior in quality and of dubious future.

Now imagine a patent-free codec came along that had substantially better quality per bit-rate and was at least as efficient as h264. You wouldn't need lobbying to move us over. The pirates would embrace it first, and everyone else would follow. At the end of the day, moving forward is the only way we know. Sadly, WebM is leading in the opposite direction.

"A single use of an obj-C number formatter..." [emphasis mine]. Carmack is a pretty smart guy, he wouldn't be using number formatters in an inner loop.

Anyway my point was that you can find fault in just about anything. But, you'll be much better off if you found out the strengths of each language instead, and used that to your advantage. Here's a guy that has this figured out: http://www.savoysoftware.com/blog/my-iphone-is-not-a-mac-pro...

We need fewer religious language BS articles like this one, especially from a guy who seems completely clueless about C++.

Wow, the author is pretty clueless about C++: "Objective-C users never call "dealloc" themselves; whereas C++ users have to call this all the time."

If you ever call delete in C++, you're doing it wrong. I have a large project where I never call new or delete even once. Whereas my Objective-C has plenty of release and retain calls.

Frankly, I'm tired of the endless C++ bashing. Yes, it's a complex language. Yes, it has bad parts that you shouldn't use. But it has strengths that make it ideal for certain high-performance applications. (And before anyone brings up C, profile qsort and std::sort and then shut up).

Use the right tool for the job, and stop being religious about language choice. If you look far enough, you'll find there's something to complain about in every language: http://twitter.com/#!/ID_AA_Carmack/status/28939697453