[haiku-development] Re: What's the status of Haiku?
- From: Sia Lang <silverlanguage@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 18 Aug 2014 18:07:36 +0200
On Mon, Aug 18, 2014 at 5:19 PM, Stephan Aßmus <superstippi@xxxxxx> wrote:
>
> You have the benefit of hindsight. First of all, there were indeed some
> technical reasons -- ports, inode ids in entry_ref, ... there was more, but
> I am no kernel guy. And it was believed that having to maintain a patch set
> on top of the Linux kernel would be too inconvenient. There was the
> argument of being in full control of everything top to bottom. And the
> Linux source code itself is probably in a much better state today than it
> was in 2001. It is probably still ugly and cryptic in many places compared
> to Haiku. Though I don't really have a clue.
>
> Anyway. If you keep going, you will probably stumble across some of the
> reasons why Haiku went with its own kernel. Maybe all of it can be worked
> around if binary compatibility is not your goal. (Personally, I think it
> doesn't have to be.) Who knows, maybe the Haiku project is prepared to
> switch kernels once you are further along?
>
Whatever the reasons were back then, I've come far enough to reach this
important conclusion: No patch needs to be maintained, and you can easily
draw a "don't cross this line" at the kit->kernel/composer transition layer
(not without tricks, but they're completely self-contained in a kernel
module). Hence, you can still use the C++ toolchain with EH runtime support
and all that. There are no "upstream issues" since there's nothing to be
patched.
Unsurprisingly, the same would be true for, say, a FreeBSD kernel.
Anyway, the proof is in the pudding, so let's go to work ;)
Sia.
Other related posts:
