← Back to context

Comment by LeFantome

14 hours ago

I think there should maybe be shadow repositories available for Open Source projects where things like your driver could be contributed.

I get why Haiku does not want to deal with it do this is not a criticism. But I have also used AI to port software and create drivers. Others may not have the ability, even with AI. Perhaps I have docs you don’t. And some of it took a reasonable amount of money and time. I am not going to dedicate that to everything I might use if it was available. And in addition to wasting duplicated money and time, we are destroying the earth recreating things others have already done.

I use Chimera Linux and I have thought about starting a repo just for the stuff that I have ported.

I am not sure what the exact answer is but I hope this is something we figure out.

You can host an alternative repo, with the packaging system it has it's as easy as on any run-of-the-mill Linux distro. The easiest way is just to store your recipes in a repo (I do that: https://github.com/przemub/haikuports-nonfree) but a binary repo can also be easily hosted. In the hybrid architecture Haiku kernel has, drivers can also be loaded at run time. I think it's a good idea, much better than shoehorning into the main repo.

While people have varying stances, I understand the policy at least for the main Haiku repo code. Allowing AI-written contributions means you will get code that neither the contributor nor the teammembers fully understand, and asking questions about the wider context becomes futile. It would require a lot of distrust to get consistently acceptable results.

I think the fact that there are multiple people who have deep understanding of what they are working on and of the system's structure goes a very long way to establish this trust and ensure quality.

In this environment, I think (as I said, the opinions are varying), having the contributor learn about their contribution (even asking AI as a starting point, if they want to) and then (re-)write it themselves is a really minimum gate to make sure everyone knows what is happening.

This is one of the things I like with NixOS: it's easy enough to add new packages and patch existing ones that stuff like this can either live in the core nixpkgs repo or be managed through some community-supported overlay. (Great example of this is [nixos-hardware](https://github.com/nixos/nixos-hardware) which shares settings and fixes for specific laptop models and the like, or [emacs-overlay](https://github.com/nix-community/emacs-overlay) which has a bunch of extra Emacs-specific stuff that would not belong in the core repo.)