lorin schultz

MacPro said:

lorin schultz said:

goodbyeranch said:

Betting we'll see pro and mini versions eventually to address different segments of the market. 

Bring on the Pro! I'll buy a couple.

Funny thing for me is, after 20 years of them being in storage  I dug out my Nightingale NM1 speakers and Quad power and pre amp a few weeks ago (reflex cabinets; KEF B139, Peerless mid-rage and Isophon tweeters with amazing crossover hardware)  as we moved to a larger house and finally had room again for them.  It is amazing to hear them after all these years.  I'd actually forgotten what Hi-Fi sounded like.   They are massive and weigh ton each and take up a lot of space.  Now I think I really must hear these new Apple thingies.

Surround ruined everything. Where the hell am I supposed to put FIVE B&W 801s? (As if I could afford ONE, much less five!)

Just do yourself a favour and don't listen to it immediately after coming home from the symphony. It will destroy your enjoyment of recorded music for weeks, maybe months.

StrangeDays said:

lorin schultz said:

macky the macky said:

[...] Apple has a 10 year lead on custom Silicon

Correction: Apple HAD a ten year lead on custom silicon. The man responsible just took all that knowledge and experience to Google. This brings Google a lot closer to being current, and slows Apple's development efforts.

Yeah it's that easy. Bam. 

I'm having trouble figuring out what you mean. Was that a sarcastic snipe? Agreement? Involuntary muscle spasm? What's your point?

pakitt said:

For everybody else, RAID on Thunderbolt 3

Yup. In my world the cloud often isn't a viable option away from home. I'm always either behind a corporate nanny gate or tethered to slow, expensive cell data. Apple's efforts to herd me into the wireless corral are wasted since I can't get there even if I wanted to go.

I signed up for iTunes match to make it easier to sync our music library across the six devices in our home. I was taken aback a little when I discovered that it didn't push actual files to the other devices, but rather just placeholders for cloud playback. Obviously the files can be retrieved, but it illustrates Apple's intention that our storage be remote rather than local.

Getting back to the main topic, I'm cautiously optimistic about this new file system, but I share the concerns of others about how creating a "pointer+difference" file is an advantage over just making an actual copy. Assuming both files continue to be changed, eventually the number of bits written is going to equal (or exceed) what would have been required to just copy the whole file in the first place, so it seems like adding a layer of risk for limited payoff.

Soli said:

I did have an issue with the previous update where editing metadata in Get Info would take upwards of 5 minute to complete. I hope that this is resolved for me in this update.

edit: Issue still exists. I wonder if it's because I used CoreServices to encrypt an external RAID of HDDs in which my iTunes Library resides.

It's not your encrypted RAID. I have the same issue.

StrangeDays said:

lorin schultz said:

3. According to APPLE, not CR, the problem is the result of a BUG, not the testing methodology per se. The testing method merely exposed it. How long would it have gone on unnoticed and unfixed if the test hadn't uncovered it? It may not have affected me or you, but obviously some people would suffer from it. This is a positive outcome.

Actually I think Apple blamed both the methodology and the bug. See their statement:

“We learned that when testing battery life on Mac notebooks, Consumer Reports uses a hidden Safari setting for developing web sites which turns off the browser cache. This is not a setting used by customers and does not reflect real-world usage. Their use of this developer setting also triggered an obscure and intermittent bug..."

Note that they use the word "also triggered" the obscure bug. "Also", not "subsequently" triggered the bug. Right or wrong, they seem to be saying both conditions are responsible for the results.

Noted. However, Apple's argument that the test doesn't reflect "real-world usage" is largely irrelevant in this context. What CR was doing wasn't "real-world" use, it was "testing." Testing requires controlling variables. Since caching is unpredictable, it was disabled. I would have disabled it too.

Also, if the testing method were the cause of the reduced battery life, the battery life would have been short every time. It wasn't. There were huge variations. Since the testing method didn't change, it CAN'T be the source of the issue. The bug, on the other hand, according to Apple, is intermittent. That WOULD cause the results to vary.

So absent any obfuscation caused by phrasing, intentional or accidental, simple deductive reasoning demonstrates that the outcomes were the result of the bug and not the testing method.

If the bug is only evident when caching is defeated (which they haven't explicitly said) then maybe the battery issue wouldn't actually affect most users, and that's a valid objection. I just don't think it's fair to accuse CR of flawed testing when what they did actually makes sense.