The distortions in maps with non orthogonal axes are evident already looking at Europe (though with centering at Greenwich). So, not just the "Map of America (of the Americas)" or "Map of Australia"... The compromises are just everywhere. Of course.
(Yes, I get what you meant. I am just suggesting other angles.)
Software had always been one big project with a dedicated team to build something one off, like building a hospital. Every customer commissioned their own software.
Microsoft recognized that the future was writing smaller software that was meant to be sold to many, many people for less money each.
What fragmentation? Find me a 64 bit RISC-V chip you want to run Python on that will not execute an RV64GC binary.
The issue is not fragmentation but ecosystem maturity. The exact same situation exists for all chips.
In most x86-64 Linux distros, CPython will be compiled to target x86-64v2. This means it will not use, for example, any of the latest vector math extensions that the x86-64v4 chip you are probably running is capable of.
The reason distros target the older profile is that not everybody has the latest hardware. There is no difference conceptually between x86-64 and RISC-V.
The difference with RISC-V is that RV64GC is more primitive than x86-64v2 and so it hurts more. And fewer people have RVA23 capable chips than have x86-64v4 chips. RVA23 is the RISC-V profile that describes essentially equivalent capabilities to x86-64v4.
But there is less RISC-V hardware in the wild in general. So, there is less legacy baggage to carry forward. RISC-V will go mainstream on a more modern profile than other chips.
Ubuntu 26.04 and newer require RVA23 support. And all new application class RISC-V processors will support RVA23. It will not be long before this is the standard RISC-V profile. It will probably happen before the x86-64 world standardizes on x86-64v4 (or even v3). So your “fragmentation” will be a bigger deal on x86-64 than on RISC-V.
But, today, projects like CPython are still using RV64GC level hardware. So, that is what they target.
Most of us do not have any desktop or server class RISC-V hardware. When we do, it will be capable of RVA23. And CPython will probably target that profile. Fragmentation has nothing to do with it.
Great point. But QEMU is no longer faster than real hardware for the latest RISC-V chips.
You are right though that QEMU is probably faster than anything only capable of RV64GC (lacking RVA23). So QEMU would probably be a great option for the CPython team.
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.
The problem is, Linux is improving too quickly for Haiku.
I have been looking forward to running Haiku as a daily driver for years. And it is almost there. It may even be good enough now for many people. Modern browsers really help.
But I was amazed recently when I put Haiku on an old laptop that was already running Linux. I remember Haiku being so lean and fast and multi-tasking so smoothly. But honestly Linux felt faster on this machine. The memory usage was about the same (a real shock to me). And I missed being able to use containers. So, I ended up putting Linux back on.
This bummed me out because I have been a Haiku fan forever and it has never been better. But when I tried to use it, I could not convince myself there was any benefit (other than diversity). And the reason had nothing to do with applications or drivers.
Cosmoe and VitruvianOS are two different approaches of "Haiku" you may find interesting.
Cosmoe works at the application toolkit level, allowing to build and run BeOS/Haiku apps on Linux. The toolkit is then implemented using Linux classic APIs.
Vitruvian is Haiku on the Linux kernel (with some extra modules).
> The problem is, Linux is improving too quickly for Haiku.
Ain’t it the truth. It’s really great now the snowball is fully in flow down the mountain with Linux. But at the same time it’s sad that there’s little time for anything else. We are a bit of a victim of our own success. We beat the drum in the 90s that Linux needs to win and now that it won what does it really mean. Free and open source to do anything but at the same time, why in the world use anything else. We have come a bit of a Chromium in that regard (or it became us?)
could you point them out? i actually did a search but could not find much. there are GTK themes, but nothing i could find that converts a gnome desktop. stuff is either incomplete or outdated. i actually managed to get half BeOS theme together for KDE, and i still use that on my desktop. but it's inconsistent, and in particular the tab style window management is missing, which is really the best part of the interface.
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.
reply