Live data from Hacker News

M4 MacBook Pro

apple.com

811–820 of 1001 posts

Re: M4 MacBook Pro

#811

Earlier quoted context omitted.

This happens whenever I load up one of our PyTorch models on my M1 MBP 16gb too. I also hate the part where if the model (or any other set of programs) uses too much RAM the whole system will sometimes straight up hang and then crash due to kernel watchdog timeout instead of just killing the offender.

There is an API `proc_setpcontrol` which absolutely noone uses which does the thing you want. It definitely gets unstable in those situations, but you probably don't want your scripts randomly OOM killed either.

> There is an API `proc_setpcontrol` which absolutely noone

Gee, I wonder why.

  $ man proc_setpcontrol
  No manual entry for proc_setpcontrol

Re: M4 MacBook Pro

#812
post #656

Earlier quoted context omitted.

> Mac OS calls home every time you execute an application Consulting a certificate revocation list is a standard security feature, not a privacy issue.

Further, there is a CRL/OCSP cache — which means that if you're running a program frequently, Apple are not receiving a fine-grained log of your executions, just a coarse-grained log of the checks from the cache's TTL timeouts. Also, a CRL/OCSP check isn't a gating check — i.e. it doesn't "fail safe" by disallowing execution if the check doesn't go through. (If it did, you wouldn't be able to run anything without an…

There was a since fixed bug in a prior MacOS release that did fail to launch an app on the local machine if the CRL data was unreachable.

Re: M4 MacBook Pro

#813

Earlier quoted context omitted.

Guess that’s why most of their comparisons are with the older Intel Macs.

And M1 from 4 years ago instead of M3 from last year; while a 2x speed improvement in the benchmarks they listed is good, it also shows that the M series CPUs see incremental improvements, not exponential or revolutionary. I get the feeling - but a CPU expert can correct me / say more - that their base design is mostly unchanged since M1, but the manufacturing process has improved (leading to less power consumption/h…

Apple updates their microarchitecture with each bump.

Re: M4 MacBook Pro

#814

The single core performance looks really fast. Chip | Geekbench Score (Process) ---- | ------------------------ M1 | 2,419 (5nm) M2 | 2,658 (5nm) M3 | 3,076 (3nm) M4* | 3,810 (3nm) In my experience, single-core CPU is the best all-around indicator of how "fast" a machine feels. I feel like Apple kind of buried this in their press release. M4 benchmark source: https://browser.geekbench.com/v6/cpu/8171874

These numbers are misleading (as in not apples to apples comparison). M4 has a matrix multiply hardware extension which can accelerate code written (or compiled) specifically for this extension.

Also: https://news.ycombinator.com/item?id=40339248

Re: M4 MacBook Pro

#815

Earlier quoted context omitted.

With the sheer number of devs who use Macs, there is a 0% chance they’re going to outright prevent running arbitrary executables. Warn / make difficult, sure, but prevent? No.

The strategy is to funnel most users onto an ipad-like platform at most where they have basic productivity apps like word or excel but no ability to run general purpose programs. Meanwhile you have a minimal set of developers with the ability to run arbitrary programs, and you can go from there with surveillance on MacOS like having every executable tagged with the developer's ID. The greater the distance between the…

If so, they are executing it badly.

As for every executable being tagged, that is not required. People can build binaries with open tools and other people can run them.

A hash gets created for Apple to play same or different with binaries found to be nefarious somehow. Seems like a reasonable proposition.

Re: M4 MacBook Pro

#816
post #20

> "up to 1.8x faster when compared to the 16-inch MacBook Pro with M1 Pro" I insist my 2020 Macbook M1 was the best purchase I ever made

I don't like my M1. It's really good for using Lightroom at the coffee shop, but absolutely sucks for developing software

Re: M4 MacBook Pro

#817

Earlier quoted context omitted.

Whats the alternative? Linux? Maybe OP likes that their OS doesnt crash when they close their laptop lid.

It's not that bad anymore (e.g. with system 76), but I understand the point. I disagree with OP celebrating Apple to be the least evil of the evils. Yes, there are not many (if any) alternatives, but that doesn't make Apple great. It's just less shitty.

It feels like a lot of people in these threads form their opinions of what desktop Linux is like these days based on one poor experience from back in 2005.

Re: M4 MacBook Pro

#819

Earlier quoted context omitted.

They send a hash of the binaries/libraries, and generate a cache locally so it's not sent again. That helps stop you from running tampered-with binaries and frameworks. No user-personal data is sent. There is no evidence at all that they are trying to ensure you can only run things from the App Store - I run a whole bunch of non-app-store binaries every single day. To make that claim is baseless and makes me de-rate…

I agree and want to emphasize a few things: 1. Most users are not capable of using general purpose computing technology in a wild, networked environment safely. 2. Too many people who matter to ignore insist, "something must be done." 3. And so something shall be done. 4. Apple is navigating difficult waters. As much as I disapprove of how they have chosen a path for iOS, the fact is many people find those choices ar…

Thank you, this crystallized a lot for me.

Re: M4 MacBook Pro

#820
post #562

Earlier quoted context omitted.

Mac OS calls home every time you execute an application. Apple is well on its way to ensure you can only run things they allow via app store, they would probably already be there if it wasn't for the pesky EU. If you send your computer/phone to Apple for repair you may get back different physical hardware. Those things very much highlight that "your" Apple hardware is not yours and that privacy on Apple hardware does…

They send a hash of the binaries/libraries, and generate a cache locally so it's not sent again. That helps stop you from running tampered-with binaries and frameworks. No user-personal data is sent. There is no evidence at all that they are trying to ensure you can only run things from the App Store - I run a whole bunch of non-app-store binaries every single day. To make that claim is baseless and makes me de-rate…

> They send a hash

My understanding is that they keep a local file with known malware signatures, just like the malware scanners on every other platform.

> macOS includes built-in antivirus technology called XProtect for the signature-based detection and removal of malware. The system uses YARA signatures, a tool used to conduct signature-based detection of malware, which Apple updates regularly

https://support.apple.com/guide/security/protecting-against-...

Post reply on HN