Groovy. I liked BeOS back in the day, but after it died, there seemed
little that could be done with it. I played with Haiku a bit, but again,
for practical use, it just isn't ready for prime time. It is, in my
opinion, a coder's project and will never catch up with the rest of the
world unless it piggy-backs on something else.
I would like to see a Haiku "desktop" running on Linux. Haiku verse as
responses would be a nice touch, but not really necessary. Most of us
blue-collar user types need stuff we can use, i.e.: the GIMP, LibreOffice,
Chrome or Firefox, maybe some of the old standbys like Mutt and Vim. We
also need to use scanners and printers and cameras, (oh my!)
This post looks kind of promising to me. It is, at least, a step in the
right direction. But then... what do I know?
On Wed, Jul 25, 2018 at 1:20 PM, Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
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 :