Nice, that’s good programming, but who is going to use Haiku?
This type of cross ‘contamination’ never goes anywhere, even Debian tried it twice, once with a BSD kernel, & once with the Hurd kernel, & if they couldn’t get interest, I doubt anyone could.
What Haiku sorely needs are native programs of the kind that other O/S have…
Adding compatibility layers will just slow down Haiku, & it’s that speed that is the attraction of Haiku; that & the amazingly quick installation procedure.
I really don’t get why people hate Haikus kernel so much that they randomly try to replace it with some Unixes.
And no,I honestly don’t think this is a good idea.
I understood the idea when it was about the Linux kernel.
I mean,personally I wouldn’t touch anything related to Linux,but I have to admit that they have better hardware support compared to Haiku or any of the BSDs.
NetBSD,on the other hand,boots on only one or two of the dozens of devices I own,while Haiku does at least boot,with some lack of drivers for some parts.
Haiku and it’s kernel are making great progress and with support for both FreeBSD and OpenBSD network drivers,Haiku does already support a lot more devices than NetBSD.
I mean,I like NetBSD,it’s fun to play around with it on a raspberry,the only device I could get it to actually boot,but I think it’s much further away from being stable for daily work,compared to Haiku.
This layer adds code in NetBSD to be able to recompile Haiku applications to run on NetBSD. I don’t see how this can possibly make Haiku slower, since nothing changes in Haiku here. It just means people writing native apps now have more options to run their apps.
It is very far from being complete, at the moment it only adds libroot. I don’t know what the plan is from there, maybe once they have libroot, the other parts of Haiku can just be recompiled on top of it, or maybe they will need more invasive changes.
It seems to be the opposite: they love the userspace so much that they try to run it on their favorite kernel. Why frame it in terms of “hate”? This is just one person having fun with their own project. We should welcome such thing and appreciate them for what they are (just someone finding that we have some nice software here and trying to use it in different ways).
If anything, we will learn more about how far this can go, how it performs, and if we find it is 10 times faster… well we will know we have more work to do on our kernel.
I don’t see how making native Haiku apps run on NetBSD would prevent people from making more native Haiku apps
Indeed Debian tried this and failed.
However: NetBSD tried this and already suceeded in the past. You can run Minix 3 as the “core” for NetBSD, and this will work giving you a reliable microkernel. : D
This part seems really really wierd to me. NetBSD is not primarily a desktop OS, so why try to judge it as if it were one…? It’s used quite sucessfully in a lot off applications on the top of my head that is stuff like embeded, and sound systems for festivals.
EDIT: This is also way more akin to how wine works or the FreeBSD linuxkpi layer, both of which work fine and serve the purpose to run applications from another OS in addition to your native applications.
I am delighted to see more opportunity to use Haiku programmes elsewhere as it enables newbies to ease themselves into Haiku from the comfort of their own OS. I am not convinced there is a massive pool of potential Haiku users in NetBSD waiting for an easy migration path, but I may be wrong. And presumably from there is would be easy to make it work for other UNIX derived systems like Macintosh and Linux.
Personally I am more interested in opportunities to migrate forward rather than back to 1970s UNIX paradigm Regular readers will have heard me banging on about it before but the compatibility layer for Genode enables our programmes to work on that microkernel powered, “capability based” piece of German software engineering.
Of course best of all is that Haiku has paths both forward and backwards. Being quite small, perhaps we are analogous to Switzerland, neutral territory that has to get on well and trade with all its neighbours?
Well, whatever floats their boat, and good luck.
Why, though? It’s not as if there is a vast codebase of native Haiku apps that can be recompiled on BSD and give them functionality they don’t already have. If that was true, we wouldn’t have been porting GTK and KDE apps as fast as we could. Tracker is the nicest file manager I’ve found on any OS, but it’s not as if BSD doesn’t have any file managers.
It makes sense. The Linux and BSD distros have never had a consistent and stable GUI like other operating systems have. Porting Haiku’s GUI to NetBSD would achieve that.
My apologies, I must have misread the original post, I thought the OP meant to insert NetBSD code into Haiku as a compatibility layer.
However, I can’t see many (Net)BSD/Linux users wanting to use Haiku programs when they have all the FOSS programs already available to them…
Linux & BSD have many very stable GUIs available to them, it’s part of the open source culture, not to be tied to any one thing, be that the interface or programs, unlike Apple & Microsoft.
It is called divide and conquer. It is the reason why Linux & BSD have never been able to get a foothold on the desktop market, and they never will.
If some individual component (project or standard) gets close to full adaption, they will be destroyed from within. GNOME is a perfect example of that, Mozilla another one.
I would like a Haiku system with a Linux or BSD kernel (and the ability to switch those kernels on the same system would be even better). It would be a real alternative to Linux and BSD distributions.
It is a pity that such a system never appeared. BeOS users had to switch to other OSes.
Perhaps it would have been better for OpenBeOS in general to have followed this path from the start, separating the development and maintenance of the kernel from the rest of the system.
What can the BSD kernel do that the Haiku kernel can not?
Also, if that’s what you want, the thing linked in the article above is exactly what you’re looking for.
Compatibility layers might also lead to cultural clashes between different operating systems. To wit I have just read “The Register’s” recent article on 9Front, which is to the old Bell Labs Plan 9 as Haiku is to BeOS.
9Front takes the famed weirdness of Plan 9 naming conventions (like that of the operating system itself) and turns it up to 11. They are also described by the article as having very much take it or leave it attitude to newbies, quite the opposite of Haiku’s friendliness. How would a similar Haiku compatibility layer for 9Front work out? More useful in some ways perhaps, since BSD has a broad software catalogue already whereas 9Front, perhaps not? Would the communities play nice? BSD might not be quite so intimidating, but I don’t think of it as a more welcoming operating system than Haiku is already is.
It seems obvious, Linux and BSD kernels are more mature kernels with better hardware support and higher overall performance and more features.
No, what we need is software that only runs on Haiku because it uses it’s unique combination of a modern kernel and API with unique features only possible through its filesystem and other concepts.
It’s a little mixed up, but it reminds me a little of when Apple was interested in BeOS. Which fizzled and they went to NeXT instead, which led to Rhapsody and eventually MacOS X – running in front of BSD UNIX.
Conceptually, whether the kernels in question are more performant depends inversely upon the memory footprint. Due to code density of small code, that works much better taking advantage of the L1 code cache than some huge monstrosity. I’d be less inclined to use Linux due to its large kernel than a smaller alternative. If the smaller alternative could use drivers intended for Linux but not require as much overhead as Linux, I’d drop Linux rather quickly.
This begs the question: Which of the three has the best code density? May the best kernel win: Haiku, BSD or Linux.
The 9Front kernel is, according to the linked article upthread, only 5Mb. Genode runs one of several available micro-kernel so would be expected to be smaller still. Others will probably be able to advise of the size of other kernels cited above.
I presume that “code density” refers to it packing lots of functionality in this small size, but does that functionality coincide with the functions that Haiku relies on?
BeOS was another one, like Windows & Apple, ‘take it or leave it’ attitude, & it died.
Windows exists because of a marketing ploy, getting manufacturers to put it on their computers…
Apple exists because Windows wasn’t up to the job in the Graphics Industry, where it got its foothold…
FOSS is all about freedom of choice, that’s why people who know what they want choose Linux/BSD.