in July due to an attack of Real Programmer Syndrome, I started a fork of
Haiku with the aim of porting most of the userland to Linux and/or Zircon.
I planned to release it someday in the future, after summer, however today
I decided it is OK to share the code and most importantly the aims.
Sincerely I feel locked in a kernel that can't be maintained anymore
without having full time developers. The only way to ensure long life to
the BeOS heritage is ensuring an exit way.
Times changed. When Linus Torvalds started linux it was possible, today,
no. You need paid people or a countless number of contributors, or probably
I already expressed in past my issues with Haiku Inc., but today I think
this is a more general issue with the project.
So, I think the NewOS kernel is not worth anymore of being maintained. I am
not even going to discuss that with the Haiku developers, some people here
have put a lot of efforts in the kernel and will never accept that it is
replaced by something better. Additionally, there's really no technical
reason to state that linux can't work better than our current kernel.
Eventually, arguments can be done for the opposite hypotesis.
I think Zircon would be a way better replacement in the long term and if
they manage to get a decent hw support, but since I am a linux user, I
decided to take the code at Cosmoe and start from there. I will also tell
you that the Cosmoe kernel_kit implementation is better than I expected.
The main difference however compared to past attempts, is that my project
try to reuse as much code as possible and so maintain as much possible
compatibility with Haiku. This is done by reimplementing libroot on top of
linux. This allowed me, to port some parts of Haiku in a nice way, without
changing any code.
In the foreseeable future I will use V\OS to port some of my software to
linux. That doesn't mean I will not contribute to Haiku, it means any major
work of mine will be done on linux and then backported to Haiku,
eventually. Don't expect a complete product, unless more devs get on board.
I am not particularly interested in the app_server right now, but indeed
I'd love to have a framebuffer interface for it.
Status at the moment:
* Kernel primitives work (thanks Cosmoe)
* _basic_ fs functionalities work (we need to build an userland server to
support queries on top of extattr and solve the remaining open-by-inode
* Most important parts of libroot are stubbed to ease development
* Support, kernel, interface, locale, network kits compile correctly
* registrar and app_servers are ported and run, but without a working linux
backend at the moment. So, people who want to help is welcome.
Keep in mind there is a lot of work to do, but it is definitely possible.
The code is currently Alpha4 for obvious reasons. I am interested in
evaluating how we can transform the app_server into a local drawing
library, so that we can easily support wayland. The buildsystem is kind of
hacky, it needs to be replaced with the Haiku one for best compatibility.
This is the repository :