Wear-leveling with SSDs isn't about reliability, more about longevity because a specific bit (really page) on a chip can only be rewritten so many times. Though once that point is hit, the data is still readable, just not writeable. Not really the same scenario as the head of a HDD crashing, making data-recovery far more laborious and expensive.

On a 4-bay NAS box, there aren't enough slots to have a SSD acting as a cache unless you want to give up one of your very valuable bays.

It's new to desktops. The idea came from Windows Phone, much like Notification Center.

Actually, it's not. AppNap enables the OS to wake up and have apps refresh their state (enabling more functionality). Battery Saver on the other hand clamps down on apps which periodically refresh when battery is low because a dead battery is useless to the consumer.

Depends on your goals, really. I think a big pitfall most people think is that the goal is to learn a language, when you really should be aiming to learn confidently learn as many as possible. You'll soon start to see how similar they are, and it becomes a lot easier to pick up.

The hard part actually isn't learning a language, but a framework. Frameworks are very platform specific, concepts are less reusable. And because Cocoa Touch is so intimately designed around Objective-C, even if you chose to learn Swift first, you'll need to know Objective-C anyway because of a) the amount of code/books/resources that exists on the internet in Obj-C vs Swift and b) a solution to your problem may only be written in Objective-C in a StackOverflow search result.

As for skipping academic CS, at some point you need to learn the stuff that almost every CS grad is expected to know at some level (data structures/algorithms, operating systems I & II, algorithm complexity (aka Big O notation), software design, etc...) not so much because they'll be explicitly required of you, but as you build larger and more complex apps, without them, code readability, maintainability, and performance are going to go to total shit. Granted, there are some, heck many, CS grads who somehow evade actually knowing this stuff, and things don't turn out so great for the code they write in the end.

My advice, tackle building an iOS app with a goal in mind, written in Objective-C due to the sheer number of resources out there, then expand from there.

You have yet to move into your house. Stop making excuses and run Ethernet. Even if it isn't an in-wall installation (though I absolutely highly recommend it, it *will* add value to your house), since you have no furniture to move, run cords along baseboards and do it the right way so any future home owners won't think you did a crappy job. Man/woman up and get it done.

Ditto. Because learning the framework takes a LOT longer than learning the language and the fact that the framework was designed with Objective-C in mind, it is foolish to think that you will be able to write a pure Swift iOS app without knowing Objective-C anyway because there isn't enough Swift material out there for Google to find to solve your problems. And unless you *really* enjoy solving those problems on your own, you'd need to convert an Objective-C solution to a Swift one on your own, at which point you are basically learning both languages anyway. So I would say all new iOS developers need to learn Objective-C because writing a Swift-only app would be too painful otherwise. This all changes when The Big Nerd Ranch puts out a Swift book, but there's no indication that is anytime soon.

It's pretty simple. Since this is Google, the less time waiting for webpages or video to load, the more pages you visit and the more ads you see/watch.

It wasn't that surprising that AMD was king around 2003-2004, the problem was that Intel was playing very dirty, signing deals with OEMs like Dell to specifically NOT use AMD chips. The fines Intel got from the EU are never going to do as much to help AMD as actually gaining more profits during that period (and who knows, they may not have sold their mobile Radeon group to Qualcomm in an effort to raise cash). It's the domino effect of unknowns that hurts the most.

Are we assuming perfect world or what the average enthusiast might have? Because I'd rather shoot video on a dSLR which has far better optics and real physical zoom than a smartphone that has to cram everything into 7mm or less of space.

The Xbox One doesn't use GDDR5 but DDR3 memory with 32MB eSRAM. They made the decision early on to have 8GB of RAM (regardless of type) before they knew it would be feasible to have 8GB GDDR5 memory at an easily attainable cost.

Non-Google certified devices cannot legally access Google services via their proprietary apps (Gmail, Maps, YouTube, etc...).

It is one of the highest bins of the Tegra 3 line, clocked at 1.7Ghz. Most Tegra SoC variants are 1.3Ghz or 1.4Ghz because they have to worry about battery life.

The raw part cost of a smartphone SoC is a tiny portion of the bill of materials (BOM), maybe 10-15%. CPU is maybe $30 at the very high end? So for a box like the OUYA where the CPU is probably the biggest cost and they don't have to worry about a display, camera, battery, cellular radios, or massive amounts of storage, they probably could have sprung for a Snapdragon 600 or Tegra 4. Only thing is it would have delayed the product by 6 months since those chips are in high demand from smartphone OEMs. Take a look at this cost breakdown analysis of the GS4: http://www.isuppli.com/Teardowns/News/Pages/Samsung-Galaxy-S4-Carries-236-Bill-of-Materials-IHS-iSuppli-Virtual-Teardown-Reveals.aspx $236 worth of parts selling for $699 just shows you how things are roughly priced (granted, MSRP - BOM != profit, but Samsung is in a pretty good position). Also you'll learn the biggest conspiracy of smartphones ever: it does NOT cost $100 to go from 16GB NAND to 32GB, or 32->64, or 64->128.

Does anything besides Direct3D change with new versions anymore? It's not as if there are groundbreaking developments in XInput or DirectSound, and things like DirectShow have been depreciated for other Windows methods.