I thought the inclusion of Glide drivers for Voodoo 3D cards from the early 1990s was enough to hint that my list of suggestions was not entirely serious. Not sure why the one with using the Linux kernel is attracting so much attention then. Where are the comments by people offended by the fact that I plan to waste my time on legacy hardware that no one owns anymore?
6 Likes
Parallel-port connected Zip Drives ? 
More seriously :
A good enough roadmap wouldn´t be to first reach Beta 5, then see what can be done next ?
I’m just going to point out that the best developments in Haiku in recent years have been due being less isolationist… sure there are warts but Haiku actually can run a large library of software now, due to implementing compatibility layers.
The same goes for drivers as well as applications, Haiku uses FreeBSD’s network drivers and it won’t have much choice but also use Linux’s GPU acceleration drivers because that is where all the open source work is happening, the up side to this is that nearly all of the code in that area of the Linux kernel is dual licensed MIT so compatible with Haiku license wise.
Then there are also compute specific drivers showing up on the scene for things like XDNA…GitHub - amd/xdna-driver which is an driver that lets you run the Xilinx XRT on recent AMD CPUs.
3 Likes
Why do you think Google’s kernel is the answer?
1 Like
I believe I still have a Voodoo card in my pile of PC parts somewhere in the house 
1 Like
It wasn’t intended to inform anyone of anything, other than the fact that it’s just a bad idea. I have no feelings of revulsion. You may have feelings on the matter, but I just don’t.
I know little of the Zircon kernel, but it seems to be on the same track as dumping the Haiku kernel for Linux (as it shortly followed the suggestion [sarcasm]?) But Dcatt asked my next question, why do you think Zircon is the answer?
2 Likes
I for one wouldn’t be offended if you wrote Haiku drivers for legacy hardware. I would be even more so not offended if you wrote legacy (BeOS) drivers for modern hardware.
I’m not saying you should or shouldn’t, I’m just not offended. Using the Linux kernel on the other hand is silliness (stupid). Why not use the extended file system with KDE (yuck). Might as well just make those people create their own Linux distribution on their own, and call it something other than Haiku, like HiKuLinux or yellowLeaf. Or better yet, just don’t waste your time because their are plenty of options for those interested in Linux
I get that you weren’t entirely serious, but that’s more to those who might take you seriously in a pro-kernel change way.
1 Like
Eww, no GPL, thank you.
And by Windows NT I meant Windows NT 10.0, since we would need the Pico processes feature.
1 Like
It’s worth noting that Haiku can and does support sharing driver code to GPL projects, they just have to dual license with MIT on their end just like Linux does with graphics drivers. Works for GPL v2 at least anyway. This is what ReactOS does with the Haiku USB stack.
1 Like
Fine 
- so get Warped ! 
Look, it is THAT ™ topic, again.
3 Likes
Windows NT kernel is a biggest failure in kernel design. It is terribly overcomplicated and slow, many of its features are become obsolete.
Also there are no reliable open-source reimplementation on Windows NT kernel. Microsoft do not ship kernel as separate product so it is not legally possible to build alternative OS on top of NT kernel.
2 Likes
ReactOS it terribly unstable to be useful in any kind except of approximate reference of Windows NT architecture. Haiku is already more stable and mature than ReactOS. You can work in Haiku for a long time without single kernel crash or file system corruption.
2 Likes
Maybe, but that is not what I was talking about.
What I was talking about was to use the Haiku source code to compile something like WSL1, then copy the whole Haiku userland into a NTFS drive (maybe a NTFS reparse point for packagefs).
If they were sharing the kernel, the alternative OS would get same hardware compatibility. They don’t want to give up that advantage; it will never happen.
It would be Haiku compatibility layer for Windows, not a Haiku with NT kernel or separate OS. It would not eliminate need of its own Haiku kernel.
Yes, but instead of re-implementing syscalls and stuff like HyClone, I would use the facilities in the NT kernel version 10.0+ that allow creating threads/processes, hooking syscalls, and dispatching exceptions to implement a special “architecture” of the Haiku kernel.
That way, we would get 100% Haiku syscall compatibility for free. We would also get a few other nice features, such as the ability to use a .vhdx with BFS instead of using an emulated root on NTFS.
1 Like
Jeez, I sure like serious negative replies to my joke comment 
3 Likes
I think that HyClone approach is more useful because it allow to load host dynamic libraries into Haiku applications address space. It will be required for example for hardware accelerated OpenGL/Vulkan support. Various interaction with host OS may need dynamic libraries.
2 Likes
well, if most of developers take haiku only as a hobby, it will be beta stage.
if someone break that freak circle , or , haiku get so long time (maybe 50 years) to develop, it will be R1 release.
haiku is useful now, but not so useful to be a Mature solutions for normal users.
and, this is the freak circle. can anyone debug it?
It is a bit of a “deadlock” situation: the OS progreses slowly as long as there are no paid developers, and the donations won’t increase if the OS keeps moving slowly. It’s not really about wanting to keep this as a hobby, but with the current budget ($20000 a year, from which you have to remove a bit because of server hosting fees, etc), there is not much you can do to make this more than a hobby.
1 Like