Live data from Hacker News

Reverse Engineering MacOS High Sierra Supplemental Update

cocoaengineering.com

121–130 of 135 posts

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#121

Off topic but related, anyone know of any active OS X hacking/tweaking forums or communities? I have an I/O issue with a peripheral I'm trying to isolate, could use some expert help.

www.tonymacx86.com is where a lot of the hackintosh community gathers. Plenty of folks in the forums there who understand the kernel / IO / driver stack.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#122

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.

> at least half a year oh yeah half a year, really? oh shut the fuck up. fuck off.

We've asked you to please stop this already, so we've banned the account.

https://news.ycombinator.com/newsguidelines.html

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#123
post #16

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

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#124
post #12
post #4

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; /* MISTAKE! THIS LINE SHOULD NOT BE HERE */ if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; History repeats itself in ever stranger ways. While the effects are different, the original mistake can be quite similar.

You don't even need static analysis (which they should use too) but just a strict coding style check that enforces curly braces. Should've happened after the first incident!

The Python and Haskell programmers would be upset if you added that pre-commit hook.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#125
post #105
post #71

Earlier quoted context omitted.

I think you might be looking at the past through rose-colored glasses. Apple's always had horrible show-stopping bugs, in every single OS X / macOS release[1], from when simple operations like updating iTunes or enabling the OS's Guest Mode might delete your home directories, to this latest failure. I suspect one reason is that they like one-person teams so much. I like one-person projects too! But there is always pa…

Are Windows or Linux QA any better, by comparison? I've been getting very disillusioned with macOS, but the workflow pain on the other platforms has been enough to keep me coming back to macOS, thus far. Working on a Linux machine would be the closest thing to perfection (in terms of workflow), but there are so many workarounds needed, and the selection of apps just isn't there. Operating systems suck. I'm obviously…

Agreed. I ran NeXTStep back in the day and Solaris. Getting OS X was amazing. Now it can be a bit frustrating, however it is still way better then Windows10 (takes forever to disable all the crapware, spying stuff and update). I looked at Linux and it works and the system itself it stable, but the desktop is not - many issues on various flavors of desktop crash-e-ness. Oh, well.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#126
The Supplemental Update took ages to install on my SSD-equipped 5k iMac (it's only about a year old). In fact, I'm quite sure it took longer to install than High Sierra itself, which is quite an achievement because the High Sierra install involved upgrading my filesystem to APFS!

Maybe I just found myself more annoyed than usual because I clicked "try later tonight" for the supplemental update prompt when using the computer the day before, and then when I tried to use the computer in the morning, it went about its installing business which featured 2 backwards-moving progress bars and took at least 20 minutes, while I sat around twiddling my thumbs waiting to use my computer for what should have been a simple task.

I'm not sure if this is normal behavior when you postpone an update and then wake from sleep later, but I've never seen what effectively turned into an un-prompted forced install before.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#127

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

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#128

Earlier quoted context omitted.

Exactly. "Never buy the first version of any new Apple product", whether hardware or OS, has been well-known for at least 10 years: https://www.engadget.com/2006/06/03/why-first-generation-app... (That said, I've found my first-gen Apple Watch to be a great product. First-gen iPad is a paperweight though...)

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.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#129
post #13

Seems like Unit testing really is NOT popular at all at Apple. I mean, they release a framework for storage, and they don’t even unit test security related functions ? Tdd introduced the wrong idea that unit tests should be all or nothing. I think it’s not. I unit test only the most critical parts of my programs (and only if there are), and i see value in it.

Serious question: How would you suggest to write a test that prevents this? You wouldn't make an assertion on clearTextPassword !== passwordHint. While developing I would think "Who will ever do that? That would be insane". But yes, even if there is no test, this should have been caught in code review or latest when testing the OS.

How about a simple test giving the function a set of parameters and then asserting that the output dictionary (besides the password hash) equals the expected output? That would have caught this case with ease.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#130
post #16

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.

The problem with testing is that it has the potential to gobble up infinite resources without actually adding much value. Just because you tested something, doesn't mean it will work reliably. It's that simple.

Honestly, unit testing good code should have a minimal impact on overall productivity. I'm not suggesting rigorous testing of all possible inputs, but at least testing one good case and one bad case can save you a lot of headaches and only takes a couple minutes to code in most cases.

I mean I agree with your general point in that testing too much is also a bad thing, but too often I hear this used as an excuse for not testing at all. And that's how we end up with legacy monstrosities that you can have no confidence in modifying that so many of us have to deal with.

Post reply on HN