Haiku Alpha 3 has been in development for more than 14 months. In that time more than 800 bugs have been identified and fixed, major sections have been updated, applications have been added and updated, and great progress has been made in supporting additional hardware. Here is a summary of updates, more details can be found here. Also inside, interviews with some core Haiku developers.

"Lol, what seriously is a "modern" kernel. What's next a postmodern kernel?

Is that a serious question? "

Yes, that's a serious question. WTF is a "modern" kernel, and WTF is a "premodern" kernel when the few decades-long history of "modern" computer science reveals a recycling of old ideas "rehashed" as innovative.

Modern, lol. Also spare me the User ad hominem. Been doing this alot longer than you, trust me. That is the whole point of microkernel (no wait, nanokernel!, no wait picokernel!) design.. simplicity and correctness at the cost of performance (to an arguable extent).

Finally, I think you overestimate kernel development effort, probably because you are doing some hobby work in that area yourself? Compare the effort involved in the Linux kernel by any "engineering" metric (man-hours, SLOC) and it pales in comparison to projects in userspace. The hard "work" in operating system delivery is HAL/drivers. Plain and simple. Some people wanna call that kernel development, but we know better.

Take a step back from what you are doing before throwing around black-box terms like "complexity" unless you are prepared to discuss what that actually means because generally speaking the cyclomatic complexity of kernel code is (and should) be signficantly lower. But there aren't even real metrics to talk compare 2 bodies of code now are there? That is how haphazard software engineering is.

when the few decades-long history of "modern" computer science reveals a recycling of old ideas "rehashed" as innovative.

Riiiight....

Also spare me the User ad hominem. Been doing this alot longer than you, trust me.

Well given that I know nothing about you and you know nothing about me, I think I'll pass on that comment

That is the whole point of microkernel (no wait, nanokernel!, no wait picokernel!) design.. simplicity and correctness at the cost of performance (to an arguable extent).

Well, not exactly.
It's about modulising core components and then porting them outside of kernel space - the goal often being to eliminate kernel panics.

There's nothing more or less correct about a micro-kernel design. It's just a different way of tackling the same problem.

Finally, I think you overestimate kernel development effort, probably because you are doing some hobby work in that area yourself?

You like to make a lot of assumptions

Compare the effort involved in the Linux kernel by any "engineering" metric (man-hours, SLOC) and it pales in comparison to projects in userspace. The hard "work" in operating system delivery is HAL/drivers. Plain and simple.

Maybe for micro-kernels, but most OSs these days use hybrid kernels so that means that things like filesystem drivers do reside in the kernel.

Some people wanna call that kernel development, but we know better.

As above, that really depends on the kernel.

Take a step back from what you are doing before throwing around black-box terms like "complexity" unless you are prepared to discuss what that actually means because generally speaking the cyclomatic complexity of kernel code is (and should) be signficantly lower.

I'm not aware of what a "black-box term" means specifically, but given the context you used it in, I'd beg to differ.

I do think you're dismissing how complicated maintaining a -modern- current kernel that has been in production use for 10/20 years and is still evolving.

Particularly when most kernels in production use are not tidy little micro-kernels like you seem to favor

But there aren't even real metrics to talk compare 2 bodies of code now are there? That is how haphazard software engineering is.

What attracted me to programming is while there are better methods in terms of readability, scaleability and effeciency; there is not always a "right" way of coding a solution - much like solving maths equations.

So you might call it 'haphazard', but I call it 'inspiring' and consider it a charm.

What a stunninly useless term then. Thanks for the clarification. I would simply use the term "current" from now on as it is more clear. Most people use "modern" as a descriptive term and it has connotations with respect to design and form. See ("modern aesthetics", "modern science").

and WTF is a "premodern" kernel
It's something you made up.

Lol, so, how do we refer to anything before modern (whatever that is because current seems to change every couple of years? Also, what does current mean "currently on the market" or "currently developed" or ..?

That is the whole point of microkernel (no wait, nanokernel!, no wait picokernel!) design.. simplicity and correctness at the cost of performance (to an arguable extent).

Well, not exactly.
It's about modulising core components and then porting them outside of kernel space - the goal often being to eliminate kernel panics.

Um, that's exactly the same thing. I can see how you don't want to equate those terms I suppose.

There's nothing more or less correct about a micro-kernel design. It's just a different way of tackling the same problem.

I don't think I can continue responding to you further as you clearly haven't put much thought into what you are writing or don't share the terminology most people use to discuss these topics. You might want to read into the benefits of a trusted code base and a provable kernel for operating system security. Thanks for the comment.