You can do it with HW accelerated emulation like Apple did with M1 CPUs. They implemented x86 compatible behavior in HW so the emulation has very good performance.
Another approach was Transmeta where the target ISA was microcoded, therefore done in "software".
They said that they implemented x86 ISA memory handling instructions, that substantially sped up the emulation. I don't remember exactly which now, but they explained this all in a WWDC video about the emulation.
Not instructions per se. Rosetta is a software based binary translator, and one of the most intensive parts about translating x86 to ARM is having to make sure all load/store instructions are strictly well ordered. To alleviate this pressure, Apple implemented the Total Store Ordering (TSO) feature in hardware, which makes sure that all ARM load and store instructions (transparently) follow the same memory ordering rules as x86.
In my case, as a developer of a programming language that can compile to all supported platforms from any platform the signing (and notarization) is simply incompatible with the process.
Not only is such signing all about control (the Epic case is a great example of misuse and a reminder that anyone can be blocked by Apple) it is also anti-competitive to other programming languages.
I treat each platform as open only when it allows running unsigned binaries in a reasonable way (or self-signed, though that already has some baggage of needing to maintain the key). When it doesn't I simply don't support such platform.
Some closed platforms (iOS and Android[1]) can be still supported pretty well using PWAs because the apps are fullscreen and self-contained unlike the desktop.
[1] depending on if Google will provide a reasonable way to run self-signed apps, but the trust that it will remain open in the future is already severely damaged
The signing is definitely about control, as is all things with Apple, but there are security benefits. It's a pretty standard flow for dev tools to ad-hoc (self) sign binaries on macOS (either shelling out to codesign, or using a cross-platform tool like https://github.com/indygreg/apple-platform-rs). Nix handles that for me, for example.
It makes it easy for tools like Santa or Little Snitch to identify binaries, and gives the kernel/userspace a common language to chat process identity. You can configure similar for Linux: https://www.redhat.com/en/blog/how-use-linux-kernels-integri...
But Apple's system is centralized. It would be nice if you could add your own root keys! They stay pretty close to standard X.509.
What is the subset of users who are going to investigate and read an rtf file but don’t know how to approve an application via system settings (or google to do so)?
I would say quite a lot of users because even the previous simple method of right clicking wasn't that known even by power users. Lot of them just selected "allow applications from anyone" in the settings (most likely just temporarily).
In one application I also offered an alternative by using a web app in case they were not comfortable with any of the option.
Also it's presented in a .dmg file where you have two icons, the app and the "How to install". I would say that's quite inviting for investigation :)
Try "killall -STOP photoanalysisd", this will pause the process instead of killing it (which would result in restarting it by launchd). You can unpause it by using "-CONT".
Chickens are very intelligent, it just happens that most people ever see chickens in overcrowded small spaces where they behave idiotically. So would you if you would be in the same situation.
I kept chickens for 15 years (mostly free-roaming in my backyard, unless there was a fox lurking, so not in overcrowded small spaces) and I disagree. To me they seemed pretty stupid, and pretty mean to one another
We've had a small amount (just 3) with plenty of space and it was fun to observe them, all sort of interesting behaviors.
My favorite thing is them cooperating against a common enemy (a dog that was eating their food sometimes, which we've tried to mitigate but not being much successful).
Then once they had a discussion in the opposite corner about the problem and launched a stealth attack, covering themselves behind the trees while approaching the dog without the dog knowing it. Then once close enough they attacked from behind, the dog squeaked, more from the surprise than pain and since then the dog never touched their food again and avoided them.
That exists and it's called web apps. For native apps you need the exact opposite, access to everything otherwise it can't do the useful integrations and provide the best experience for the user, which is the point of native apps.
You have to trust native apps, as it always was the case. You can't just install random apps. You can delegate the trust to a curated lists of apps that you trust.
Or you can just use the web apps, but then you have to trust them too (so they don't misuse information about you or your data for example). But then it can't integrate with anything and many features are simply not available.
As for your example, a photo editor could need a network connection when it contains collaborative features. Or an auto-update system. Or downloading of assets on demand. Or cloud AI feature. Or list of add-ons to install. Or for license checks. Or online help/docs. Or whatever.
Why do I "have to trust native apps"? I owe them nothing and they can happily work in a sandbox where they have access to a their own folder and files that I allow them to use. If I decide they don't need network, then they don't need network.
> a photo editor could need a network connection when it contains collaborative features. Or whatever.
Unfortunatelly DMA is the reason Google is doing this. It allowed Apple to require notarization for "security". Google is just copying the same approach as it's now clear what the requirements by the governments are.
Before it was unclear so it was better to allow installation of apps without any verification to appear as more open.
Remember any regulation/law has unintended consequences. At one point Apple decided that PWAs would no longer be supported in EU so they don't have to provide equal capabilities to implement them in alternative web browsers, fortunatelly they changed their mind by obtaining an exception. PWAs is the only alternative choice for making "proper" apps on iOS (no hacky sideloading methods).
I think overally DMA is more a loss than a win (good on paper, terrible in practice). It codified worse things. The EU app stores are still fully controlled by Apple (harder to install, they can just decline or drag notarization of any apps or revoke your license to dev tools, you need to still pay them, etc.).
For various apps the EU market is too small (esp. for things that need to be global) to invest into the development so while you can for example theoretically develop a real alternative web browser to Safari/WebKit (forbidden by App Store rules) nobody is willing to do it.
It doesn't matter how hard it was to produce, it is still a derived work. Binary vs source code doesn't matter for copyright, it's just a different form of the same work.
It matters with patents where you can have patented stuff in the source code without a problem as long as it's not compiled into the binary. Users who are unaffected by the patents or have a license can compile it in.
Fair use is used during a trial to determine if your use case is an OK exception despite being it a copyright infringment. It's not guaranteed to go into your favor (there are a lot of nuances case by case despite of precedents) and you need to be sued to exercise it.
What you can do is to mimic the behavior and look from scratch, then it would be a separate work. The internal structure would be quite different too. Even the same logic would most likely be coded differently. And the look wouldn't be pixel-perfect just very similar looking.
> When my terminal was dark, the eg some docs in the browser were light, switching back and forth was quite painful.
I do this all the time (even at night without lights) with no problem at all. The key is to have properly set brightness/contrast on your monitor and gamma correction.
It can achieved by setting the brightness to a minimum (and use the contrast setting to go even lower, or even combine it with GPU settings in addition to monitor settings). It is also important to set a proper gamma correction so that darker/lighter levels don't have too big contrast.
The gamma correction needed can be measured by comparing the apparent thickness of antialiased text in black-on-white vs white-on-black color combinations that you toggle between. Once it is the same you get the right value. For example it's 1.3 on my LCD.
MacOS can run unsigned apps with GateKeeper active, no need to disable it. Attempt to run the app, then go into security settings, scroll down and click on "Open anyway". And before Sequoia a right click -> Open was sufficient.
On M1+ devices it might also need "ad-hoc signing" if the developer hasn't done it (not required for Intel binaries). This is not a true signing, it just inserts a cryptographic checksum into the binary, no actual signing is involved.
Another approach was Transmeta where the target ISA was microcoded, therefore done in "software".