Are we perfect? No. But we are advancing closer to the ideal expressed in our founding document.

"Humanity can generally be relied on to do the right thing, once all other avenues have been exhausted". - Churchill.

Werner von Braun orchestrated a surrender of his team to the US instead of the rapidly advancing Russian forces due to religious reasons

Citation needed? I'm sure he had plenty of good reasons. The Germans were very well aware of their likely fate at the hands of the Russians - they not only had a brutal reputation but the Germans knew that they felt justified in using that brutality in revenge. As the Red Army swept across eastern Germany, in some villages more people committed suicide than were left remaining afterwards. Thousands of women were raped. The Allied powers on the other hand were seen as the far "milder" enemy - in fact in the early stages of the war Hitler didn't even expect to have to fight the British and Americans, he expected a negotiated peace.

Von Braun was well aware of all of this and knew that if he was captured by the Russians, the worst he could expect was to be summarily shot. On the other hand the worst he could expect from the Allies was a fair trial. In the end he didn't even need to go through that.

I sell an app through the Mac app store. It's been fairly successful - certainly in terms of volume we would have struggled to match it if we'd only stuck with our own website as the sole means for a new customer to acquire the app. When Apple have helped us with promotion, we've seen sales skyrocket, at least for as long as they deign to put us on the front page or whatever.

But now we have an almost completely new version 2.0 ready to go, and the App Store has no provision for paid-for updates (all of our version 1 updates were free). Therefore we have to submit it as a brand-new product, which is really dumb, because it means all of our installed base of 1.0 users won't automatically get a notification that there is an update, and we can't build on any of our existing materials in the app store other than adding text to say "there's a new version over there". We have to start over from scratch, and it's a real cause for concern.

We can't offer quantity or educational discounts through the App Store either, which we've been frequently asked about.

I've also been on the receiving end of the sorts of developer-hostile treatment others have reported here, though on the whole it has been a mostly positive experience. The enforced sandboxing was exceedingly painful, and I definitely wouldn't want to go through that again, but having done it, it's an issue easily forgotten about. Apple eventually (in 10.9) included frameworks for getting media from other (i)apps which was the main thing we lost in the sandboxing, needing a hideous workaround.

What's annoying is that many of the issues pointed out in TFA are real, and have been a problem for a long time. Apple appear to have no interest in improving the store or canvassing developers about how it should evolve. The store staff appear to be a lawless disconnected bunch that don't seem to talk to other parts of the company, and seem arrogant and capricious. That may not be the case, but that's how it appears and so it's a problem they ought to be addressing.

So given that, the right thing is not to give them the password. Without it they cannot prove anything, however much pressure they apply. There may be the assumption that you have something to hide, but without proof, you're innocent, right?

As the crew of Apollo 1 sadly discovered, or at least the accident investigation discovered. In hindsight it certainly seemed a really, really bad idea to have a near-pure oxygen environment at 16psi.

A Mainair Blade or similar. Easy to fly, not ridiculously expensive, can fly it in and out of my backyard (paddock, actually), nice for fairweather fun flying. It's not a car, but the flying car will never happen unless they are fully autonomous, and even then they'll be a bad car and a bad aeroplane. The flying car isn't just "a car + an extra dimension", it's a whole different engineering space. Never happen.

Queue the many certifications...

The word you're looking for is 'cue', meaning 'to set up, schedule', not 'queue' which is a list of items or objects to be processed in order.

You don't need to use "all the retain and release calls". In fact, by default, they are not enabled. They're only required in legacy code, or if you really prefer to work that way (and believe it or not some do - it's actually not really very hard if you take the trouble to understand it properly - most people who get into trouble with manual retain/release/autorelease often haven't spent the half hour reading the relevant documentation, or the even-better explanation found in 3rd party books, e.g. Hillegasse).

If you do get into trouble, and we've all done it, no denying that, there are plenty of "obvious" ways to see the problem - such as the Instruments 'Leaks' tool or NSZombie. If you haven't come across these you should be shamed of yourself as an iOS developer.

And so, having missed all the advantages of Obj-C due to misunderstanding memory management, wilful ignorance or straightforward incompetence, you're moving to C++. The irony is, you have no mechanism for tracking memory allocations over time there, and you have to do everything yourself - there is nothing in the C++ runtime to help you. Some programmers do prefer writing their own solutions to perennial problems, because they can't understand others' solutions to those same problems. It sounds a little like what you're saying here - your company's programmers don't really 'get' Obj-C's memory management rules, find them "a bear" and so are moving to C++ where they'll get no help on that score at all, but hey, at least they can reinvent their own wheel and so understand how it works, square corners and all.

A lot of comments here saying how Obj-C is "ugly", and so forth. I wonder how many commenters are actually using it to any great extent, on a day-to-day basis, rather than have just looked at it out of curiosity for five minutes?

If you want to write an app now, Obj-C is the only sensible choice. Swift looks promising, but it's not ready. It's changing almost weekly and at the moment it's actually introducing bugs into the frameworks where none exist in Obj-C. If you want to live on the bleeding edge, go for Swift, but if you want to write an app, get it working and ship it out of the door, Obj-C is the only game in town today.

Once you get into Obj-C, it's a much more elegant language than it's usually given credit for anyway. Sure, it's old, but the runtime and compiler work put in in recent years makes up for many of its older roots. Manual memory management is not required, there is a dot syntax for properties and so on, so square brackets are not the only way to call getter/setter methods. As a pure superset of C99, it's easy for a C programmer to learn. It's also a small language. The real power lies in the frameworks, and that will take you far longer to learn than the language. Don't be put off by the superficial "ugliness" of Obj-C code, it isn't relevant. It's expressive and straightforward, and as a former C++ programmer, I also found it dramatically more productive when I first adopted it over a decade ago. It is possible to become fond of it, believe it or not. Whether the same eventually becomes true of Swift, only time will tell. Ignore the nay-sayers who have probably never actually used Obj-C in anger in their lives.

Obviously you've never had your circumstances suddenly change, for example lost your job unexpectedly, or had a close family member (or yourself) fall ill. I know it's therefore a big stretch of the imagination, but how about showing a little bit of compassion?

Lego is the building material as a whole, therefore it's already a collective noun. So there's no such thing as "a lego", it's "a lego brick", and by extension there's no such thing as Legos.

When the BBC opened 4 digital channels here in Oz on FoxTel, my assumption was that this is an intermediate move to establish the brand and also debug the distribution channels ahead of a time a few years away where everything is an "app" on whatever STB you choose, with a paid subscription model. Foxtel is only being used for now (I supposed) because that's where the technology is at and not everyone yet has an open-ish STB that can support arbitrary channel apps.

This latest shows that the BBC isn't doing this after all, which is a great shame, as it's surely the way TV is going to go (as long as governments have the balls to tell Murdoch to stuff his 80s distribution model up his arse). If there were a BBC "app" with a simple subscription model (in the manner of say, Apple TV) then the BBC would not give a shit who runs a VPN or how the content is accessed. They only have to ensure that the client has paid for the service. I'd go for that, it's a no brainer. Everyone wins - the BBC, the consumer, the box makers. Oh, Rupert doesn't, oh well, boo hoo hoo.

I just don't get it. The BBC is generally quite forward-looking and surely can see the way this is all going? If they truly can't, as this stupid comment seems to imply, then I really hope somebody gets their brain into gear over there soon.

...it's just another brick in the wall.

For some reason people aren't breaking out the hammers. It's as if they just don't care, or fail to understand the implications at least, of all this surveillance and monitoring.

I started out as a hardware designer, specialising in RF. I worked for a medium-sized company at first, but one that was quite important in the UK in its particular market, and I had no trouble getting free samples out of any supplier when I mentioned their name. Later, when I wanted to build stuff for myself without the clout of a larger company, I still found getting free samples was easy enough. The trick was, call them up and ask them to give you a quote to supply the chip with price breaks at 10, 100, 10,000 pieces. Then after they'd gone through that process, throw in a "by the way, any chance of a couple of free samples?" (I wouldn't bother with this charade for basic components, free samples were no problem, but for more expensive items they needed to think you were serious). This was in the 80s so cutting edge at that time meant chips such as the 68HC11 SoC - I even got a couple of free development boards out of Motorola for that one.

A company called CML used to produce codec chips for handling the digital modulation of a baseband signal using GPSK, etc. Getting samples out of them was sometimes tricky because these were highly specialised custom fabrications. But I still got a tube full of free samples out of them which I used in a university project - very much a one-off - using the same BS.

SCART was more common in other parts of the world

What other parts? Where are you from? If you include a relative reference, at least mention what it's relative TO. You know, the internet is worldwide, FFS.