No, it is not clear. What is clear is that every other person who has commented besides you and him feel the same way that I do. I suggest that you learn proper English grammar.That is clearly not what he meant, and your argument is flawed. The first half of the second sentence is linked with the first sentence, but the second half is not.
[doublepost=1484351111][/doublepost]
To be fair, the menu is not at all hidden. It's actually fairly visible under the Develop menu, which is also fairly visible. However, I take issue with some other parts of your post. They could not emulate a scenario at their server's end as the very scenario they were emulating was loading new pages for the first time, something a server cannot tell a machine to do at the server's end. If you come from a scientific background, you should know that it is important to publish weird results as long as you note that the results are weird - which CR did. The only negligent thing that CR did was to not publish their testing process, which I agree that they should've. You cannot make a recommendation on inconsistent results, which is what CR followed - they did not say "the new MacBook Pro has a bad battery life" - instead they said that they couldn't recommend the tMBP based on inconsistent battery results. Now, as a secondary note, I do take issue with their testing process - most users will not diverge from the defaults and so they should strive to test using the default settingsYour post is a great example about how facts are bended through incompetent journalism and careless retelling by forum posters who didn't bother to read the entire story. Facts: CR was using a non-default, debugging configuration of Safari that can only be activated via a hidden developer menu. Virtually no users use that configuration. Yes, its Apple's bug in the end, but this bug only affects a very particular, low-profile operation mode and is therefore much less tested than the configuration a normal user would use. CR should know that using non-default settings of a browser cannot be representative for default operation. They have enabled that setting to emulate a particular scenario — and that made sense — however, they should have implemented that scenario at their server's end instead. Their mistake, one that I consider to be very crude for such a well-known organisation — is that they used a non-default configuration of the browser while not mentioning this fact in their original review(!!), observed some conflicting and overall clearly weird results (they even say it themselves!), and with all that, still proceeded to publish the article. I come from the scientific community, and thing like these are considered gross negligence and unprofessionalism. If you get non-systematic results in your experiment, which also conflicts with other related experiments, the only conclusion you can make is that your test is obviously not working properly.
[doublepost=1484351251][/doublepost]
Why does it have be fixed at all though? It's fairly clear that the time estimate is based on you continuing to use the machine in the manner that you're using it currently. Obviously the time remaining changes if I change my usage - Apple should've done what they usually do with user complaints and wait it out to see what's reasonable to change.It's still there. Just open activity monitor..
Alternatively, iStat Menu's can show it in the menu bar but with the same issue that made Apple hide it. Due to the extreme power throttling of the Haswell CPU's, the estimated time just jumps back and forth while your working with various loads.
For example, while using Xcode for app development, it shows over 8h while coding, than jumps down a bit while compiling just to go up again.
Not a real issue but obviously confusing enough for some "PRO" users to complain and have Apple remove it from the top menu. And this is not something that can be magically fixed. There simply is no simple way to predict remaining battery time in combination with aggressive power management..
[doublepost=1484351350][/doublepost]
It's been fixed in the latest beta and unless you enabled that option, it isn't affecting your machine. Btw, what do you usually do on that machine?Omg. .Stop it. Someone got a check. No "fix".. Still 3-4hrs at best. Unreal.
[doublepost=1484265654][/doublepost]
NAILED IT. I could not say it better! ^^^^^^
[doublepost=1484351486][/doublepost]
Then next time spend longer than 10 sec. on proper English grammarYes, "at least" Apples software is fixed now, but the tests don't tell the story for Chrome.
I'm sorry, I didn't consider those who thought "Apples software" was referring to Google Chrome when I spent 10 seconds typing that.
[doublepost=1484351996][/doublepost]
Are CR's procedures more rigorous than Apple's? From this report it sounds like it is acEven more interesting is getting battery life times of 12, 14, 16, 18 1/2, and 19 1/2 hours in some trials under a test procedure that's much more rigorous than Apple's, where Apple's published spec was up to 10 hours of battery lifetime.
Makes me wonder if CR actually did any kind of observation, monitoring, and supervision in their test protocols.
This is why some, more likely engineers, have little respect for CR's test procedures.
No, they don't. Apple specifically says that they keep all the defaults as they are, except where they make note of where there aren't specific defaults (screen brightness, etc.).It wasn't the CACHE, it was the BUG that was "ENABLED" by Disabling the CACHE.
According to Apple, that Bug caused Safari to INTERMITTENTLY fall into a LOOP, CONTINUOUSLY RELOADING certain Assets on the webpage. THAT's what burned the battery-charge.
[doublepost=1484283604][/doublepost]
Really? I would assume that Apple also disables the Browser Cache when looping through its 25 website-test-set.
[doublepost=1484352170][/doublepost]
Quite a few more than a dozen in a million. How many web developers are out there? Probably thousands if not many more?No, it's about the unprofessional way that CR is approaching the issue and a general recognition by the public that CR is no longer relevant as it was many years ago. First of all, this is a completely inconsequential bug. Who turns off caching on their browser? 4 or 5, maybe half a dozen, out of a million people? CR is only distracting from real issues, bugs, neglected product lines, etc. and other problems facing Apple, many of which are addressed by MacRumors users on a daily basis right here on these forums. CR also comes across as promoting clickbait and somewhat desperate for attention. Just look at the Youtube video above with the giant text superimposed: "Battery issue FIXED!" It wasn't even a battery issue. It was a Safari issue.
[doublepost=1484352439][/doublepost]
I'm a developer and I'm a) a college student (well, alumni now, but a student at the time of release) b) those cables cost quite a bit more than $19 at regular retail price but most importantly c) don't want to deal with the hassle of carrying so many cables.Yeah, but you have spend another $19 on a new cable
Seriously the haters act like they are so "professional" yet they can't afford new cables to go with their new laptops...oh I forgot...the haters don't actually have these new laptops LOL
Last edited: