81–90 of 135 posts
> Apparently, Disk Utility and command line diskutil use different code paths. StorageKit does not appear as a direct dependency of diskutil. [snip] This duplication in what’s more or less the same functionality, while sometimes justified, certainly increases the opportunity for bugs. To me this is the more problematic part - good design would use same code paths as much as possible for the GUI app and the command li…
Earlier quoted context omitted.
> a company which has approximately infinite resources I believe the leadership insists in keeping up a pretension that this is not actually the case. To be fair, most of that "infinity" is sitting in offshore bank accounts and can only be used as leverage for borrowing rather than being spent directly.
To be fair, it doesn't need to be spent in the US.
It's pretty insane this sort of bug either passed or didn't even go through code review and testing at Apple, a company which has approximately infinite resources and whose marketing pitch is making high-quality products. I loved Apple products and still do, but as both a user of and a developer for their systems, I feel the quality has been steadily going downhill the last few years.
I don't know. Serious QA problems in Apple software isn't anything new. Remember when iTunes 2.0 would wipe out hard disks? https://apple.slashdot.org/story/01/11/04/0412209/itunes-20-... The problem was an installer script that ran "rm -rf" as root: https://www.cnet.com/uk/news/itunes-2-0-an-analysis-of-what-...
https://github.com/valvesoftware/steam-for-linux/issues/3671
https://www.theregister.co.uk/2015/01/17/scary_code_of_the_w... (article)
I can imagine myself doing the same thing as well had I not heard about this back then
Installing a new Mac OS on a machine you care for has become an absolute no-go area. I wait for at least half a year and then only install in a place that I can trash in case I still see problems.
I'm not sure why you say "has become". In the circles I've been it has been common practice to wait for the .2(but minimum .1) release before it goes onto real work machines. The early Mac OS X releases were even worse. Even if for some reason the OS itself was fine by itself, they almost always broke compat with a bunch of 3rd party applications. EDIT: typo
It's pretty insane this sort of bug either passed or didn't even go through code review and testing at Apple, a company which has approximately infinite resources and whose marketing pitch is making high-quality products. I loved Apple products and still do, but as both a user of and a developer for their systems, I feel the quality has been steadily going downhill the last few years.
> a company which has approximately infinite resources I believe the leadership insists in keeping up a pretension that this is not actually the case. To be fair, most of that "infinity" is sitting in offshore bank accounts and can only be used as leverage for borrowing rather than being spent directly.
Or , they could pay the tax and use the money (crazy idea I know).
Earlier quoted context omitted.
> a company which has approximately infinite resources I believe the leadership insists in keeping up a pretension that this is not actually the case. To be fair, most of that "infinity" is sitting in offshore bank accounts and can only be used as leverage for borrowing rather than being spent directly.
> can only be used as leverage for borrowing rather than being spent directly Or , they could pay the tax and use the money (crazy idea I know).
> Apparently, Disk Utility and command line diskutil use different code paths. StorageKit does not appear as a direct dependency of diskutil. [snip] This duplication in what’s more or less the same functionality, while sometimes justified, certainly increases the opportunity for bugs. To me this is the more problematic part - good design would use same code paths as much as possible for the GUI app and the command li…
Yeah it seems bonkers to me that an OS would ship with two sets of disk management libraries. At worst, at least try to make one depend on the other.
I don't like the old style NSDictionary way of packing information that so many API's use. First of all they're lacking an enforcement for the type of the value they're expecting (sometimes leading to crashes if you get them wrong) and the discoverability of possibilities is less easy than with a struct or object. Still, passing in password twice would still be a possible mistake. The only thing that would help in my…
Earlier quoted context omitted.
> a company which has approximately infinite resources I believe the leadership insists in keeping up a pretension that this is not actually the case. To be fair, most of that "infinity" is sitting in offshore bank accounts and can only be used as leverage for borrowing rather than being spent directly.
> can only be used as leverage for borrowing rather than being spent directly Or , they could pay the tax and use the money (crazy idea I know).