An individual site doing its own investigation and coming up with a conclusion that they don't know exactly what's going on (and even stating that their speculations don't fully make sense) is hardly a reason for people to get all upset. Withhold judgment until there's an actual story to judge.

Those food scraps in the landfill become permanent volume. Ever higher mounds. At one point, the Fresh Kills Landfill near where my folks live was the largest manmade object in the world. The small amount of attrition that occurs is into methane, which is a potent greenhouse gas. In contrast, composting breaks down the food into constituent organic components, some of which become soil enrichers and come of which are turned into CO2 (which is released back into the air from which it recently came and so isn't a net climate change contributor). What would you rather have? A big, permanent pile of stuff taking over your land and releasing undesirable gases or a much smaller static pile that gives off helpful-to-benign byproducts? Put another way in terms of purely animal matter, would you rather that all the dead creatures of the earth pile up until we're hip deep in them or that they break down naturally for their materials to be reused?

Pretty true for most cases such as typical bus mass transit, but large cities with subways can be an exception. The average New York MTA average consumption per passenger mile is 2000 BTU, which is less than 5500 BTU for a single-passenger car, 3,500 BTU for a car with average passenger load and even less than the 2,300 for typically-loaded car under a 35MPG CAFE standard.

iTunes Match does, yes. And tracks with under 256kbps that exist in the iTunes store are replaced with 256kbps AAC versions.

The original iPad racked up 100,000 preorders per day upon announcement, without any real preexisting tablet market to have stoked demand. The fact that it sold 1 million during the first month indicates that fulfilling these levels of orders for a complex product is tricky. Hopefully, since the Fire is based on the Playbook, they've been practicing production for a while.

Yes, but the first Intel Macs weren't released until January 2006. There was barely any time between the hardware being Windows compatible and Apple not only supporting it but actually supplying the enabling drivers. So, the "finally" sentiment is very misplaced, as it implies a long period of unfulfilled demand as someone dragged their feet.

This makes perfect sense to me. With Android, Amazon doesn't have top-to-bottom vertical integration and control, since they still rely on Google to do the core Android development and thus need to either be beholden to Google's timing or continue to work with forks of older versions. If they buy WebOS, they now employ all the programmers and can coordinate all the pieces that go into their tablet. Then could also further develop their EC2-assistance technologies and extend them beyond Silk to further enhance tablet performance. Buy making their forward-facing UI software completely custom, it's independent of Android from the customer point of view, especially customers buying the device for media and not for Android app compatibiility. This should make it easier to transplant the UI onto a different core OS without confusing customers who've already learned the UI. They could eventually exposure more of WebOS over time and offer a fully-controlled app store for it. I even wonder if they'd create a special build for $99 TouchPad firesale customers, allowing them to transform their tablets into large-screen Kindle Fires. In effect, HP would have subsidized putting Kindle software into many more Amazon-media-consuming hands.

Although I'm only one datapoint, my Optimum Boost (Cablevision) service north of NYC almost always hits the 50d/8u Mbps that I'm paying for ($15 over base service for the higher speeds). When I've had issues, they've always been catastrophic ones (no signal due to bad connector on the utility pole, etc.) rather than just slowdowns.

Not really. The equivalent would be if your power company charged a flat rate for unlimited electrical use, based on the tacit assumption that there were only so many gadgets and appliances that a regular house would ever run. Then, you go and install a huge cable from your house to your huge office park across the street in order for that park to take advantage of your house's unlimited power plan. The problem is all the assumptions either implied or in fine print. Companies shouldn't be allowed to offer unlimited service at a flat rate. Such things are untenable, business-wise, since networks can't handle infinite traffic. If a company means that you can use as much data as a given device can consume, that's what the plan should say. The restrictions against another device tapping into that plan's data allotment should be spelled out clearly in advance of a customer signing the contract. Better yet, offer a metered plan that is device agnostic and perhaps which has an escalating cost for the highest monthly data caps as needed to keep network congestion reasonable.

Even when you enforce official APIs for apps, the OS itself must of course use undocumented APIs. That's merely separation of user functions from central system functions. Apple isn't using private APIs in its apps sold through the app store but rather in the implementation of a new OS capability. iOS already has USB sync. Apple just implemented the means to cut the cord. This isn't something an app can do because a central principle of iOS apps is that they are sandboxed and see only their own data. This is what allows users to feel free to try any app without worry of ever corrupting the phone or data from another app. A sync app must obviously see beyond its own sandbox and is thus impossible. That's why Apple made it a central system service. Note that there is no concept of a system tweak in iOS. You can only buy apps, never any software to customize or modify the OS function itself. Perhaps Apple will one day create APIs to allow this, but the sandboxed app model is the only one right now. By the way, another reason many private APIs is because the developer, whether Microsoft or Apple, isn't prepared to lock them down or support them. They are subject to change as the functions they implement are refined and co-optimized with the rest of the OS.

If you ran the company, would you throw away the brand value of "i" just for the sake of being imaginative? When you here "i" anything, you know the product is Apple. Most companies would kill for that level of brand recognition.

As many have stated for days now to no avail, the iPhone consolidated.db log does not store and user location data. Even the patent indicates this. To understand this better, consider how both iOS and Android devices estimate user location when GPS is not available. They triangulate based on position relative to cell towers and wi-fi APs, which, in turn, requires the phone to know the location of these reference points. Since towers and APs don't transmit their own coordinates, phones need access to a position database. There are two ways this access can happen. The phone can either access the info over the internet, with all attendant delays, or it can maintain a local database and go off-phone only when there is no hit in this cache. But how can one keep this local database from becoming too large? Limit it to those cell towers that the user has connected with in the past, since those are the ones the user is more likely to be near in the future. This leads to a file on the phone containing location coordinates of towers and APs to which the phone has connected. Not user location data ... reference point data. And not in linear time, but only the most recent encounter with each reference point. In other words, the consolidated.db file. The Apple patent claims exactly this.

Actually, the iPhone file is a caching file. It retains one entry per cell tower to which it's been connected and overwrites that entry with updated location data (of the tower, not the triangulated location of the user) each time that tower is encountered. So, tracking the user is actually difficult within areas they commonly visit since only fresh data will exist. For places visited only once, that data may live in the cache much longer.

But this is all that it's doing. Any new connection to a tower triggers recording the latest best-guess location of that tower ... not the triangulated location of the user based on the tower or GPS. And, older info on any tower is overwritten by new coordinates and a new timestamp of a newer encounter. So, it's not a linear, complete history. The fact that towers appear only once in the file is apparent without having to quote a publication that I'm assuming you're referencing because they are regarded as pro Apple.

That's not the point at all. The existence of the log file has zero bearing on what Apple or a third party could do. After all, if the file didn't exist but Apple later chose to track users, they'd simply institute the logging at that time. The file only establishes that it's possible for a phone that knows the approximate location of towers to which it is connected (which we already know) is capable of writing this info into a log file (which we also already know).