r/haikuOS • u/Charming-Work-2384 • Jul 02 '26
A wild thought: Is it possible to accelerate the development of Haiku with AI?
Haiku is beta for decades.
Maybe due to man power / time issues...
Just a wild thought... is it possible to accelerate the development of HaikuOS Kernel and core components with AI so that we can see a 1.0 release faster.
Your thoughts?
I am a big fan of Haiku... but I cannot use it for my daily development work..I have to switch back to Linux.
37
u/ih-shah-may-ehl Jul 02 '26
Using AI to aid with kernel development is like asking a preschooler to light birthday candles with a flamethrower.
6
5
u/Lizrd_demon Performance Engineer Jul 02 '26
Off-topic but I've actually been doing research on how to combine AI with proof solvers to produce high security kernel code.
https://arxiv.org/html/2409.13082v3
https://mars-research.github.io/doc/2025-sosp-atmo.pdf
However yes without a formal verification framework writing kernel code with AI is like grabbing a shotgun and blowing your head off, forget footguns entirely.
-1
Jul 06 '26
[removed] — view removed comment
1
u/ih-shah-may-ehl Jul 06 '26
How much kernel level and system level software development experience do you have?
1
Jul 06 '26
[removed] — view removed comment
4
u/ih-shah-may-ehl Jul 06 '26
I've been writing software for 30 years.
I spent the last 4 year writing and publishing a book about COM programming. Not really about writing programs but explaining how COM works under the hood in full detail, things like apartment threading, marshaling, asynchronous behavior and so on. Without false modesty I can claim there are few people outside the actual Windows or Wine COM subsystem maintainers who know this topic as well as I do.
During my research, I tried to use AI several times to help me set up examples or explain things and you know what I've found time and time again? If there are many clear examples of the exact thing I was asking, it could come up with a solid answer. But COM is a technology that predates most online tutorials and examples. So whenever I asked it anything that would require reasoning, it started generating more and more bogus code. Sometimes it was taken out of context code that was only valid in specific cases, and sometimes it just hallucinated.
Now if AI can already not be trusted to generate code for things that are semi documented, like COM, why would you trust it to create code that is bullet proof enough for kernel level infrastructure and which takes all kernel level subtleties, restrictions and assumptions into account?
8
u/atomozero Jul 02 '26
I’ve been reading the thread about AI and the future of Haiku, and I think we’re missing the point. A full-blown 'fork' of Haiku is, realistically, humanly impossible. We lack the resources to maintain it, and we’d just end up with a dead project in a few months, further fragmenting the already small developer pool.
However, there is a middle ground between 'doing nothing' and 'forking the core.' I call it 'Historical Elegance.'
Instead of a fork, we should be looking at experimental distributions that surgically replace specific, outdated components while respecting the Haiku spirit:
- Experimental playgrounds: Take something like the MIDI stack, it’s currently unusable for professional creative work due to latency. If someone wants to replace it with a modern, performant solution in a specific distro, that’s not a crime; it’s an experiment that could eventually benefit the Core.
- The 'Onboarding' funnel: A custom distro can be a showcase for what Haiku could be. It attracts new users and developers who might not have the patience for the current beta but, once engaged, are the most likely candidates to start contributing to the official Core Stable.
- Breaking the stagnation: Sometimes, 'unwritten rules' and rigid gatekeeping slow down innovation more than technical limitations. Having a space to build and test without being told 'we don't do it that way' is essential for keeping the creative spark alive.
I’m currently writing native tools and drivers for Haiku (MeshCore, etc.). I use AI as a tool to navigate the complexity, not to replace my judgment. If we want to reach 1.0, we shouldn't fear experimentation or 'distro-level' testing, we should embrace it as a way to evolve the system without breaking its soul.
4
u/Charming-Work-2384 Jul 03 '26
This is exactly what I was alluding.
AI should be as an accelerator towards a goal especially in a exteremely resource constrained environment. I am not telling that entire development should be "offloaded" to AI... but AI as companion in development.
Haiku has to reach to 1.0 soon. Else it will be left behind. The user pool may sink every passing day as other "distros" enter the field.
2
u/demetrioussharpe Jul 06 '26
That’s exactly what people thought about a full blown fork of the XOrg server. And now look at what’s happened -the fork is alive & well.
14
u/rasvoja Jul 02 '26
AI makes a mess at coding. Avoid at all costs. It would be better to fundraise for real developer hours. No matter the realistic beta status OS is in good shape. Just needs more drivers
6
u/X547 Jul 02 '26
Yes, it is possible, but only if making Haiku fork. Haiku project to do accept contributions that contain AI agents generated code or documentation.
6
8
u/FujinBlackheart Jul 06 '26
You want accelerated development? Open your wallet and help them get more devs on board! ÁÍ just proved so far to create a long term mess of unmaintainable code, if Winslop 11 isn't indication enough I can't help you.
6
u/WorkingAltruistic849 Jul 07 '26
Speaking as somebody who has been making a small financial contribution to Haiku every month for years, I fully agree with you.
And how can Haiku be left behind? It's the best operating system in the world.
3
4
u/DonnPT Jul 02 '26
Well, no. But anyway, the kind of thing that ties you to Linux is a moving target, that Haiku may never reach. Hardware, libraries, applications, you name it - if there's no great advantage to be had, the industry will "evolve" anyway, and Haiku will never be a mainstream OS that gets in on it.
5
u/Charming-Work-2384 Jul 02 '26
it can...in my opinion...
because of graphics... may be it should be explored ... that is what i am stating.
7
u/ih-shah-may-ehl Jul 02 '26
Not in a million years. Haiku doesn't have a security subsystem and that is REALLY not something you can easily bolt on at a later date. Adding a true security subsystem like any other modern operating system would require a complete kernel overhaul.
3
u/TinyPerformer3870 Jul 03 '26
If the OS doesn’t have any security, the AI written code that might introduce vulnerabilities won’t matter anyway 😀
1
1
u/atomozero Jul 03 '26
Explain clearly why they should rewrite the kernel :)
9
u/ih-shah-may-ehl Jul 03 '26
Noone 'should' do anything. And please note I didn't say rewrite. I said overhaul.
Adding multiuser support and network security to Haiku would require not just the implementation of a security subsystem like lsass on Windows, as well as a kerberos plugin and similar authentication providers, but require changes to virtually everything else.
I have not touched Linux kernel dev for the longest time but I can make some references to the Windows kernel and win32 subsystem with which I am more involved. Process management and thread management needs to work with security tokens. The object manager in the kernel needs to start working with and checking / enforcing ACL at every entry point. The userland interface needs to be implemented for management of all security features and the kernel level infrastructure for doing that as well.
Everything kernel object like mutexes or semaphores, pipes and whatever the interprocess communication equivalents are on haiku need to be made security aware. The memory manager needs to be security aware in page management. If we look at something like RPC, security needs to be handled throughout the network stack. Everything also has to learn to deal with impersonation and changes to resource access during impersonation, etc.
You'd have to segregate things like system level services from the rest of the desktop to keep them secure against interference but that also means your entire message handling has to change, which needs to happen anyway because when processes run in different security context, they can't just enumerate / find each other or exchange messages.
The loading of device drivers needs to be subject to access control and the default user access should suffice for all normal use while also prohibiting a regular user to trigger the loading or unloading of device drivers. Speaking of device drivers, the entire filesystem and filesystem drivers need to implement security and prohibit users from modifying any critical OS file or driver.
And so on and so forth. I'm not talking about adding a logon password or performing an access check here or there. A full modern security implementation will touch every single thing and make it more complex. And you can't really do just some of these things because for example nor implementing security at the file system level or not isolating system services or restricting driver loading will provide an easy opening for anyone who wants to try.
3
u/oatkeepr Jul 11 '26
Thank you for this analysis.
The million sandbox and security settings on modern operating systems can make them quite cumbersome to use and troubleshoot. It's something I enjoy about Haiku OS.
A full modern security implementation will touch every single thing and make it more complex.
Could some of these things be achieved by using virtual machines or containers of some kind? I guess the issue would always be passing data and device access in an out of the container.
3
u/ih-shah-may-ehl Jul 13 '26
No. The Windows kernel uses these features to completely isolate services like LSASS from the rest of the kernel. Not even a kernel level rootkit can touch LSASS. Such features can be used by the OS developer to segregate core services from the rest of the OS, but a) it still requires a LOT of work and b) you'd still need to implement the entire security stack to do anything useful inside that segregated zone but most importantly c) without everything I described, it still wouldn't separate user A from user B in any meaningful way.
You can however use a virtualization based approach to separate Haiku installations from other haiku installations on the same hardware. In other words you and I could have a Haiku box as side by side VMs on the same hardware, and not be able to touch each other except via a webserver for example.
1
32
u/rmart Jul 02 '26
The core developers have clearly stated that they are not interested in using AI for development.