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.)

Looks like a user that was porting to ARM64 disagrees with the Haiku AI stance:

https://github.com/rcarmo/haiku-arm64-build#haiku-arm64-buil...

Makes sense. I had codex port haiku to arm64. Works decently, fun to play with on my Mac.

What I'd love to see (but likely lack the skill to, even with Claude Opus) is PowerPC. Haiku would look great on an iMac G4.

There have been some contributions accepted recently for the PowerPC port, so maybe it will happen! There is a working AI-driven derivative distribution as well. https://github.com/ActionRetro/Tabby-PPC

Cool! I watch Action Retro sometimes, but prefer the more relaxed style of TDNC.

I have a Pismo G3, so running Haiku on that would also be of interest to me (and I hadn't seen Tabby-PPC before)... though honestly I'm probably going to keep that machine as the PPC OS X & Classic machine that it is. If I can boot into Haiku from an external drive, then maybe.

Also, don't dismiss what you're capable of with Opus / AI! I keep discovering I'm not being ambitious enough with my AI work. Not that I'm an expert or anything, but the models keep being more capable than I imagine, with enough coaxing. I keep needing to set my sights higher.

I do always find that alternative OSes on PPC Macs are an exercise in going "It worked! Neat." and then going back to the Mac OS. 2026 software on 1999 hardware is always something I appreciate, but it's the Mac's unique "pairing" (lock-in) which gives it value compared to any commodity PC which will run Linux or BSD or Haiku or TempleOS better, and does not run the Mac OS as well.

My LLM experiments have become more ambitious as the tech has improved. Porting a decompiled SNES game to the Dreamcast is the latest (80% complete) victory.

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.