X-Istence

You've misunderstood what the concept of jailbreaking means.

Jailbreaking in the sense it is used for breaking out of the Apple defined jail/walled garden.

Darwin does not have jails as FreeBSD does. And the software they have for limiting what an application can do is not in any way similar to what a jail is.

Ah, my apologies for not making that more clear. Currently all are running under Rosetta.

I was unable to get all the versions I needed compiled natively, which means for now I will use the non-native versions.

I have tested Py3.9 compiled for arm64, and one particular test suite went from 9 seconds to 6 seconds. Other test suites were not as dramatic, especially larger ones, where it might go down from 40 seconds to 36 seconds.

Still a speed improvement, but not as dramatic as the 2017 MacBook Pro i7 -> 2020 MacBook Pro M1.

I run test suite across those Python's. So Python 3.6, 3.7, 3.8, and 3.9 using tox to drive the automation to test against all of those versions to validate compatibility and that nothing breaks.

So there is no moving anything. Python compiled using pyenv for the Intel platform.

Which reports are you reading? Are they using C libraries or doing heavy math computation that is not CPU bound because there's no optimized ARM version yet?

Now your are just quibbling over what ultimately is a minor difference.

The rated battery life may not have, but the actual, real world experience battery life certainly has. Speaking as the user of a. 2019 MacBook Pro with the DDR4 that I use for work.

I find myself scrambling for a power supply way more often than I ever did with my 2017 15" MacBook Pro.

Even with the older battery in the 2017, with more cycles, I get a longer battery life out of it than the 2019.

"just"

Also need to track down and install all of the dependencies, and the dependencies dependencies and all the way down, and figure out the right configure flags to pass, and what environment variables it needs and where it expects to look for header files and the like.

Doing all of that from scratch takes hours and hours. Homebrew lets me not worry about that, and instead be productive.

I've been averaging about ~15 hours per charge on my 13" MacBook Pro M1 so far.

That includes compiling/running tests/and not just web browsing/checking mail.

5120 by 1440 at 60 hertz.

I have it driving a 49" UltraWide Curved Monitor... which replaced my two 27" monitors.

Might not be for everyone, but I only need it to drive a single external monitor.

Yeah, it is absolutely insane for my workloads.

It's Tier 2... and I've been using the ARM toolchain that was just released.

So far all the crates that were not working have been getting updates to work on the new platform, so far I haven't found any issues!

Because I enjoy working from my home office hooked up to my 49" UltraWide, but I also enjoy working from a coffee shop, or from my couch, or from my bed, or when I go spend time with friends and do amateur photography I like having my laptop with me to do on the fly editing/reviewing of images before finishing a shoot...

Portability.

I install from Homebrew, specifically MacVim. The system version is usually behind on patch levels/plugins that can be loaded.

Being able to easily install it using homebrew is really where that need came from. I can use the existing bottles and the recommendation for right now is to not mix and match both Intel/Arm binaries.

Also, the ARM version of Homebrew is not yet ready for primetime, there is a ton of software that doesn't compile for ARM yet (Including MacVim).

This is Python 3.6 -> 3.9 compiled to Intel running under Rosetta 2.

For Rust I am running the ARM toolchain that was recently released, so no Rosetta involved at all.

Probably because they couldn't keep waiting. It also means the 16" MacBook Pro goes through battery life at high speed from experience.

It does not support LPDDR4... which is something Apple has been targeting because it uses less power.

I'm a developer as well and don't use apps like VSCode, or Java/Gradle... but instead develop open source projects running Python, and Rust.

1. For my open source projects, running tests has sped up so much that I find it more of a joy to work on this projects now. Test suites that take ~60 seconds on my 2017 MacBook Pro i7, now take just ~15 seconds. That's a HUGE win in the edit, run test suite cycle.

2. My Rust projects now compile in WAY less time. Something that used to take 3 minutes to compile + link for a debug build is now down to 40 seconds. Once again, this has increased my productivity in the edit, compile, test cycle.

For other projects like node/npm the speedups are also massive and running various pipelines to go from source code to final deployable object is also much faster.

I use vim to develop, and it runs on Rosetta just fine, so I can continue to use all my existing plugins. I don't extensively use docker containers, but for those I connect to the cloud instead of running them locally, which is a move I was already making even on my Intel based MacBook Pro.

I got the 16GB 13" MacBook Pro. I, like the blog author, was thinking of this as a secondary laptop, something fun to have around, but I have hardly touched my old 15" MacBook Pro because this one does everything I already need. And does it faster.

I've been living with 16GB of RAM forever, so maybe I am used to fitting in that memory space... I avoid Electron based apps like the plague, and with being able to run iPad/iOS apps on the M1, I've been able to cut down even further since things like Authy are way faster to launch when they aren't large Chrome based hogs.

I am looking forward to the 16" MacBook Pro's with Apple Silicon based processors, but only because I do miss the additional screen real-estate, and prefer the larger size. But the 13" MacBook Pro M1 has been absolutely fantastic so far.

I've been pushing my virtualization to cloud providers or my in-home VM beast anyway, so that didn't matter to me.

What did make me faster though is compiling Rust is now soooooo much faster that it flies. I've been building some toy projects and the edit, compile, test cycle is now shortened so much that I find myself enjoying hacking on my projects more because there is no dead time while the compiler does its thing.

That alone is hugely important.

webpack is also faster, as is a lot of other things that don't require virtualization or docker. I bought the 13" MacBook Pro M1 to supplement and use occasionally alongside my 2017 MacBook Pro 15", but I find myself not having touched my 2017 MacBook Pro at all because I keep grabbing the 13" MacBook Pro.

It's incredibly fast, and the battery life is amazing, which allows me to not worry about where my charger is, or whether I am comfortable on the couch and damnit now I need to get up and plug in.

I think part of the issue with the eGPU as mentioned in the forum post that is linked is that the drivers haven't been compiled for arm64. So maybe they will bring it back once the drivers are stable enough?

That's not true. Anyone with an Apple ID is able to sign software they build/binaries and install them on their iOS devices.

Although instead of lasting 1 year they only last 7 days, but there is no fee for a user to sign and install their own binaries.

Most people who buy Macs won't use Docker either, or even know what it is.

Where do they claim to do that? Maybe there is no API for it because it happens so rarely that letting the Apple Security team push a few buttons is more cost effective.

Replace Apple with any CA on the world wide web, if I go ask them to revoke a certificate, they should just do as I ask. Not try and second guess me.

Apple is not to blame for HP requesting the certificate be revoked, not even apportioned. HP is the sole requestor and the sole entity responsible for the cert being revoked.

That's the same way a CA works (except with a bit of automation instead of emailing someone).

I go to the CA that issued my cert and say "I'd like to revoke this" (whether that is an API call or an email), they then publish the cert into their certificate revocation list.

Now, Apple could deny a request, but they are under no obligation to do so, and I would argue that they shouldn't be making those judgement calls.

As they did here, they get the email, they then publish the CRL, and wash their hands off it.

HP to Apple: "Please revoke this certificate"

Apple: "Okay done"

Lapcatsoftware: "Apple is to blame for revoking this certificate"

How is Apple supposed to know that the certificate has not been compromised? When I ask my CA to revoke a certificate I don't have to explain why to them, they just do it. They are my consequences to bear.

NLB doesn’t support IPv6.

An ALB is the only one of the load balancers in AWS to support IPv6, but only to terminate the connection, not to send traffic to an IPv6 target.

If I were a spammer I would very much not appreciate the notion that you will allow them to remove my content, but not your "political content".

Why is your content okay, but mine isn't?

Home Theater uses the full size HomePod's to do 5.1/7.1/Dolby Atmos surround sound. It requires the spatial processing to allow for the surround sound experience.

The HomePod Mini can be used as a stereo pair, and connected to an Apple TV with no issues.

Apple does have this page: https://support.apple.com/en-us/HT208336