하이쿠는 시대를 따라잡지 못했다

The port is mostly stable and all of the usual QEMU devices (virtio SCSI, virtio net, xHCI USB) as well as up to 8 core SMP work as expected. Though there is at least one kernel crash and some double frees that need to be worked out. There are also still some issues with software ports that need to be resolved, for example: I mean Haiku upstream. You may need to enable some extra features (e.g. the acpi add on and the zstd package) in the bootstrap image to get it to boot though Awesome Work! I was wondering if you using cli emu or UTM which is using emu? Maybe worth creating an UTM image for easy download/install when things mature a bit? Actually I do not onw any arm64 device – any Apple M* or an SBC/laptop/keyboard computer with ARM64 CPU –, but I followed the patches from curiosity, so I was interested what is your status. Seems arm64 attacked from 2 sides right now –> first @dodo75 reported a running instrance on the forum, he targeted an RPI 500+ device –> and now you have a running Haiku 64 bit in QEMU (arm64) - targeted Apple M* machines. Interesting … Wether these 2 development would be meet ?.. … or as vendors and architectures are different, so there will be 2 different install image for ARM64 Haiku ? I successfully “re-bootstrapped” the base package set and updated it in the build-packages repository. So after hrev59644, the ARM64 nightly images should (I hope) boot to the desktop in QEMU. At least I built a @minimum-mmc image and it booted for me: 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 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… 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