Hello there! I have also been working on this, and joined the forums to let you folk know. I am focusing on having reproducible builds (which is where automation is really handy), and have been poking at a build harness over at GitHub - rcarmo/haiku-arm64-build: Build environment + automation · GitHub - my goal is to get this running fully automated so that I can then deal with uboot and the actual hardware layer (which is where I usually have the most fun), and thanks to @smrobtzz ‘s initial patches I got a few working QEMU builds, but, again, I want to make this fully reproducible, and once I’m happy with the process I’ll start churning out automated builds for .qcow images somehow.
hi @rcarmo, welcome to the forums.
I’m currently a bit suspicious about your work not being compatible with the policies of
Haiku ( Policies | Haiku Project ), which practically forbid merging any work done with an LLM or similar stuff (see copyright policy).
However, the repo’s header image seemed a bit odd to me (i.e. the pin header having a bend in it) and the use of checkmark emojis in the Makefile are something I seldom see in non-LLM-generated code (of course, there are some exceptions there). I thus have the suspicion that at least part of the assets and code might be generated. LLM “assisted” code can’t be commited to the tree AFAIK.
Of course my suspicion might be totally unwarranted, in which case I’d take any kind of accusation back and give my sincerest apologies
1 Like
Yes, the images are AI-generated, according to a very specific set of styles I have, and yes, I do use AI for code generation, audits and more (you can check my blog at taoofmac.com for more background, including the frameworks I use to guide agents and the quality control and manual revision steps I use). And I happen to have plenty of proof points that it works very well given the proper guardrails and audits
If Haiku has a policy against it, then I have to say that banning modern AI models on the basis of copyright is a fundamental misconception of how they work.
I will, regardless, continue working on this, because I do love the platform and ARM SBCs. And I am perfectly OK with my code - even if it is at this point essentially scaffolding and automation) not being merged back into Haiku if you don’t want any sort of AI assisted coding - my views on that are very simple: it’s a lever, and you need to know how to use it - and, I hope, reassess fundamentally incorrect takes on it.
As an anecdote, this is very familiar to me. Some ten years ago I came here and tried to discuss support for the Raspberry Pi, only to have a bunch of replies saying it was Broadcom proprietary hardware and that it was never going to go anywhere. Well…
6 Likes
As a Haiku user and a vibe coder, I really appreciate the work that you are doing. 
Keep up the good work! Many people are rooting for you!
3 Likes
uh, yeah, not really…
There was enough discussion on that already. There are too many code quality problems and even more ethical problems tied to LLMs that I don’t want to have to recount
Besides that, I now know at least one place that has adopted Haiku as a public system exactly because Haiku holds this position and some people that are considering this system because of the no-LLM policy. I’d argue that’s a good thing
At least consider not posting work that you do on Haiku itself that is fundamentally unmergable on the forums. That just potentially jeopardizes actual development
3 Likes
It can be posted in the right category just fine.
Stop discouraging people doing what they like, just because you don’t like their tools.
3 Likes
It’s definitely important to point out that we currently don’t accept any AI generated code on the basis of possible license infringement.
But it’s nice to know that we have a fundamental misconception of how they work…
3 Likes
We already have automated builds, so I wonder what you are actually trying to achieve.
1 Like
The official wording is very precise. If you want to get LLM assisted code upstream in Haiku, you have to do the work to show that your LLM didn’t accidentally generate code that is too similar to something from its training database without attribution, or code that is under a license incompatible with the MIT used in Haiku. That is, of course, in addition to making sure you fully understand the code you are submitting. I would say this is the same as when you write the code yourself, but it is significantly harder to achieve that when the code is generated and you didn’t carefully think about each line of code when writing it.
We are not willing to do that work for you. We have already enough work to do for code reviews of patches made by humans.
While I would prefer a stricter ban (and I think some other developers also do), there isn’t a full agreement on that in the development team. What you risk is a few developers not being interested in reviewing your code. I will let the people who think LLM generated code is mostly OK and shuld be allowed (with appropriate guardrails, of course) handle it, if it gets submitted to Gerrit for review.
1 Like
I think people are missing the point, probably because they didn’t even read the docs: I am automating the drudge work of building an automated pipeline for a specific SBC that I want Haiku to run on. I know what the thing is doing and why (and have a parallel 9front repo to test u-boot separately with a kernel I know, because bring up is huge pain with proprietary blobs, etc.). Zero actual Haiku code was touched other than scaffolding and what was needed to appease the tool chain.
But, like the Raspberry Pi discussion I was in a long time ago, I am disenchanted by the reactions. Haiku could be much more popular… I’ll come back again in another decade and check in on progress, and just keep at my hobby SBC projects. If I get it to boot, I’ll update the repo.
6 Likes
It’s not about my personal opinion. That would have been a lot harsher.
However, as far as I understand, it’s against a policy (just like it would be to copy something from the linux kernel (which has an incompatible license)). Maybe it would make sense to point towards the policy page in the pushing patches to Haiku 101 page, as I find that page pretty easy to miss
Let not start a another AI debate instead let see how we can improve the actual Arm64 support rather than a AI debate
3 Likes
from what I could tell, this stricter ban is actually the public perception I I don’t see how this could be bad in practice - should such a rule prove bad in the long run, it could just be reverted. The other way around would be much more difficult if not impossible
Anyways, that probably is a discussion for which the mailing list is better suited and I don’t want to derail a thread again
Anyways, I might just be confused, but shouldn’t the orange pi work with just the stock images? At least from what I could tell, the OPI6+ should have uefi support. Or have I understood something wrongly?
I think what is referred to here is the early Raspberry Pis which were unusual for using ARMv6. We decided at the time to not bother supporting that and focus on ARMv7 (still not working) and ARMv8 (also known as ARM64). As far as I can see, the ARMv6 based Raspberry Pi models (the first model A, B, A+ and B+) remain and will remain unsupported. Starting from the Raspberry Pi 2, they use an ARMv7 CPU, which is considerably easier and more standardized. And, of course, ARMv8 is even better which is why it the first one where we finally manage to boot to the desktop.
There is still no reason to spend any more time supporting the old, quirky ARMv6 hardware, or at least no more than there is for PowerPC, m68k and other legacy architectures 
1 Like
Not now, but ten years ago you still missed an opportunity to have a lot more popularity.
1 Like
Yes, if you had Haiku versions from now 10 years ago, it would have beren much more successful.
This is true at any time in the history of Haiku. Unfortunately, developping an ARM port takes time and required fixing many problems. It’s a good thing the focus is/was on ARMv8, so it is useful now, rather than on ARMv6, which is a dead architecture no one cares about today. Otherwise, we still wouldn’t have a working ARM port at all.
5 Likes
That atleast already exists: GitHub - haiku/rune: Haiku MMC image writer for ARM,ARM64 · GitHub
I think you do not get the real problem. The LLMs are trained on vasts amounts of data, which they acquire on the internet, including potentially proprietary code (e.g. Microsoft Windows Code leaked multiple times in the past, but also a lot of open source code under for example the GPL, which is incompatible with Haikus MIT Licence)
Copyright Infringement Lawsuits are very time consuming and cost lots of money, if some LLM produces code very similar to for example microsoft Code and we integrate that into Haiku this could ruin and bankrot the project, i think we will see a lot of lawsuits in the next years.
This is not much a problem if a vibecoded programm is running on haiku, but ich the code becomes part of haiku itself it could be a problem.
I hope i was of help in understanding the problems ( as much as i want haiku on raspi;) )
2 Likes
I was referring to this comment:
At least consider not posting work that you do on Haiku itself that is fundamentally unmergable on the forums. That just potentially jeopardizes actual development
It’s perfectly fine to post about AI stuff, as long as it’s posted in the right forum category.
That was about “AI” stuff for 3rd-party software iirc. This thing was aimed for Haiku’s development itself. I understood that this is unmergeable. If you post this on the forums and someone else uses it as a basis for their development work, assuming that it can be merged could waste quite a bit of development resources imo. I’d consider it nice to just not do that.