Just a heads-up for those trying it out, I've found a couple of regressions in Beta 6 that rendered my Haiku system unbootable, until I remembered about hammering the space key during the boot sequence to get to the safe mode menu.
In my case, my ThinkPad X1 (Yoga 3rd Gen) used to boot despite what appeared to be kernel panics, but typing "continue" at the kernel prompt would skip past them and everything would then work fine. In Beta 6, it now hangs at boot instead with no kernel panic warning. Disabling ACPI in the safe mode options gets me past that, and there's a way to disable ACPI permanently at boot via some configuration files - though obviously that isn't desirable.
It also seems there's been some work on USB Audio (yay!), but it now causes a kernel panic on boot if a Focusrite Scarlett is connected. Turning the Scarlett off avoids the kernel panic. The Scarlett has never officially worked in Haiku, but it at least never used to crash the system. In my case, I've reverted back to the USB Audio Scarlett Haiku driver that Claude Sonnet vibe coded for me, and for me that's working. (I can't contribute that code because of Haiku rules against AI code, but hopefully the humans will eventually find time to hand code it and get it working.)
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.)
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
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.
I keep a personal list of links to defend my non-AI stance. It is weird I even need to. If I am a carpenter and I was ordered to use a robot and tell it what to do there would be lawsuits and what not but as a software developer I am the idiot that does not want to modernize.
Will do, I think I recognize your username from the forums :) Life is getting in the way and makes it difficult to write a bug report with the necessary level of detail & logs. But when I can find time, I intend to.
I think the ACPI issue is long standing, but I can't find my bug report anywhere in Trac. I'm fairly sure I've made at least one report, I created my Trac account roughly 6 years ago. But I also remember running into issues with Trac, so maybe it never went through.
If it's the one I'm thinking of, this device includes a read-only ~100KiB USB mass storage device filled with .lnk files to remind you to register the device to get your bundled digital goods (a bunch of DAW plugins).
You might want to try connecting the interface with Windows and install the focusrite driver. This will set the device to a "pro audio" mode, unlock the higher sample rates, and permanently make it stop behaving as a mass storage device. Not sure if this fixes Haiku OS USB audio compatibility, but it's a good bet and helps avoid the annoying mass storage device volume.
If you don't have a Windows machine to do this on, you can do it in a libvirt or qemu virtual machine on Linux using USB host device passthrough. Once you do it, it doesn't have to be done again, I'm guessing they implemented this with an eFuse.
Haiku should rethink that AI rule. Put very high code quality gates in place, sure, but Haiku in particular is a very low-velocity project and AI could help them so much. There is no reason you can't produce high-quality code with AI conformant to your style guidelines and structural preferences, it just takes a lot more effort than the slop.
I'm curious why velocity is sooooo important. Every single AI discussion that I've read always always always mentions velocity or development speed as though that somehow is the ultimate goal. Why does it matter if your velocity isn't as fast as everyone else? Maybe taking things slowly might actually be a good thing.
I'm not at all trying to be overly critical or pissy; I'm genuinely curious as to why this is always the gain that AI brings as though it matters (or, rather, this is how it's always stated in one way or another). So I come from a place of confusion when asking this. Why should I care if you can write 100000 or 1000000 lines of code and push out 10 billion commits per minute? (Yes, I am intentionally exaggerating here to prove a point.) If anything, I would argue that increased velocity just brings about recklessness and unnecessary churn instead of accomplishing anything useful.
Velocity is important because we all eventually die.
I've been following Haiku since it was announced. In that time a couple of personal friends have passed on, and a number of family members. In that time children have been born, gone to school, grown into adults, and had children of their own.
Projects that drag on forever make for an interesting artistic statement, but if their goals in any way include utility then velocity is important because time is important.
Not everything has to happen in your or my lifetime. Not everything will happen in our lifetimes. If time is so important, Haiku was never going to work for you anyways on account of it being niche, which adds friction, which adds time. Velocity isn’t going to fix this either
As I mentioned, projects that take a long time make for interesting artistic statements. But if the goal isn't performance art but is utility, then alacrity matters.
Many other niche projects have enjoyed enough velocity to have meaningful utility, in my lifetime. Linux was still niche when I started using it in '94.
Some people enjoy building things. It's not performance art, it's a hobby. Can Haiku not be a hobby for people who enjoy hacking away at BeOS? (You might think I'm splitting hairs here, but performance art is precisely the wrong analogy to use, since performance art is for the benefit of others. Performance art is inherently public and assessable in terms of how it reaches others, unlike hobbies. Performance art is env=PROD.)
Was the purpose of Haiku ever utility? What do you define as utility? If I spend a day building a shelf, does that have more or less utility than buying a shelf from IKEA? What if I like making shelves? What if I like making OSes? Does the shelf (/OS) that I build have less utility than the one from IKEA (/MS)?
In economics, utility is a measure of individual satisfaction. The person who likes tinkering with Haiku is deriving cold hard economic utility from Haiku right now. What should it matter to this person whether you find Haiku web scale and production ready? John Q Public is never going to run Haiku, no matter how much polish you throw at it. Why rush to some goal line that doesn't exist in the first place?
Velocity of LoC isn't important. Velocity of user visible improvements can matter if a project feeds off of usage and popularity. Or at least that velocity matters until the OS is capable enough to satisfy the user base.
I... Don't agree with this. If your users have followed your projects developments even remotely reasonably, you taking a few months to implement something or to figure something out is not a sign that the project is dead. It would be one thing if your project was completely inactive for like 2-3 years.
Haiku OS has gone up to 6y between releases. While not entirely inactive in that time, lurkers who aren't as motivated to dig for signs of life could reasonably conclude the project is inactive.
For example, I'm a big fan of DOSBox. And while the core project still has some code check-in's from time to time, its last release was 7ya. Now I use and follow forks because they're consistently releasing useful features and fixes.
My understanding is that the AI policy is more to do with issues of copyright and code provenance. They want to make sure that all of their code is cleared with no risk of accidentally using 'stolen' code or GPL code repeated by an AI. I can at least understand the policy.
I think there's other opinions around AI use there as well, but I'll back off from that. I didn't mean for my post to become top voted, when we should be celebrating Haiku reaching Beta 6. I'm just disappointed that for me, R1/b6 has been a very big regression, right at a time when I've been using AI to make all the software I write cross-compatible with Haiku via Go & SDL, and even use AI to write drivers so more of my hardware works on Haiku... and instead, now I can barely even boot the system.
I have no qualitative opinion as to whether the Haiku team should reconsider the AI rule or not, but you select about just one possible advantage. There may be disadvantages using AI. One that keeps on happening is that real humans use AI slop spam to pester other humans with it.
> There is no reason you can't produce high-quality code with AI conformant to your style guidelines and structural preferences, it just takes a lot more effort than the slop.
It's not just code though. There are humans who deliberately and actively use AI slop to spam people. I saw this first on gobolinux, then on prawn, then on the ffmpeg mailing list. There are really good reasons why many humans dislike the proliferation of AI slop spam.
> Haiku in particular is a very low-velocity project and AI could help them so much
I am not entirely certain about that. If AI were to work so well, Haiku-AI could have already been insta-spawned and auto-fixed everything. Clearly this does not work, so I am unconvinced that AI is the final solution to everything - at the least right now.
What is also unfortunate about Haiku is that things such as ruby do not work by default. Ruby even works on windows, though on Linux it is much more convenient to use.
No one is trying to get rich from working on Haiku. They are doing it for fun, as a passion project. Sure AI would help with velocity but velocity is not the only goal. Journey before destination.
Also: Open source is about relationships.
Reviewing code sucks. However at least reviewing code from humans allows you connect and learn from each other. You get to mentor someone. Build a relationship and trust. They learn and grow and maybe someday can also review other people's code.
Nowadays with lots of low effort merge requests and spam it is already easy to burn out. Now add AI. Yeah, no. Why should anyone review AI slop for free. Why? It is the prefect solution to burn your contributors out.
In my case, my ThinkPad X1 (Yoga 3rd Gen) used to boot despite what appeared to be kernel panics, but typing "continue" at the kernel prompt would skip past them and everything would then work fine. In Beta 6, it now hangs at boot instead with no kernel panic warning. Disabling ACPI in the safe mode options gets me past that, and there's a way to disable ACPI permanently at boot via some configuration files - though obviously that isn't desirable.
It also seems there's been some work on USB Audio (yay!), but it now causes a kernel panic on boot if a Focusrite Scarlett is connected. Turning the Scarlett off avoids the kernel panic. The Scarlett has never officially worked in Haiku, but it at least never used to crash the system. In my case, I've reverted back to the USB Audio Scarlett Haiku driver that Claude Sonnet vibe coded for me, and for me that's working. (I can't contribute that code because of Haiku rules against AI code, but hopefully the humans will eventually find time to hand code it and get it working.)