Hi everyone,
Some of you saw the SanpOS 1.1 announcement. SanpOS is a 64-bit (ABIv11) AROS distribution that I'm building for low-cost, silent workstations, mainly schools and labs. It will be free and open source.
Running it daily on real hardware showed me that the biggest gaps in AROS are in the low-level stack. Modern PCs ship hardware that AROS mostly can't use yet. So I'm planning five milestones, each one a separate piece of work and each tested on real hardware:
M1: Modern OpenGL. I'm moving from the Mesa 20.0.8 in the current tree to a recent Mesa (26.2.x). The aim is working accelerated or software GL for current applications. I already have Blender 2.49b running on SanpOS, and a newer Mesa is the next step for graphics-heavy software.
M2: Vulkan. It builds on the M1 work. The first goal is a loader plus a software-capable driver so Vulkan applications can start at all. Hardware drivers come after that.
M3: xHCI (USB 3). Many current machines and mini-PC boards have no usable USB 2 ports for keyboards, mice and storage. This is the milestone that decides whether SanpOS boots usably on new hardware.
M4: Bluetooth. A driver for Intel AX200/AX210 combo cards, the most common modern Bluetooth module. The first goal is keyboards, mice and audio.
M5: Wi-Fi. The same AX200/AX210 family. A silent school workstation needs working wireless.
Alongside these I keep working on desktop pieces (Wanderer toolbar, theming, launcher), but these five are the foundation.
What I need from you. If anyone has worked on AROS USB, PCI, Bluetooth or Mesa/Gallium, I'd like to hear what you've tried, what failed, and what to avoid. Test reports on real hardware (not only VMs) will be useful once the first builds exist.
I'll post progress as each milestone moves. Nothing here is finished yet and I'm not giving dates.
You really should read through the last three weeks of "This Week in AROS" plus Deadwood's "News from AROS commit log!" ( https://www.arosw...post_14901 ), then talk to Deadwood and Kalamatee, if you can
Are you on the developer Discord
I'm just saying this as that's a duplication of work We have Mesa 26, USB 3, Bluetooth (recent development WIP), etc
Also, check out my posts in the Hardware forum It's post on testing the later developer releases of the ABIv11 release That was two and a half months ago. USB 3 works great, and there have been many developments since then
What hardware are you testing on, and/or are you targeting (specs and/or brand and model)
Thank you very much a wifi board is appreciated and I appreciate your work and that of all the new developers, I am a user who has been using AROS since there was Icaros Desktop
Edited by Amiwell79 on 01-11-2026 03:54, 1 day ago
I've been reluctant to comment because I believe everyone should be free to experiment with AROS. I joined this community only a few weeks ago, sharing similar updates about my own projects, but eventually started questioning my approach.
I think we should ask ourselves more often: "So what?" What problem are we solving? What does this enable? How does it fit into what's already there?
Any answer is fine, even if you're experimenting just for fun or showing off. But there's a difference between making something run on AROS and moving AROS forward. Especially now, when AI makes it easy to build software without understanding the existing ecosystem.
Take SanpOS and its goal of providing low-cost, silent workstations for schools and labs. Why would someone choose it over Linux? What hardware are you targeting? How will you ensure compatibility and long-term support? And what's the actual plan for Mesa 26 and Vulkan, given that GPU drivers and graphics subsystem integration are still needed?
One final thought: ports are valuable. I've ported ArtCraft applications myself because it makes more sense than rewriting them. But there's a difference between making AROS more capable and giving people a reason to choose it. I think we need more original software and experiences that make AROS worth using in the first place.
I've been trying to apply the same thinking to my own work. For example, porting Helix wasn't just about getting another editor running. It was also a way to identify limitations in AROS's POSIX compatibility, threading, and terminal support, and contribute fixes back to the platform. The port itself was only part of the goal.
Edited by coffeecat on 01-11-2026 09:32, 21 hours ago
Fair questions, coffeecat, and I like that you asked "So what?" instead of scrolling past.
Why AROS: I love Amiga-style systems, and I never got on with Linux distros. I wanted something that behaves like an Amiga, and AROS is exactly that. That's the honest reason I'm here.
What I'm aiming for: under-the-hood improvements rather than just ports.
Mesa 26 and graphics: you're right, the GPU drivers and graphics integration are the hard part. I'm working on Mesa 26 on Deadwood's build, and it isn't working yet, so I won't claim it is. I'll report back when it is.
Hardware: it will vary, and I'm not going to name targets until I'm 100% sure which metal I'm committing to. I'd rather announce something real than promise something and walk it back.
As for why someone would choose it over Linux, I agree that's the real test. I'd rather answer it with working software than with claims.
This was committed last week The previous Mesa version was 26.0.0 Before that, the version was Mesa 20, which shipped with the AROS 64bit ABIv11 release in September
Have a look at Deadwood's "News from the Commit Log!" post that summarizes months of additions that finalized the ABIv11 release That includes not only Mesa, but xHCI (USB3), and Bluetooth https://www.arosw...post_14856
Here is were I report my logs from booting the D5 development pre-release ABIv11 build on my shop PC (Ryzen 5700X, Radeon 5700XT, 32Gb RAM) booted from a USB3 stick
All my devices were recognized, even if there are not drivers for all of them https://www.arosw...post_14048
You've put a lot of great work into SanpOS and have a good idea of what you want it to be Though it doesn't seem crystal clear yet Like the others, I'd hate to see you put effort into your project on parts that already exist, as part of the Core or 64bit ABIv11 branch
@coffeecat - I've been reluctant to comment because I believe everyone should be free to experiment with AROS. I joined this community only a few weeks ago, sharing similar updates about my own projects, but eventually started questioning my approach.
I think we should ask ourselves more often: "So what?" What problem are we solving? What does this enable? How does it fit into what's already there?
Any answer is fine, even if you're experimenting just for fun or showing off. But there's a difference between making something run on AROS and moving AROS forward. Especially now, when AI makes it easy to build software without understanding the existing ecosystem.
Take SanpOS and its goal of providing low-cost, silent workstations for schools and labs. Why would someone choose it over Linux? What hardware are you targeting? How will you ensure compatibility and long-term support? And what's the actual plan for Mesa 26 and Vulkan, given that GPU drivers and graphics subsystem integration are still needed?
One final thought: ports are valuable. I've ported ArtCraft applications myself because it makes more sense than rewriting them. But there's a difference between making AROS more capable and giving people a reason to choose it. I think we need more original software and experiences that make AROS worth using in the first place.
I've been trying to apply the same thinking to my own work. For example, porting Helix wasn't just about getting another editor running. It was also a way to identify limitations in AROS's POSIX compatibility, threading, and terminal support, and contribute fixes back to the platform. The port itself was only part of the goal.
My personal view we need distributions targetting different interests and groups. I like the idea of targetting schools and university, perhaps another distribution targetting kids, another one optimized for work / serious stuff. There might be other ideas too
@coffeecat - I've been reluctant to comment because I believe everyone should be free to experiment with AROS. I joined this community only a few weeks ago, sharing similar updates about my own projects, but eventually started questioning my approach.
I think we should ask ourselves more often: "So what?" What problem are we solving? What does this enable? How does it fit into what's already there?
Any answer is fine, even if you're experimenting just for fun or showing off. But there's a difference between making something run on AROS and moving AROS forward. Especially now, when AI makes it easy to build software without understanding the existing ecosystem.
Take SanpOS and its goal of providing low-cost, silent workstations for schools and labs. Why would someone choose it over Linux? What hardware are you targeting? How will you ensure compatibility and long-term support? And what's the actual plan for Mesa 26 and Vulkan, given that GPU drivers and graphics subsystem integration are still needed?
One final thought: ports are valuable. I've ported ArtCraft applications myself because it makes more sense than rewriting them. But there's a difference between making AROS more capable and giving people a reason to choose it. I think we need more original software and experiences that make AROS worth using in the first place.
I've been trying to apply the same thinking to my own work. For example, porting Helix wasn't just about getting another editor running. It was also a way to identify limitations in AROS's POSIX compatibility, threading, and terminal support, and contribute fixes back to the platform. The port itself was only part of the goal.
My personal view we need distributions targetting different interests and groups. I like the idea of targetting schools and university, perhaps another distribution targetting kids, another one optimized for work / serious stuff. There might be other ideas too
Distributions are fine… the issue arises when we have people reinventing the wheel multiple times with various levels of compatibility. It becomes worse once we’re recreating what’s already been created in mainline because they alternative might not be compatible with what’s being worked on elsewhere. So you don’t end up with multiple implementations you end up with incompatible applications because they depend on different implementations.
You can view all discussion threads in this forum. You cannot start a new discussion thread in this forum. You cannot reply in this discussion thread. You cannot edit the poll in this discussion thread. You cannot vote on the poll in this discussion thread. You cannot upload attachments in this forum. You cannot download attachments in this forum.
ArgoMember
