macOS 10.13.2 already patched the Intel Security bug

[captain_to_fire]

“The computer for the rest of us.” ?

 

[EunSoo]

mitigated not patched:

https://support.apple.com/en-us/HT208394

 

if I read and interpreted it right

Edited January 5, 2018 by SCGazelle

[Not_Jony_Ive]

Our fix comes faster than your android update...

[Mooshi]

Quote

macOS best OS! 

But can it run Overwatch without installing Windows in bootcamp? *smug face*

[Drak3]

4 minutes ago, Mooshi said:

But can it run Overwatch without installing Windows in bootcamp? *smug face*

Best arguement to switch to OSX I've seen.

[straight_stewie]

On 1/4/2018 at 11:32 AM, DrMacintosh said:

So it would appear that Apple has already patched one of the security holes in the Intel chips their Macs run a while ago. What is interesting to me is that they noticed that there was a problem and implemented a fix before anyone else. 

It's not a hard patch, it's just a sucky one. 

For whatever reason, all these companies that had months to work on a fix after the exploit was disclosed to them waited until the bug was disclosed to the public to start working on a fix, effectively making it a 0day exploit. That's the most bothersome part about all of this; Meltdown could have been patched before it was released to the wild.

[Bit_Guardian]

Oh for Pete's sake. These patches have been in the works since July. Software, being non-trivial, can be made easier or more difficult to modify along various measures depending on the design philosophy. That Apple got theirs done one month early is not suspicious to me as a contributor to Clang and two vastly different corporate ColdFusion apps designed and programmed by two vastly different individuals.

 

There's a reason I don't waste my efforts on GCC. The entire thing needs to be scrapped and redone from the ground up, regardless of their comparable performance. Clang is 40% smaller in its footprint because it has a modern design. It had documentation. It has very clear commit messages and readmes for sufficiently large changes. GCC's community only began waking up to this message a couple years ago, and thankfully Stallman's been overthrown as it's chief governor since he believed documentation was only needed for subpar developers.

 

The difference between a layman programmer of any skill and a solid software engineer is the ability to reason about both macro and micro design. Everything I build in my corporate work is modular. If we swap languages on our web apps, about 80% of everything I've built is reusable without any syntax changes whatsoever. I only use the language-specific security libraries and database integration libraries. Everything else is built generically. Think about applying this to an OS, something more than 10 million lines of code long, and try to imagine the impacts and ripple effects of one choice over another.

 

All Apple had to do was get luckier than Microsoft or Linux on one aspect 6-7 years ago, and that would impact development time extensively today.

[mr moose]

On 1/6/2018 at 2:59 PM, Bit_Guardian said:

Oh for Pete's sake. These patches have been in the works since July. Software, being non-trivial, can be made easier or more difficult to modify along various measures depending on the design philosophy. That Apple got theirs done one month early is not suspicious to me as a contributor to Clang and two vastly different corporate ColdFusion apps designed and programmed by two vastly different individuals.

 

There's a reason I don't waste my efforts on GCC. The entire thing needs to be scrapped and redone from the ground up, regardless of their comparable performance. Clang is 40% smaller in its footprint because it has a modern design. It had documentation. It has very clear commit messages and readmes for sufficiently large changes. GCC's community only began waking up to this message a couple years ago, and thankfully Stallman's been overthrown as it's chief governor since he believed documentation was only needed for subpar developers.

 

The difference between a layman programmer of any skill and a solid software engineer is the ability to reason about both macro and micro design. Everything I build in my corporate work is modular. If we swap languages on our web apps, about 80% of everything I've built is reusable without any syntax changes whatsoever. I only use the language-specific security libraries and database integration libraries. Everything else is built generically. Think about applying this to an OS, something more than 10 million lines of code long, and try to imagine the impacts and ripple effects of one choice over another.

 

All Apple had to do was get luckier than Microsoft or Linux on one aspect 6-7 years ago, and that would impact development time extensively today.

Don't go bringing logic and reason (let alone actual programing knowledge) into a discussion like this.   People need their reasons to love/hate on apple, if they find out they are company just like any other, we won't have any fanboys to blame for the stupid comments. 

 

 

admission: I thought it came quicker because they had a tighter OS (due to having less hardware/3rd parties to work around). 

 

 

[Bit_Guardian]

20 minutes ago, mr moose said:

Don't go bringing logic and reason (let alone actual programing knowledge) into a discussion like this.   People need their reasons to love/hate on apple, if they find out they are company just like any other, we won't have any fanboys to blame for the stupid comments. 

 

 

admission: I thought it came quicker because they had a tighter OS (due to having less hardware/3rd parties to work around). 

 

 

Eh, OSes themselves are usually developed without the core CPU in mind (I know that sounds impossible, but it's true). The only thing OS kernel devs really care about from a performance perspective is the memory model guarantees and the cache line sizes. All else is just noise.

[mr moose]

10 hours ago, Bit_Guardian said:

Eh, OSes themselves are usually developed without the core CPU in mind (I know that sounds impossible, but it's true). The only thing OS kernel devs really care about from a performance perspective is the memory model guarantees and the cache line sizes. All else is just noise.

 

So there you have it, another myth that is easily perpetuated. 

[wanderingfool2]

On 1/5/2018 at 7:52 PM, straight_stewie said:

It's not a hard patch, it's just a sucky one. 

For whatever reason, all these companies that had months to work on a fix after the exploit was disclosed to them waited until the bug was disclosed to the public to start working on a fix, effectively making it a 0day exploit. That's the most bothersome part about all of this; Meltdown could have been patched before it was released to the wild.

To be clear, they didn't start working on the fix when the public found out.  They all were working on the fix well before, most likely within a short time of learning of the bug.  Thus, when it was disclosed to the public, they were able to release a patch straight away.

 

The actual release date to the public was suppose to be Jan. 9th, which would have coincided with Microsoft's patch Tuesday.  (Microsoft patches the second Tuesday of the month).  So, if you want to blame someone, blame the outlet that initially prodded and poked to force the early disclosure.

 

Lots can go into patching systems, testing for stability, compatibility between programs, etc so I don't blame them for taking their time

[straight_stewie]

1 minute ago, wanderingfool2 said:

So, if you want to blame someone, blame the outlet that initially prodded and poked to force the early disclosure.

This is the piece of information that I was missing when I made that reply.