31–40 of 102 posts
A few years back, I would have dreamt to run Photoshop on Linux. But this and the mandatory utilities that come with it became so bloated that even if it was officially offered on Linux I am not sure I would be using it.
I run the last version I could fully buy before it went subscription based. It’s great.
I went down a deep but entertaining rabbit hole in the other direction for fun: https://github.com/ayourtch-llm/fakelinux - initially with the idea “just replace the syscalls in the executable with some sort of a trap and handle that”. It almost worked, unfortunately MacOS reserves x18 for platform purposes and Linux doesn’t. The result is some sort of pretty mad contraption which works sufficiently often to compile…
I believe you can find slightly more info on how to use it in some XNU (macOS kernel) tests, namely this one: https://github.com/apple-oss-distributions/xnu/blob/main/tes...
Earlier quoted context omitted.
> What allows Wine to run so many Windows apps that there's not an equivalent for MacOS? Is it lack of interest? Is it a technical thing? It is a technical thing. The XNU[0] kernel, which underpins macOS and is detailed by the exceptional book "Mac OS X internals"[1], can theoretically run on many x86 and/or ARM machines. However, the issue with running macOS apps via other operating systems is not the OS, but instea…
No? Windows also has its own graphics subsystem, compositor, and an even bigger set of user land UI/forms/controls libraries than Mac OS. It really is just a critical velocity / adoption / time thing, there’s nothing strongly technical separating Mac OS API/ABI translation from Windows ala wine.
Apple's business model regarding macOS is to sell as many devices as possible capable of running that operating system.
The former lends itself to intrinsic portability such that an independently derived emulation layer is possible (not easy, just possible), whereas the latter has the freedom of assuming device capabilities/features always present for any given release.
This is the Darling project which aims to run macOS software on Linux for both Intel and ARM64. But you are probably looking for this: > Does it support GUI apps? > Almost! This took us a lot of time and effort, but we finally have basic experimental support for running simple graphical applications. It is still far away from running your favorite mac GUI apps like Logic Pro or Xcode, but it is a work in progress but…
What allows Wine to run so many Windows apps that there's not an equivalent for MacOS? Is it lack of interest? Is it a technical thing? I'd even be willing to limit to x86 apps. Or maybe there is and I'm just really out of touch??
When it started Windows was a lot smaller, so getting Windows 3.1 programs working was probably enough.
There's too much history to cover in a quick comment.
Wine has a lots of things that help - the compatibility database https://appdb.winehq.org/ is a good place for people to submit info on apps for instance, there's also a big test suite that runs against Windows + Wine.
Both of these have been around since the 1990s - Darling is at an earlier stage, but once GUI apps run better both of those are good ideas to adopt.
I think Darling probably needs more people working on it.
The whole are of Metal on Vulkan looks interesting https://github.com/darlinghq/darling/issues/390#issuecomment...
I went down a deep but entertaining rabbit hole in the other direction for fun: https://github.com/ayourtch-llm/fakelinux - initially with the idea “just replace the syscalls in the executable with some sort of a trap and handle that”. It almost worked, unfortunately MacOS reserves x18 for platform purposes and Linux doesn’t. The result is some sort of pretty mad contraption which works sufficiently often to compile…
Recently, Apple has made it so with a special entitlement, com.apple.private.custom-x18-abi iirc, you can actually use the x18 register, mainly so ARM64 versions of WINE/CrossOver can run outside of Rosetta, since they'll be partially killing Rosetta in macOS 28. I believe you can find slightly more info on how to use it in some XNU (macOS kernel) tests, namely this one: https://github.com/apple-oss-distributions/xnu…
Will it run xcode build tools?
*Does Xcode work?*
Yes and no. The Xcode GUI definitely doesn't work yet; see *Will > Work?* above. However, the Xcode CLI tools like Clang, LLDB, Git, the Metal compiler, the Swift compiler, and more do work.
*What about `xcodebuild`?*
Some versions of `xcodebuild` (e.g. 11.7) are known to work for extremely basic XIB-based macOS apps. However, the vast majority of projects do not qualify as extremely basic and aren't supported yet.
Earlier quoted context omitted.
No? Windows also has its own graphics subsystem, compositor, and an even bigger set of user land UI/forms/controls libraries than Mac OS. It really is just a critical velocity / adoption / time thing, there’s nothing strongly technical separating Mac OS API/ABI translation from Windows ala wine.
Microsoft's business model regarding Windows is to sell an operating system capable of running on as many devices as possible. Apple's business model regarding macOS is to sell as many devices as possible capable of running that operating system. The former lends itself to intrinsic portability such that an independently derived emulation layer is possible (not easy, just possible), whereas the latter has the freedom…
There's a reasonable argument that the Win32 API was designed to be more stable than the Mac OS one and this makes WINE's task easier, but this sword is double-edged: while slow change is useful, backwards compatibility expands the Win32 API surface area, since each API also needs to continue to support every way it was ever wrongly used. With the continued proliferation of Windows UI frameworks and OS subsystems, it becomes difficult to argue that Windows is any easier than Mac OS would be to implement at an API layer.
I do think there is an argument to be made that Win32 was more straightforward and felt more tractable when WINE _started_, and therefore the project was able to scale with the problem space, while OS X started from a "larger" place and was therefore more daunting, but this again is a timing and traction argument more so than a purely technical one.
Very neat. All I want for Christmas is Logic on Linux. But then you’d still need a Mac to legally download it from the App Store and DRM checks would probably only work on Macs
The strategy Apple has figured out with GarageBand pre-installed (or at least very low friction to install) seems really really smart in hindsight, give complete beginners a highly simplified but functional version of your professional utility, and provide an on-ramp to your professional programs. I imagine if Microsoft had some professional version of Windows Movie Maker it would've taken over a big chunk of the video editing market via the same method.
Anyway, regarding Linux DAWs, I am trying to get used to Ableton in Wine, but it's just not the same, and making it work in Wine is troublesome enough that I end up giving up before finishing anything of interest. Is there any DAW that feels like it actually belongs on Linux and doesn't either feel like you're maintaining a package by yourself, or has an awfully bad UI/UX like all FOSS DAWs I tried so far? I think in 2026 there's really a good opportunity here, with user interest genuinely rising for Linux on desktop.
I genuiniely can't see why I would want to run Mac software on my Arch box.
I have used Linux since the 1990's and used the Mac back in 1988.