[flagged]
Show HN: Kakehashi – Experimental userspace to run macOS binaries on Linux ARM
51–60 of 80 posts
Re: Show HN: Kakehashi – Experimental userspace to run macOS binaries on Linux ARM
#52Earlier quoted context omitted.
Darling is written in a different language so I don't think the LLM would copy paste code from it directly. But it is the main (only?) prior art, so it could be argued that everything the LLM knows about how to do this came because it read and understood Darling, i.e. if Darling didn't exist it may still be able to do this but it would have to figure it out from first principles. Not saying it happened here, but it's…
> Darling is written in a different language so I don't think the LLM would copy paste code from it directly. Just because it is written in a different language does not mean that it is a clean room implementation. The logic from Darling might as well have been lifted and then rewritten by a human or an LLM agent. > Indeed, LLM code is now often better than human code, so direct code copying would be a disadvantage.…
you can copyright a specific implementation but that doesn't necessarily grant a patent on the "algorithm". so unless darling is patented then a translation of the "algorithms" in darling is legal. to wit: that's why all the "numerical recipes" books couldn't block implementations in other languages.
Re: Show HN: Kakehashi – Experimental userspace to run macOS binaries on Linux ARM
#53Interesting project! A long term vision for MacOS applications is feasible given the success of WINE/Proton with Windows applications. Are you familiar with the Darling project? https://github.com/darlinghq/darling There's an open PR for ARM64 support https://github.com/darlinghq/darling/pull/1753 Could you combine efforts or do your goals differ too much?
Wine got a lot of support from games, even today productivity apps are often much less supported.
Which makes sense, games have a much smaller area of contact with the host platform.
This sounds strange given how much modern GPUs can do, but consider that a typical Windows machine ca. 2005 will have Access/JET Red, Active Directory/JET Blue, possibly MSSQL, definitely MSMQ/MTS, ODBC, OLE DB, DAO, ADO, that one SQL interpreter inside Windows Installer, and I’ve only just listed Microsoft’s database-adjacent things. I’m not surprised that press reports about the “MinWin” initiative mentioned as the main difficulty the fact that nobody could figure out if any given component was actually necessary for a Windows install to function, let alone to be compatible with third-party software. (Is anybody other than WordPad using the Word 6.0 parser included among the text converters?..) Now consider that this was, by our standards, a lightweight system on a massively underpowered computer.
Re: Show HN: Kakehashi – Experimental userspace to run macOS binaries on Linux ARM
#54[dead]
Re: Show HN: Kakehashi – Experimental userspace to run macOS binaries on Linux ARM
#55Earlier quoted context omitted.
That's true. But if we can achieve support for the current stable version, it will be much easier to add new features later or rework the ones that were replaced (unless Apple changes everything on purpose :)
Historically, I’d say that the chances of this being successful are exceptionally low given how large the ABI surface is — and it will wildly change out from underneath you on a near yearly cadence. Perhaps LLMs change that calculation. I really couldn’t say.
I'm curious: how large is it really? As I understand it, Kakehashi is targeting command line programs, especially Xcode-tools. How much non-POSIX/Mach/BSD interface do Mac command line programs use? How much of that is not already open source. How much of that changes yearly? The only thing that comes to mind is process security for codesign and notarization but I'm just guessing.
Re: Show HN: Kakehashi – Experimental userspace to run macOS binaries on Linux ARM
#56Earlier quoted context omitted.
> Darling is written in a different language so I don't think the LLM would copy paste code from it directly. Just because it is written in a different language does not mean that it is a clean room implementation. The logic from Darling might as well have been lifted and then rewritten by a human or an LLM agent. > Indeed, LLM code is now often better than human code, so direct code copying would be a disadvantage.…
you can copyright a specific implementation but that doesn't necessarily grant a patent on the "algorithm". so unless darling is patented then a translation of the "algorithms" in darling is legal. to wit: that's why all the "numerical recipes" books couldn't block implementations in other languages.
IANAL and I don't think you are either. Be careful making simplistic inferences about a complicated system. Human "translation" is one thing, algorithmic "translation" has seen separate treatment in IP case law.[1] Whether this has relevance to LLM transformation or recall I don't know.
[1] https://en.wikipedia.org/wiki/Adobe_Systems,_Inc._v._Souther....
Re: Show HN: Kakehashi – Experimental userspace to run macOS binaries on Linux ARM
#57Really cool project, but honest question though: why do people tend to name these projects so horribly? I know software engineers aren’t actually known for their creative acuity when it comes to naming, but damn, Kakehashi is just bad.
[deleted]
Re: Show HN: Kakehashi – Experimental userspace to run macOS binaries on Linux ARM
#58Earlier quoted context omitted.
That's true. But if we can achieve support for the current stable version, it will be much easier to add new features later or rework the ones that were replaced (unless Apple changes everything on purpose :)
Historically, I’d say that the chances of this being successful are exceptionally low given how large the ABI surface is — and it will wildly change out from underneath you on a near yearly cadence. Perhaps LLMs change that calculation. I really couldn’t say.
Even React Native tools used by tons of companies struggle to keep up with Xcode build tool changes on mac itself.
Re: Show HN: Kakehashi – Experimental userspace to run macOS binaries on Linux ARM
#59Earlier quoted context omitted.
you can copyright a specific implementation but that doesn't necessarily grant a patent on the "algorithm". so unless darling is patented then a translation of the "algorithms" in darling is legal. to wit: that's why all the "numerical recipes" books couldn't block implementations in other languages.
IANAL and I don't think you are either. Be careful making simplistic inferences about a complicated system. Human "translation" is one thing, algorithmic "translation" has seen separate treatment in IP case law.[1] Whether this has relevance to LLM transformation or recall I don't know. [1] https://en.wikipedia.org/wiki/Adobe_Systems,_Inc._v._Souther... .
Do you understand what you're saying?
> Human "translation" is one thing
No it's not since "human translation" is literally all we had until about a year ago.
You should read the case again because it doesn't say what you think it says - it says generating a copyrighted work via a new system is still infringement (which is exactly what I'm arguing isn't happening in this case because what's being generated is a new language impl).
To put it very simply: if I use a machine (biological or electrical) to translate my favorite song into another language that's not infringement.
Re: Show HN: Kakehashi – Experimental userspace to run macOS binaries on Linux ARM
#60Hi HN, I started developing an experimental project with the goal of running macOS CLI binaries natively on Linux ARM machines. As of now, we have working prototypes for: - 7-Zip: Passes multi-threaded compression tests on an 8k-file tree. Currently ~5.2x slower than native Linux execution, but I already mapped out a clear optimization plan to cut this gap down. - curl: Over 200 commands and options successfully pass…
Do you plan on supporting different target versions and implementing similar restrictions to those targets? eg: older macOS had a writable /usr/ while newer does not without manual effort. Also, do you plan on having similar cli tools available with similar features ported (maybe from the available Darwin sources?) eg: can I run a /bin/bash script that expects a macOS environment? Will it get "Darwin" from "uname -o"
[dead]