Vincent Bénony:
Hopper Disassembler for Apple Silicon is now available!
[…]
I have recently decided to change how the future versions of Hopper will be distributed: starting with this new version, every purchase of a license will include a one year update plan. It means that if you purchase a license today, you’ll receive EVERY update for one full year.
But this is NOT a subscription; If you decide to purchase a license, it will always be usable even after the year is over.
noar:
Hopper Disassembler is the first reverse engineering software for macOS to support Apple Silicon authenticated pointers (PAC)
Previously:
ARM Macs Business Developer Tool dyld Hopper Mac Mac App macOS 11.0 Big Sur Programming
Mike Bombich:
CCC 5.1.22 is officially qualified for macOS Big Sur.
[…]
Thanks to these massive system changes and some bugs in the version of Big Sur that Apple intends to ship, nobody can make a proper copy of the System volume right now, not even with Apple’s proprietary utilities.
[…]
The changes in Big Sur definitely present some new logistical challenges, but yes, you can have a bootable backup of macOS Big Sur. Right now you can install Big Sur onto your CCC backup to make it bootable, and in the future we’ll use Apple’s APFS replication utility (ASR) to clone the Big Sur System volume. Apple has assured us that they are working towards fixing the problems in ASR that prevent it from cloning the Big Sur System volume.
[…]
To put it plainly, we spend about a quarter to half of our year just making CCC work with the next year’s OS.
See also: the known issues.
Previously:
Backup Carbon Copy Cloner Mac Mac App macOS 11.0 Big Sur
Ben Cohen (via Joe Groff):
Unlike a manifesto, which might describe multiple possible directions and in some cases unlikely directions, this document describes a single intended plan for tackling concurrency in Swift.
The end state of these changes will:
- make asynchronous programming convenient and clear at the point of use,
- provide a standard set of language tools and techniques that Swift developers can follow,
- improve the performance of asynchronous code through better knowledge at compile time, and
- eliminate data races and deadlocks in the same way Swift eliminates memory unsafety.
The introduction of these features will span multiple Swift releases. Features will be introduced in broadly two phases. The first phase introduces the async syntax and actor types; this will allow users to organize their code around actors in a way that will reduce, but not eliminate, data races. The second phase will enforce full actor isolation, eliminating data races, along with number of features to allow efficient and ergonomic interoperation of actors needed to make that isolation practical.
I’m still digesting all of this. My first impression is that it looks good, though some have expressed concerns about the plan.
See also:
Previously:
Concurrency Language Design Programming Swift Concurrency Swift Programming Language
