Repository navigation
Replies: 7 comments 25 replies
I have mixed feelings accepting PRs that are generated/assisted by AI. With that being said... it does seems like AI assisted contributions are an inevitably. @LubosD & @bugaevc - What are your thoughts on accepting AI assisted PRs? I'm leaning towards tolerating it as long the code quality isn't poor and the human author is willing to do their due diligence in verifying/understanding their AI code.
I was originally intending to redesign Darling's syscall implementation before I continued my work on ARM64, but I guess I can put that task on hold since there are PRs for ARM64 support.
I have mixed feeling bridging Quartz to Skia. We should only bridge to libraries that are essential (like Vulkan, FFmpeg, Wayland, etc.)
Please do keep in mind that it will take time for me to understand your code contributions. It may be a long while before I can accept these PRs. |
|
Thank you for your reply. In practice, I am also reviewing AI-generated code. I think it makes sense to share preliminary results for multiple humans to review, especially when introducing a single feature that requires massive code changes on ARM64. Regarding “bridging Quartz to Skia”, I may not have expressed myself clearly. What I meant was to have Skia serve as the underlying layer for Quartz, providing 2D rendering and animation capabilities, while Vulkan would serve as the underlying layer for Metal, providing 3D processing capabilities. |
|
I'm new to the project, just the other week discovered the project, but these are my two cents as someone interested to meaningfully contribute to the project using AI. I'm heavily using AI in my day to day work and thought to give it a try on Darling to see if I can get it running on my Omarchy M1 Macbook Pro, as a fun project to burn remaining tokens, hoping to one day get it to run all my GUI brew casks. About 12 days ago I started to submit AI generated contributions on the VibeDarling fork created by someone else. I went pretty crazy, maxxed out my Claude and Codex tokens for two weeks, plus 3 limit resets, most of which working on Darling. This resulted in over 500 pull requests across the Darling repos and code changes that probably approach 500k LOC combined. Among other things got it to build and run on Arm, built a Wayland backend to Cocotron that is significantly more feature rich than the existing X11 backend, added a ton of symbols and a exposed a few existing open source libraries through Apple ABIs, such as an adapter over OpenSwiftUI to mimic Apple the SwiftUI ABI, and a few smaller ones. This got it to the point of running a handful of native Mac applications copied from MacOS (including Textedit, Terminal and a few more), and a couple of 3rd party apps. They run but still with a ton of very annoying glitches, but addressing those quickly. I shared on discord a screenshot of the Terminal app running side by side with the Omarchy Linux terminal. This amount of progress would have easily taken years of manual work at the rate of progress I've seen before, and I've seen AI contributions from other people that were basically shut down and urged to slow down. In my opinion there's no way to slow down, we like it or not AI is here to stay. I'm sure this is just the beginning, there will be more of this once more apps get running, people see the usefulness of Darling and start to join and contribute in larger numbers. I think there's no way to meaningfully review all this AI generated code without AI, and that as a project we should embrace this iteration speed and use it to drive the project forward. So I started to work on a sort of AI collaboration protocol that would get people's agents to review each other's code, maybe human maintainers to approve the architecture of the change based on AI generated summaries but without necessarily looking at the code and once enough maintainer agents/people vote for the contribution to have it merged automatically. The critical part is this requires established maintainers to embrace this new way of working and trust the process. I'd love to see your perspective on this. |
|
I don't know @LubosD... We are making a huge gamble here. Things can go potentially south for this project. With that said, I won't deny that these AI tools are very impressive. If you want to go down this path, I will respect your decision. However, I'm not sure if I want to be a part of this... |
|
With well-defined project guardrails and a solid CI pipeline, you can ensure maintainability while using AI to boost productivity. Isn’t that the best of both worlds? |
|
I think one huge risk not considered here is that LLM generated code is in a legal gray zone in terms of the license. Is it license washed code or a derivative work? The developer contributing the LLM generated code has no idea the code the LLM was trained on. The code generated by the LLM is definitely not a "clean room" implementation, as it essentially reproducing work based on the training data. I don't see how this is a good idea for a project creating a translation layer of Apple's software where we want to avoid copying proprietary code. Just because companies are going all in on AI and don't consider the externalities (environmental, social, or legal) doesn't mean Darling has to do the same as an open source project. |
|
I find it nice to see some of you receptive to AI contributions, but also sad to see long term maintainers considering to leave because of this. I would love for us to find a way to make it work in a sensible way for everyone so we don't get to that, or leading to a hard fork of the project. But in the end everyone has their own motivations when it comes to contributing, and also valid concerns and boundaries that we need to consider for the best interest of the project. For me the main motivation is making meaningful progress towards getting things work. I personally don't get much fun reverse engineering things myself, troubleshooting bugs, typing the code myself or reading every single line of generated code code. The project is large enough and requires a tremendous amount of work, so people who love those things can still find areas to do that kind of work and contribute. I've been using AI for development ever since the early days of ChatGPT 3.5 and over time built a decent harness and agent configuration that generates decent quality code, although maybe not always perfect. But I think we can first make it work and then improve on it further until it meets even the most stringent quality requirements. As I did the bulk of the VibeDarling AI contributions, I noticed that most of the work was mechanical, perfect for fanning out to a bunch of agents and relatively low in algorithmic content:
The harness would fan out a bunch of agents that each addressed a few symbols, troubleshooting a bug and in the end commit a relatively simple fix. There are relatively few exceptions to this, such as the Wayland backend and the Webkit and Vulkan work I'm doing as we speak. But much of that was also "filling the blanks", using AI to work towards a simple goal of getting something to work as expected. A lot of the missing symbols patches took multiple hours of troubleshooting and verification but resulted in relatively small and simple diffs so should be easy to review by people. For the larger patches we could use AI to understand them deeply or split the patches into smaller chunks easier to digest and merge. If a given maintainer doesn't feel like reviewing a patch, they can just leave it for others until it's eventually ready to land in mainline. The way I see it we could do it like in the Debian project, having an "unstable" bleeding edge branch with a ton of vibecoded patches, a "testing" branch where things get merged once they mature enough, maybe used by a small set of users, and a "stable" branch that's rock solid and ready for general consumption, although maybe missing certain features. Small symbols addition patches can make it pretty quickly, enabling missing applications to run but larger work can be matured over time until it's ready. |
|
As someone who makes significant use of AI in my own projects and at work. The main concern is building in robust self-verification, actually reading your code and not using a shitty model. As long as that's in place basically any code change becomes trivial. You're never going to get into a situation where 'AI makes your codebase an unusable mess' cus it's basically trivial to tell an agent to 'clean up the repo so XYZ isn't a problem'. People really need to get out of the pre-AI engineering mindset because it's just not reasonable anymore outside like - competitive programming/demoscene stuff. |
|
I posted this in the Discord.
As additional context, I'm the AUR packager for Darling, and have been making good progress on understanding the HIToolkit/Carbon run loop, with the goal to implement it. |
|
AI has practically speaking nuked the entire basis on which software IP law was founded and the US government sees blistering advancement in this field as an existential matter for its economy so it will not permit anything that would make the industry's product to become radioactive. Everyone who could sue for this would also be guilty of it - we know for a fact that Apple is vibecoding |
|
Copying over from Discord: I don't actively contribute (including not having the cycles to review others' contributions), so I don't feel I'm in a position to make a decision. Yet as an observation, projects that enact pro-AI policies typically value achieving extraordinary results quickly, and projects that enact anti-AI policies emphasize community building, code review, and technical excellence. So depending on whether you think Darling is a serious way to run Mac software on Linux, or a fun low-level project to hack on. |
|
That's a false binary. I think it's a fun low-level project that I can work on to meaningful effect by making it into a serious way to run Mac software on linux. |
|
@Lazerbeak12345 I understand your concerns and I don't mean to downplay them. Regarding your IP/legal concerns, AI generated code is becoming acceptable in the industry, and even projects like the Linux kernel started accepting AI contributions, after adequate reviews that ensure quality. For me Darling is not a "a fun little side thing I work on and put research time in for fun", but rather a potentially useful project capable of eventually running all Mac apps, much like Wine does for Windows apps. I did all those contributions to the VibeDarling branch with the goal to be able to run my Mac apps on Linux. I also don't want to fork the project but to find a way to work together on it with the people who put so much effort over the years to get it to this point. I respect all that hard work and wish we could find a way to work together. Over the last days I was reflecting on how can we find a way to both accept AI contributions, while also ensuring quality of the mainline code base. I think a good way to do that would be to take inspiration from the Debian project's unstable/testing/stable model. This way we don't need to do a hard AI fork, but embrace the AI fork as part of the project's code intake process. Any sort of development would happen on a bleeding-edge development branch, that would equally accept manually written patches, as well as "slop" It may be broken at times, code quality would probably suck at first, but it would be working/useful code that people can play with and build upon. Eventually patch sets that survived for a while and passed an initial review process would be merged/backported into a testing branch, which would be used for testing builds given to a wider audience of people who could use this branch to get some working code that isn't likely to be utterly broken. And then, we'd have a stable branch, with carefully reviewed patches that were in testing for long enough to be deemed mature, and without any time pressure to promote to stable or to compromise on quality. The project would get more users and attract more contributions, hopefully over time getting to the point that it can run all apps we throw at it, like Wine is nowadays. I know this will require a lot of work to review this massive backlog of "slop", but I think for the project having lots of contributions is a good problem to have, rather than nothing at all. |
|
The first part of this post is mostly a re-hash of what we've said on Discord. Putting it here to unify the conversation a bit.
For one, that's not what I'm seeing. I'm seeing a mixed reaction to it. Second, that might not be a good thing. The popularity of the idea does not change that it is undermining copyright law.
Honestly I suspect this is understating the amount of work. The amount of slop on github is so bad that the website is breaking.
quantity over quality doesn't bode well in technical projects. This all isn't to say that I haven't used AI or that I'm 100% opposed to it. I've literally contributed to published AI research, for one! Secondly, I often use AI for validation (only). Something to the effect of "tell me why this code might be wrong" on a loop until I'm convinced the AI is telling me nothing new of merit. |
We may be in different bubbles, in the open source world many people are cautious because of copyright and maintainability concerns. But in the business world it becomes acceptable because of the speed/cost benefits, as long as the copyright risks are mitigated and the work is original. Copyright protects meaningful creative expression and verbatim reimplementation of large algorithms. In case of Darling the vast majority of the contributions needed to make Darling support real-world apps are small symbol additions that are mechanical in nature and don't have much novelty. What we can explore is some sort of automated pre-commit hooks that check patch hunks generated by AI are verbatim copies of copyrighted code. It could also see which license that code is under, and have AI run in a loop delegating rewrites to another agent with fresh context until the generated code stops being flagged as infringing any existing open source copyrighted code, or adding license notices for that code in case it's under a permissive enough license. |
|
It's impossible to check for proprietary source code without hosting a copy of that source somewhere, which is even more risky than having snippets from it in the first place. |
|
How about trying a new collaboration model? We could maintain two projects under the same organization:
vibedarling could take full advantage of vibe coding: rapidly validating ideas, implementing large amounts of code—especially replacements for closed-source system libraries—and quickly turning concepts into working prototypes that can attract attention, contributors, and donations. Meanwhile, darling would remain the carefully engineered project. Its overall architecture and direction would continue to be designed by humans, while selectively extracting and integrating well-designed, proven implementations from vibedarling. vibedarling would regularly merge the latest changes from darling, keeping it aligned with the main project while continuing to experiment and move faster on top of that foundation. When experiments in vibedarling prove valuable and mature enough, their implementations or ideas could then be selectively brought into darling through normal, carefully reviewed engineering work. With this model, every important dependency repository would ideally have a corresponding vibe version as well. In other words, vibedarling would optimize for speed and experimentation, while darling would optimize for architecture, quality, and long-term maintainability. The former explores and proves what is possible; the latter turns the best results into production-quality engineering. This kind of dual-track collaboration between vibe coding and traditional engineering is itself fairly novel, and the experiment could attract some attention on its own—even before the technical results start paying off. |
|
I'm rather fond of the KDE AI policy. Their rule is more or less that one should not be able to tell that it's AI. Now I don't agree that co-authored-bys should be stripped, per se (but I do understand why advertising a particular brand of AI is not ideal). As for unintended reproductions:
From figure 4. see the figure for the model-specific and task-specific percents. the means range from <5% to ~25%
From section 3.2 |
|
Regarding AI plagiarizing code snippets from other OSS projects, I think that's okay as long as
We need a plagiarism detector included in the pre-commit hooks that would maintain all this. And then the AGENTS.md would instruct the agent to do a clean-room implementation in another agent with fresh context whenever the commit hook fails, with high level instructions on what the rewritten code needs to do. Later edit: I don't think it's a good idea to force AI to generate code/PRs indistinguishable from humans like KDE is doing, because from my experience AI tends to write quite nicely formatted and chatty PR descriptions that are unlikely to be written by humans. I personally find those useful to understand the generated code if needed for review and also easy to identify as AI generated. |
|
@cristim I would like to think that Darling is unique enough that we don't need to worry about getting large chunks of plagiarized code. I am also following the hubbub around KDE and their AI policy. I understand it's a very heated topic. I'd compare it to the proliferation of automobiles more than a century ago: prior to that, people would need to learn how to ride horses (which served as a barrier) but then suddenly every fool could drive in a car, dangerously fast and cause accidents. The Pandora's box has been opened. Pretending the world hasn't changed won't change the fact. We need to find ways to make most of it and protect us from the negative effects. Another angle: The fact that we now accept monetary contributions means that people like me, @CuriousTommy and others can use these funds to build things right. IDK what else we should do with the money. I eliminated the hosting costs that I used to cover (by moving to GCP Free Tirer), so the only recurring host we have is the domain, which is peanuts. LMK what you think @CuriousTommy. |
|
@LubosD I agree, but saw a few people on Discord and in this conversation very concerned about legal consequences of using AI, and I want us to do as much as possible to address those concerns. The last thing we want is to scare people away by being too reckless with how we use/incorporate AI generated code into mainline. Regarding monetary contributions, I think we could use funds to sponsor maintainer's AI subscriptions, maybe setting up testing harnesses and CI/CD infrastructure to verify changes before merged to mainline in case the Github Actions and whatever other relevant tools free for OSS projects aren't enough. |
There are two areas where I am thinking of using the funds for:
|
It's maybe possible to Darling containers without disabling System Integrity Protection in macOS, but I don't have a Mac to do that (maybe via macOS VM if it's possible)
My best solution maybe WinObjC and Chameleon, both they have a complete implementation of UIKit/Cocoa Touch , we need modification to WinObjC to remove Windows-related things
We already have Cocotron as GUI implementation but we need to add more missing stubs, but my solution is to share bits and parts of ravynOS's Cocotron fork with Darling's one. The Cocotron fork that ravynOS is using has more implemented parts than Darling's fork now, so we can share them. They have also an WindowServer/Quartz Compositor/DisplayServer implementation that my idea it could be used as a virtual Aqua desktop similar to Wine has that. Since both forks keep the same MIT license, so no hurdles need.
We can gain widespread attention if maybe Valve and even Epic Games can eventually look at this and contribute them significant to Darling project. Valve can create a Darling implementation for macOS/iOS games on Linux called Neutron.
I don't think that is a solution to use AI tools to speed up development further, Wine banned use of AI-assisted contributations and PRs because copyright concerns and faulty code. I could recomend to discuss about implementing AI policy about banning AI-generated code.
It's in work-in-progress, also in the future we can support ppc64 and riscv platforms if it necessary
Skia is unnecessary for graphics backend. We have the Iridium/darling-metal implementation so check in our repo. Also my idea is to rename Darling into Darwine or Darine as it maybe for cross-platform outside Linux such as the BSDs, illumos, Haiku, AROS, RISC OS, Android, Genode and maybe Windows |
|
I am going to sound a bit grumpy here, for which I apologize in advance 😆
That hasn't happened in 14 years of the project. It feels like relying on a Wunderwaffe while losing the war.
So it means almost nothing will ever run. All that while even the Linux kernel is embracing the use of AI. We have plenty of faulty code at the moment 😅. Not to mention that we never even had as strict anti-reverse engineering rules as Wine.
Now who the heck uses BSD, Illumos, Haiku etc. on desktop? Maybe we can fit all of them into one room. These systems are even less relevant than they were 20 years ago and that's quite an achievement. |
The whole point of running Darling on macOS is to avoid using a virtual machine. If we're going to use a VM anyway, we might as well just run Darling in a Docker container. With Darling, we could potentially build true native macOS containers without relying on virtualization. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I’ve been following the Darling project for a while, and I think it has significant potential for several use cases:
Containerized CLI execution: Darling could run CLI programs like the essential CLT in containers on macOS. This could fill a gap in macOS, where containerization solutions are limited. Currently, the only known option is rund, which requires disabling SIP. I’ve seen discussions suggesting that Darling may be the only approach that works without disabling SIP.
iOS program support: Darling can directly load and run iOS programs on Linux systems, without requiring emulation or simulation.
macOS GUI programs: Darling can enable running new macOS GUI applications. As a reference, GNUstep has already demonstrated a similar approach for legacy macOS programs on other platforms, illustrating that this kind of cross-platform GUI support is possible.
Despite this potential, Darling hasn’t gained widespread attention. I think the project could benefit from stronger promotion and potential funding or donations.
With modern AI agents, iterating on a large project like Darling is now more feasible. Here’s what I plan to contribute:
I hope these contributions help Darling grow and reach its full potential.
All reactions