[prev in list] [next in list] [prev in thread] [next in thread]
List: openbeos
Subject: [haiku] V\OS Project Announcement (Haiku on linux)
From: Dario Casalinuovo <b.vitruvio () gmail ! com>
Date: 2018-07-25 18:20:33
Message-ID: CAKk25i6sFim2s5FkB-A6YcTkr4LRSvt4egWU+kvPy_B1nZnFWA () mail ! gmail ! com
[Download RAW message or body]
Dear friends,
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
both.
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
issues)
* 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 :
https://github.com/Barrett17/V-OS
--
Saluti,
Dario
[Attachment #3 (text/html)]
<div dir="ltr"><div>Dear friends,</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Times changed. When Linus Torvalds started linux it was \
possible, today, no. You need paid people or a countless number of contributors, or \
probably both. </div><div>I already expressed in past my issues with Haiku Inc., but \
today I think this is a more general issue with the \
project.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Status at the moment:</div><div><br></div><div>* Kernel \
primitives work (thanks Cosmoe)<br></div><div>* _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 issues)</div><div>* Most important parts of libroot are \
stubbed to ease development</div><div>* Support, kernel, interface, locale, network \
kits compile correctly</div><div>* 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.</div><div><br></div><div>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.</div><div><br></div><div>This is the repository \
:</div><div><div><br></div><div><a \
href="https://github.com/Barrett17/V-OS">https://github.com/Barrett17/V-OS</a></div></div><div><br></div>-- \
<br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div><span \
style="color:rgb(37,37,37);font-family:sans-serif;font-size:14px;line-height:12.8px">Saluti,</span></div><div><span \
style="color:rgb(37,37,37);font-family:sans-serif;font-size:14px;line-height:12.8px">Dario</span></div></div></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic