I thought this was a PCIE card with an Apple M series chip on it.
iceboundrock 12 hours ago [-]
A general purpose Apple Silicon layer for x86-64 PCs. It is a UEFI boot program with an arm64-to-x86-64 translator, a Metal driver for NVIDIA GPUs and a model of Apple silicon hardware. macOS and most apps start, but it is slow and needs much more testing, as of v0.1.0
stingraycharles 9 hours ago [-]
Is the intent to support running macOS on it, or rather for e.g. Linux that targets Apple Silicon?
perfsakuya 8 hours ago [-]
To support running the Apple Silicon version of macOS on x86-64 PCs.
userbinator 7 hours ago [-]
There was a lot of discussion around the time the M1 came out about how it would be the end of Hackintoshes, but it seems the Hackintoshers just won't give up (and now they have the help of AI.)
ShinyLeftPad 4 hours ago [-]
honestly i'm surprised.
apple still has good hardware but software feels increasingly bloated and buggy.
back in the day I hackintoshed, but now i feel like switching to asahi sometimes (or at least dual booting it) when my silicon is supported.
asimovDev 2 hours ago [-]
Hackintosh makes sense if you require to run Apple software to do something, e.g Xcode for iOS development since you cannot develop, build and publish easily without it. I am not sure if Final Cut or Logic or whatever else adjacent is still an industry standard. I'd think Da Vinci Resolve (which is even on Linux) and FL / Ableton are kings nowadays.
For a brief moment of time in 2020s it was easier to just buy a Mac Mini M2/M4 than bother with a Hackintosh but now with the hardware prices on the rise you have to consider it instead of it being a no-brainer.
ShinyLeftPad 2 hours ago [-]
True. Also plenty of people using Logic and FCP for whatever reasons (because Resolve is a crufty buggy piece of Electron app, because Ableton's price is multiples of Logic, because they like their workflows etc)
stingraycharles 2 hours ago [-]
Yeah the reason I switched to macOS is that pretty much all my hardware was already Apple, and it just integrates so much better.
I did Hackintosh for a year or so as well maybe a decade ago, but that was a scary experience any time you did an OS update.
exe34 3 hours ago [-]
Yeah my 2012 Mac book air runs nixos. Solid hardware, refuses to die, but it got pretty slow under os x about 10 years ago and I gave up.
yjftsjthsd-h 11 hours ago [-]
So, basically an emulator layer that doesn't need a host OS? (I'm not really interested in running Darwin, but that's a cool concept)
userbinator 7 hours ago [-]
I guess one could call it a "bare-metal/type 1 emulator" much like VMs can run in a "bare-metal/type 1 hypervisor".
cromka 11 hours ago [-]
"An ahead-of-time and just-in-time compiler translates arm64e code to x86-64."
No, not the same, actually. It's more of a Rosetta, but other way round, if I understand this right.
yjftsjthsd-h 10 hours ago [-]
Rosetta is an emulator (or, I suppose, a series of emulators), i.e. a piece of software that makes a computer pretend to be another kind of computer. This is also a bit of lower level software that makes a (x86_64) computer pretend to be a different kind of computer (aarch64), in this case, by AoT and JIT translation, though that's an implementation detail. What distinction are you trying to make?
stavros 8 hours ago [-]
This doesn't emulate a computer so that code in another architecture can run, it translates the other architecture'a code to native code. It's a small difference, but I guess it is a difference.
throwaway27448 8 hours ago [-]
Is this not how qemu works? Is rosetta not considered an emulation layer? For all its name suggests otherwise, I would certainly refer to wine as an emulator, and it also uses these techniques.
zbentley 8 hours ago [-]
Not to be That Guy, but WINE doesn't use those techniques, and thus isn't an emulator.
It lightly translates binary formats (Windows executables) into Linux-compatible executable code, and then runs that code against libraries that implement Windows APIs in terms of Linux underneath. It's not an emulator in the same way that your libc isn't emulating lockf(3) in terms of fcntl(2) underneath. In web-dev parlance, we'd call WINE a polyfill.
Rosetta and QEMU on the other hand are emulators--emulators, in this instance, being a term of art that implies interpreting bespoke meaning from machine code instructions written in another program. Some emulators translate instructions 1:1, some have optimized stencils, some (like Rosetta) have kernel support for emulating very quickly, and some (maybe like Rosetta; sources disagree) also have hardware support as well.
yjftsjthsd-h 5 hours ago [-]
WINE emulates an ABI, rather than a CPU or such, but I'd happily argue that that's an emulator. (In fairness, though it's not generally described that way, I would call web polyfills API emulation)
leidenfrost 8 hours ago [-]
Wine as a polyfill makes so much more sense
userbinator 7 hours ago [-]
I believe WINE doesn't actually translate any instructions; it's a Windows PE loader and a bunch of libraries that implement Windows APIs using Linux equivalents.
throwaway27448 7 hours ago [-]
How does it handle stuff like syscalls without altering the executed code?
pcwalton 6 hours ago [-]
Windows apps don't use syscalls directly; they call into kernel32.dll, which is convenient for Wine. (Microsoft enforces this by scrambling the syscall numbers on OS updates [1].)
Huh, now I know. I suppose macos is the same way these days even if you can technically bypass it.
Conan_Kudo 4 hours ago [-]
Yes. Linux is the only major operating system where there is even a convention to directly access system calls. For macOS, everything goes through libSystem.
aunderscored 6 hours ago [-]
It installs handlers. I don't have the exact name but there's support in the kernel to redirect syscalls to a Userland process
throwaway27448 8 hours ago [-]
> It lightly translates binary formats (Windows executables) into Linux-compatible executable code,
Does this not involve transpilation? I guess I was grouping that in under dynamic recompilation and AOT techniques.
Regardless, I don't think that there's a benefit from defining emulation from an implementation rather than an empirical perspective. If it runs a chunk of code as if it were in a different environment, I'm kind of ok to call it an emulator. To the sibling's point, a polyfill would also fit as an emulation layer here.
ecnahc515 6 hours ago [-]
Not necessarily. It could just rewrite the outer portion to be an ELF loader that then calls into a runtime that actually shims the syscalls for example. I don't think WINE does exactly this but it's not really transpiling either.
yjftsjthsd-h 4 hours ago [-]
You don't even need that, really; just have wine load the PE binary into memory and hand it a bunch of DLLs that use Linux syscalls under the hood. It's less transpiler and more of a funky dynamic linker+loader plus libraries.
jamesy0ung 10 hours ago [-]
I noticed Golden Gate still ships with an x86_64 kernel (not kernelcache), I wonder if this is any useful
james@Jamess-MacBook-Pro ~ % sw_vers
ProductName: macOS
ProductVersion: 27.2.1
BuildVersion: 26B131
james@Jamess-MacBook-Pro ~ % file /System/Library/Kernels/kernel
/System/Library/Kernels/kernel: Mach-O 64-bit executable x86_64
james@Jamess-MacBook-Pro ~ % strings /System/Library/Kernels/kernel | grep "Darwin"
@(#)VERSION: Darwin Kernel Version 27.2.0: Wed Oct 14 23:40:09 PDT 2026; root:xnu-13432.41.4~25/RELEASE_X86_64
Darwin Kernel Version 27.2.0: Wed Oct 14 23:40:09 PDT 2026; root:xnu-13432.41.4~25/RELEASE_X86_64
Darwin
vintagedave 10 hours ago [-]
This is fascinating. If x64 isn’t supported in Golden Gate why is this present?
ykl 8 hours ago [-]
Rosetta 2 is still supported, and the way Rosetta 2 works requires that various system components that x64 apps might depend on also be available in x64. x64 code that is running as arm64 translated by Rosetta 2 can’t call into native arm64 code due to ABI differences, so Rosetta 2 must translate the x64 version of system libraries as well.
My impression was that this did not require the kernel though, just system frameworks, so I don’t know why there’s a full x64 kernel in there!
stingraycharles 9 hours ago [-]
Not saying this is the reason, but we build and test and release our software on platforms nobody uses, as it catches rare compiler / memory / UB bugs we otherwise wouldn’t have (eg win32 and FreeBSD)
1over137 9 hours ago [-]
Lots of people use FreeBSD :)
ndiddy 9 hours ago [-]
Reminds me of how some of the dev versions of Snow Leopard still boot on PowerPC.
rbanffy 11 hours ago [-]
Sounds like a great use for those new Epyc processors with 256 cores…
schmeichel 11 hours ago [-]
Huge. I have been desperately looking for a project like this to be able to use https://github.com/seedds/nxnative to be able to play my copy of BOTW on IOS. Thank you for sharing this, I will be trying it this evening.
sneurlax 11 hours ago [-]
Is this really needed? I got it working on macOS pretty easily without this. It's all in private repos tho, not exactly easy to share by URL unless you're willing to sign up for a gitea.
orionblastar 12 hours ago [-]
This repository needs a star and a follow. It stops Intel Macs from becoming obsolete, but it is slow and buggy.
code_duck 9 hours ago [-]
Apple still supports the latest ones up to Tahoe, and probably security updates for a few years. You can install Windows 10 (no idea about 11) but that is only updated through next year. After that, there's Linux, of course.
1over137 9 hours ago [-]
macOS does get some security updates for the non-latest version, but it does not get all security updates.
I don’t think there is anything that can make Intel Macs not obsolete. Embrace it - that’s their charm and you should use them as they were intended to be used, and experience them as they were designed, as artifacts of their time.
iceboundrock 11 hours ago [-]
I installed CachyOS on my MacBook 16,1, and it feels much faster than with macOS, but the D side is still hot though.
LeFantome 9 hours ago [-]
No thank you. They can sit in a museum 30 years from now. Today, they are still amazing and productive machines (once you get macOS off them).
bigyabai 8 hours ago [-]
Many (most?) Intel Macs still receive microcode updates, Mesa support and recent kernel changes.
The only obsolete part is macOS, which is removable.
Rendered at 11:03:56 GMT+0000 (Coordinated Universal Time) with Vercel.
I thought this was a PCIE card with an Apple M series chip on it.
apple still has good hardware but software feels increasingly bloated and buggy.
back in the day I hackintoshed, but now i feel like switching to asahi sometimes (or at least dual booting it) when my silicon is supported.
For a brief moment of time in 2020s it was easier to just buy a Mac Mini M2/M4 than bother with a Hackintosh but now with the hardware prices on the rise you have to consider it instead of it being a no-brainer.
I did Hackintosh for a year or so as well maybe a decade ago, but that was a scary experience any time you did an OS update.
No, not the same, actually. It's more of a Rosetta, but other way round, if I understand this right.
It lightly translates binary formats (Windows executables) into Linux-compatible executable code, and then runs that code against libraries that implement Windows APIs in terms of Linux underneath. It's not an emulator in the same way that your libc isn't emulating lockf(3) in terms of fcntl(2) underneath. In web-dev parlance, we'd call WINE a polyfill.
Rosetta and QEMU on the other hand are emulators--emulators, in this instance, being a term of art that implies interpreting bespoke meaning from machine code instructions written in another program. Some emulators translate instructions 1:1, some have optimized stencils, some (like Rosetta) have kernel support for emulating very quickly, and some (maybe like Rosetta; sources disagree) also have hardware support as well.
[1]: https://j00ru.vexillium.org/syscalls/nt/64/
Does this not involve transpilation? I guess I was grouping that in under dynamic recompilation and AOT techniques.
Regardless, I don't think that there's a benefit from defining emulation from an implementation rather than an empirical perspective. If it runs a chunk of code as if it were in a different environment, I'm kind of ok to call it an emulator. To the sibling's point, a polyfill would also fit as an emulation layer here.
james@Jamess-MacBook-Pro ~ % sw_vers ProductName: macOS ProductVersion: 27.2.1 BuildVersion: 26B131 james@Jamess-MacBook-Pro ~ % file /System/Library/Kernels/kernel /System/Library/Kernels/kernel: Mach-O 64-bit executable x86_64 james@Jamess-MacBook-Pro ~ % strings /System/Library/Kernels/kernel | grep "Darwin" @(#)VERSION: Darwin Kernel Version 27.2.0: Wed Oct 14 23:40:09 PDT 2026; root:xnu-13432.41.4~25/RELEASE_X86_64 Darwin Kernel Version 27.2.0: Wed Oct 14 23:40:09 PDT 2026; root:xnu-13432.41.4~25/RELEASE_X86_64 Darwin
My impression was that this did not require the kernel though, just system frameworks, so I don’t know why there’s a full x64 kernel in there!
https://arstechnica.com/gadgets/2021/11/psa-apple-isnt-actua...
The only obsolete part is macOS, which is removable.