71–80 of 80 posts
Really 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.
Kakehashi is perfectly fine for the 2/3 of humanity that live in Asia. Open up your mind and learn other cultures.
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
Haha, thanks for the comment! My previous project had a more traditional name: WIE (Wie is Emulator), which was an attempt to run PE64 binaries on macOS via Cranelift JIT. It was an ironic joke nod to WINE (and it still survives in the GitHub organization name). For this one, I wanted something more conceptual. Kakehashi (掛け橋) means "bridge" or "go-between" in Japanese. Plus, I just really liked how it sounds and har…
WIE is also bad because the W in Wine is for Windows. Should have gone with MIE for both the Wine worldplay and weebery (well close enough anyway).
Would be nice to be able to build iOS apps on Linux ARM runners
this is something I've been waiting for a long time. I will be watching this with great interest. If this ever gets far enough I would love to see something similar to yabridge implemented on top of this and be able to run AU binaries on linux.
What's your use-case? Are you hoping for eventual GUI before it becomes useful, or there's value for you in the CLI?
Earlier quoted context omitted.
What's your use-case? Are you hoping for eventual GUI before it becomes useful, or there's value for you in the CLI?
I just want to use macOS plugins for music production on asahi linux. A GUI is important but not strictly necessary I guess. So yeah, limited gui support would be great.
By the way, has anyone checked if the utility works on Asahi Linux (or on real non-Mac hardware)?
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
WIE is also bad because the W in Wine is for Windows. Should have gone with MIE for both the Wine worldplay and weebery (well close enough anyway).
W in WINE stands for WINE
Earlier quoted context omitted.
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 l…