Reverse Engineering MacOS High Sierra Supplemental Update • Hacker News Board

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#131

Post by madeofpalk » Mon, Oct 09, 2017, 10:40 PM UTC

astrange wrote: post #123

madeofpalk wrote: post #92

Earlier quoted context omitted.

> a company which has approximately infinite resources The classic Apple problem is they they compatibility have much less corporate employees than other tech companies and they're stretched too thin, despite all their money.

Have you read "The Mythical Man-Month"? It's not possible to get better software with more people, only more software of the same quality.

Have you read the Mythical Man-Month? I havent, but my understanding of the general crux is that is that adding more people to a late project only makes it later. Not (again, from my understanding) the problem Apple faces.

Of course, nine women can't make a baby in once month, but loosely speaking the narrative that's been mentioned is how Apple doesn't have two women to make two babies in 9 months.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#132

Post by madeofpalk » Mon, Oct 09, 2017, 10:44 PM UTC

ShinTakuya wrote: post #128

madeofpalk wrote: post #95

Earlier quoted context omitted.

Never buy the first version of any new product

If nobody did then you wouldn't get a second generation since the product would fail. Better advice is never buy the first generation of a product until you see enough independent reviews.

You're right. And I guess it should be mentioned that I usually buy the first of anything Apple makes (the AirPods are amazing!).

I just thought it was worth pointing out that that quip usually is applied to more than just Apple. I guess its kind of a riff of the programming "never be the biggest user of x" mantra.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#133

Post by blinkingled » Mon, Oct 09, 2017, 10:56 PM UTC

burntcaramel wrote: post #127

blinkingled wrote: post #46

> 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…

I imagine StorageKit is a relatively new addition, or is tailored for UI applications. So I can see why it is not used by diskutil (which has been there from the early days of OS X), at least not yet.

Ultimately though it comes down to how much effort Apple is willing to put to get things right - doesn't look like that's much in case of macOS.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#134

Post by mark_l_watson » Tue, Oct 10, 2017, 12:26 PM UTC

Sorry if this is off topic, but I ran into another serious bug in High Sierra that I think is a result of their de-duplicating of files feature: I had about 30 GB of family videos and pictures on OneDrive and wanted a second copy on Dropbox. As I copied them I noticed that the disk space did not decrease, a good thing to have file de-duplication. All was well for a long while until I decided to have OneDrive and DropBox not keep my family videos and pictures on my laptop.

After DropBox and OneDrive deleted these files, I never got the 30 GB of free space back.

Apple should provide an option in the Disk Utility to check for files that don’t have references and free the space.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#135

Post by eru » Tue, Oct 10, 2017, 4:26 PM UTC

emsy wrote: post #112

eru wrote: post #45

Earlier quoted context omitted.

A coding style check _is_ static analysis. (But that's beating a straw man, of course: with that expanded definition your comment just because "you don't even need anything more than the most primitive forms of static analysis".)

I think the point I was trying to make was: If they don't even check for rudimentary things like coding style, can we expect them to check for more sophisticated sources of issues (e.g. memory corruption).

Amen.