macplusplus

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:
https://www.intel.com/content/www/us/en/support/articles/000025619/software.html

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,

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.

Chrome is known as a memory hog. Check at least its extensions, they may inject extra Javascript code. Also find an ad blocker like Ghostery to disable some ads and trackers. Trackers inject a lot of Javascript code. There is a utility called gfxCardStatus, it monitors which GPU is in use. Install it to check if there is a background process that continuously uses the AMD Radeon GPU. Also enable Automatic Graphics Switching in Energy Saver Preference pane. Open Activity Monitor, click on Energy tab, click the column heading Energy Impact to sort by that and check the processes that use the most energy. Keep the Brightness around 75% as specified in Apple battery tests. Use the Touch Bar to dim keyboard lights. If you cannot fine tune your battery usage using these techniques then the nuclear option is a clean installation of macOS Sierra.

AppleInsider said:

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

I liked that mouse. No, not for the sake of saying something controversial but really it was a pleasure to use it provided that you are not "holding it wrong". The mouse moves mostly in circular paths on the table, this might be the reason of why the shape of the mouse matches its movement. It is relatively easier to move a circular mouse in circular movements than a rectangular mouse. One downside is that you may lose the orientation of the mouse during that movement, but no, this is not a totally free movement, it is controlled by the orientation of the cable, it was easier to reacquire orientation than losing it.

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.

... If there is an issue at all. Apple can clearly describe the tests the battery estimations are based on. CR cannot clearly explain their tests. And this is all this article is about.

Here are Apple's explanations. Footnote #2 quoted below :
http://www.apple.com/macbook-pro/specs/

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

API is not just the interface, it is everything. You can build some library this way or that way, what distinguishes your IP protected work is how you design your libraries. You are not obligated to replicate the exact libraries Oracle has built; write your own functions and collect them in your own libraries to build your unique IP protected API. That is the whole point of the lawsuit. Oracle is right.

If the API is protectable then there is a whole lot of stuff that is suddenly a violation of IP.  All sorts of emulators, Wine for Linux (which is used in other projects), any applications that translate language and APIs into C or C++ etc.  A language and the standard library API are inseparable.   Maybe I date too far back, but as far as I am concerned this change is really really bad.  One project I know of started with a huge code base in VB and started its life as language translation from VB into Java - this ruling would make the writing of that language translator illegal since the code would be implementing the parsing of protected API and language IP.

Yes, yes and yes. This is why there exist multiple license types.

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

What a weird take. But I get it, you just wanted to old-man-at-clouds about Adobe's subscription pricing. Go ahead and review every other structured drawing program on the Mac or iOS. Guess what file format they all use—some of them wrapped in their own file package, but they're all EPS at the core. It's *the* mathematical model for object drawing.

More I'd say it indicates Preview.app's decline in relevance. 

I wouldn't say drawing programs on macOS use EPS at its core but every printer uses Postscript as its print file. PDF files are simply a combination of images and Postscript codes. Does this mean that Ventura Preview doesn't support the opening of PDF files? There has to be some reason Apple isn't talking about this limitation. The support file only says what's in the AI article. I have to wonder if you simply change the extension of a Postscript file to .pdf and see if it opens. This has nothing to do with any perceived Adobe decline, they will be around forever because PDF is a standard and Adobe wrote it. The non-commercial market isn't what keeps major applications around, it's the commercial market.

PDF is based on PostScript but a PDF file is different from .ps file. A .ps file is printer-dependent, PDF is printer-independent. Since .ps is generated by the printer driver, it includes all the setup environment specific to the printer and it will fail on another printer. Preview is PDF, it cannot be otherwise because Quartz, the very graphic core of macOS, is based on PDF. So PDF is intrinsic to macOS and it will remain so until another graphic model replaces Quartz.

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.

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

PCIe-4 support depends on Intel, not on Apple. Show us any Xeon that supports PCIe-4 yet. Your point is irrelevant.

appex said:

A real computer? Get a Mac! Apple should make a Mac tablet.

Apple won’t make a Surface. Get over it...

Disable location-aware widgets in iOS 14.