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

▲

LeFantome 4 hours ago | parent | next [-]

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.

▲

tikhonj 2 hours ago | parent | next [-]

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

▲

0x1d7 2 hours ago | parent | prev [-]

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

	▲	selectodude an hour ago \| parent [-]
		Makes sense. I had codex port haiku to arm64. Works decently, fun to play with on my Mac.

▲

jessikat an hour ago | parent | prev | next [-]

Feel free to reach out, I will be happy to try help with these issues :)

	▲	SyneRyder an hour ago \| parent [-]
		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.

▲

KerrAvon 3 hours ago | parent | prev [-]

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.

▲

LeFantome 3 hours ago | parent | next [-]

I imagine that their issue is reviewer bandwidth.

If all submissions were high-quality, it would probably work. But that is probably unlikely.

Maybe the project could host a searchable directory of AI contributions hosted at external GitHub repos or something.

	▲	SyneRyder 29 minutes ago \| parent \| next [-]
		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.
	▲	hvb2 2 hours ago \| parent \| prev [-]
		> I imagine that their issue is reviewer bandwidth. This feels to me as the real bottleneck in general. Maybe along with thinking through what to code/prompt. I don't need more tokens or automated generation of PRs, I'm already at capacity for the care and understanding I want to have for code I own.

▲

cardanome an hour ago | parent | prev | next [-]

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.

▲

shevy-java 3 hours ago | parent | prev [-]

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.