5 ms·
This is by far the best explanation of what’s happening at Apple and why we’re noticing these bugs and problems: https://www.imore.com/understanding-apple-scale
by alwillis 9y ago
This is by far the best explanation of what’s happening at Apple and why we’re noticing these bugs and problems: https://www.imore.com/understanding-apple-scale https://www.imore.com/understanding-apple-scale
- x0x0 9y agoNot really. If you built a new filesystem, competent software engineers will heavily test the corner cases. What happens when the fs runs out of space? What happens when the metadata store runs out of space? etc. The original article mentions bugs that are pretty obvious cases to test. What precisely happens when you have a sparsebundle that exceeds the storage capacity of the containing volume? A PM needs to define what should happen and an eng needs to test that it does. It's inexcusable that things like this aren't tested and is an organizational failure. This isn't some complex interaction of earbuds with watch and a cloud system. This is a very testable filesystem.
- stormbeta 9y agoAgreed. Many of the issues with Apple's software quality lately are fundamentals, not issues of scale. Stuff like this, the root password bug, the many issues with reliability in High Sierra, etc. These things speak to organizational issues.
- dingo_bat 9y agoMaybe they tested everything and didn't care. That's unlikely but possible.
- x0x0 9y agoMy guess is more that MacOS just gets the B or C team, and no-one involved was smart enough or diligent enough to think through the implications of sparsebundles that don't reserve space.
- djsumdog 9y agoFile systems are hard. They're incredibly difficult and incredibly important. It look a long time to get to ext4 and NTFS, and there's a reason HFS+ has stuck around for as long as it has, despite all of its shortcomings and limitations. Even in the Linux work, thinks like btrfs, even though some distros consider it sable, is still treated with scrutiny. Back in the early 2000s, many Linux distros refused to install on XFS or JFS. Apple's APFS rollout really does fell like it happened way too fast.
- JustSomeNobody 9y agoRene Ritchie is very biased. He has to be as his livelihood depends on Apple. I take his words with many grains of salt. The only reason he's quoting Sinofsky is because it gives him a way of excusing Apple's software stumbles of late.
- alwillis 9y agoRene Ritchie is very biased. He has to be as his livelihood depends on Apple. No, he quoted Sinofsky because he’s one of the few people in the world who understands what it’s like trying to operate at this scale, since he was at Microsoft during it’s heyday. Corner cases that affect only .01 percent of the installed bases aren’t a big deal when you’re operating at a few million; it’s entirely different when it’s more than a billion devices.
- izacus 9y agoWhat difference does 1mil vs. 1bil make when they're deploying software on identical hardware? The type security and stability bugs showing in modern macOS and iOS are unacceptable at 100.000 installs. What does volume have to do with accepting empty root passwords?!
- JustSomeNobody 9y agoThe software issues haven't been corner cases lately. iOS 11 is just... bad software. High sierra has had some rather embarrassing issues too and, I'll say again, they aren't corner cases.
- alwillis 9y agoAlso, nobody is harder on Apple than the people who know the company best. He’d lose credibility if he pretended everything was all rainbows and unicorns when they clearly are not. He clearly cites how unacceptable some of these bugs are—that’s not being biased. Like Ritchie, I go back to the days of when the Macintosh Operating System shipped on floppies and didn’t have pre-emptive multitasking or memory protection—everything ran in the same memory space. The entire system would crash pretty regularly due to INIT (system extensions) conflicts, for example. I can count on one hand the number of times my Mac has kernel panicked over the last few years and I regularly run beta versions of macOS.