- Last Active
Why everyone is so panicked?
In order to exploit the flaw the "attacker gains physical access by manually updating the platform with a malicious firmware image through flash programmer physically connected to the platform’s flash memory. Flash Descriptor write-protection is a platform setting usually set at the end of manufacturing. Flash Descriptor write-protection protects settings on the Flash from being maliciously or unintentionally changed after manufacturing is completed.
If the equipment manufacturer doesn't enable Intel-recommended Flash Descriptor write protections, an attacker needs Operating kernel access (logical access, Operating System Ring 0). The attacker needs this access to exploit the identified vulnerabilities by applying a malicious firmware image to the platform through a malicious platform driver."
as explained by Intel:
In everyday's language, the attacker needs physical access to your computer's interior. And all the efforts for what? For accessing kernel VM pages into which macOS never puts critical information. Holding critical information in wired memory is the ABC of kernel programming in Apple programing culture. That wired memory is the one that cannot be paged to VM. When the computer is turned off no critical information resides anywhere in your storage media.
AppleInsider said:Security firm Kaspersky says that in 2019 the Shlayer Trojan infected one in ten Mac users,No it doesn't say that.
It says "one in ten of our Mac security solutions encountered this malware at least once".https://securelist.com/shlayer-for-macos/95724/
If their "Mac security solutions" are installed on 1/100,000 of total active Macs, the one tenth of that makes 1/1,000,000 of total active Macs.
bocaboy2591 said:I have this problem with my new 15" 2016 MacBook Pro. I'm lucky if I get 4-4:30 while running on battery. I use Chrome, not Safari, so "switching" isn't going to solve my problem. I love my new computer, but I expected to get close to or better than the 10 hours that was claimed by Apple. Battery life is a big part of owning a portable computer. If the claim in 10 hours, then that's what it should be able to deliver. Lastly, check out the Discussions forums over this issue. There are hundreds of posts with users having this problem. Consumer Reports was right to withhold their approval until this issue is resolved.
Like the 2013 Mac Pro, Ive's notable errors reflect a preoccupation with beauty that eclipses functionality. His worst work is in building mice that are refined down their most basic design elements until they are just really shitty to use. Perhaps a fresh approach would create an entirely new kind of pointer that worked exceptionally well, even if it didn't look like a beautiful mouse at all.
Reductio ad absurdum
But then enter people's habits and muscle memory... Just like today's users stroking their keyboards to the extreme because mechanical typewriter keys had a long travel path, the users of that mouse were trying to "grab" or "catch" it to the extreme, because they were used to PCs' brick size mice. You don't grab that mouse, you don't hold it in the palm of your hand, it moves freely under your fingers. Your wrist rests on the table, then your fingers move to drive the mouse: a way to prevent carpal tunnel syndrome because your wrist is not elevated. It is one of Ive's most clever creations not appreciated by the "clients"... But, that's business, ingratitude is part of it.
jumpcutter said:I am glad this has happened. Apple can not ignore these test results from Consumer Reports. Whenever I have made a claim about an Apple product to AppleCare, they seem to express the claim as a surprise. "We never heard this before" is always their initial response. I am concerned because Apple will try to discredit CR then try and solve the problem. I do not trust Schiller... he is in charge of marketing hence "the cover up." Sorry, Tim Cook should be addressing this issue.
Here are Apple's explanations. Footnote #2 quoted below :
- Testing conducted by Apple in October 2016 using preproduction 2.0GHz dual-core Intel Core i5-based 13-inch MacBook Pro systems with a 256GB SSD and 8GB of RAM (wireless web test, iTunes movie playback test, and standby test). Testing conducted by Apple in October 2016 using preproduction 2.9GHz dual-core Intel Core i5-based 13-inch MacBook Pro systems with a 512GB SSD and 8GB of RAM (wireless web test and iTunes movie playback test) and preproduction 2.9GHz dual-core Intel Core i5-based 13-inch MacBook Pro systems with a 256GB SSD and 8GB of RAM (standby test). The wireless web test measures battery life by wirelessly browsing 25 popular websites with display brightness set to 12 clicks from bottom or 75%. The iTunes movie playback test measures battery life by playing back HD 1080p content with display brightness set to 12 clicks from bottom or 75%. The standby test measures battery life by allowing a system, connected to a wireless network and signed in to an iCloud account, to enter standby mode with Safari and Mail applications launched and all system settings left at default. Battery life varies by use and configuration. See www.apple.com/batteries for more information.
bkkcanuck said:macplusplus said:bkkcanuck said:I disagree with the Federal Court.
API is just the interface (e.g. add(operand1, operand2) - i.e. no implementation to that - and implementation is basically 99%+ of the code).
Being able to use an API for compatibility purposes is no different than for example Open Office being able to implement the file format for Word. The need for competition outweighs the argument as an API protected IP. Google's implementation uses the API (common) and then the implementation code which is probably more than 99% of the code base. As long as Google did not copy the code itself the API itself should be fair use. Languages and APIs should not be able to be protected as API.
The court has already previously ruled that you cannot protect interfaces for hardware for the purposes of locking out the competition on things like printer cartridges etc. An API is not much different than the software equivalent.
"A language and the standard library API are inseparable" provided that you don't replicate but just use that language and that library in your project. But if you build a new virtual machine and put into that the libraries copied from the competing virtual machine then you crash onto the IP barrier.
rob53 said:neoncat said:JWSC said:Does this indicate Adobe’s decline in relevance? Years ago I was all in on Adobe. But they priced themselves out of the non-commercial market and I dropped them like a hot potato.
More I'd say it indicates Preview.app's decline in relevance.
nubus said:JWSC said:How do you conclude that MacPro users would be lost? The MacPro has this magical thing called a PCIe slot. Have an Intel MacPro? Get a PCIe card with Apple Silicon. Have a MacPro with Apple Silicon? Get a PCIe card with Intel x86. This is a non-issue.
- There is no PCIe card with Apple Silicon and there won't be. Think security on a card + power + system integration + the fact that there are very few sold units. On the Mac Pro storage is connected to T2. And it won't work with the existing GPU in the Mac Pro. Last time Apple dropped computers launched 2-3 months earlier, and those computers got one OS update (10.4.2 to 10.5). The Mac Pro is toast - again. In the old days Apple offered motherboard replacements but that stopped like 20 years ago.
- The Mac Pro is PCIe 3.0 - which simply isn't fast enough. Even budget computers from AMD are now running PCIe 4. The Mac Pro 2019 was built using tech that was obsolete on launch. You can get a B550 motherboard with a PCIe 4.0 SSD for 50-100% better performance on storage.
appex said:A real computer? Get a Mac! Apple should make a Mac tablet.