Alrighty, then.
If the FreeBSD network driver compat layers allow Haiku to use Linux drivers, then how come not all of the NICs and adapters working on Linux function in Haiku. For example, Broadcom drivers on Linux have support for BCM4313; however, Haiku doesn’t despite using the same drivers with the FreeBSD compat layer. I am sincerely curious to know the answers to this.
Because that isn’t what it does!!?
The network compat layer is for FreeBSD drivers on Haiku it has nothing to do with Linux. With some work other BSD drivers can be ported to it also as all BSDs try to work together a little on this.
The graphics acceleration layer would be porting FreeBSD’s Linux graphics driver wrapper to Haiku. And I’ll mention this again when written properly these layers exist only in code… And all the translation between Haiku FreeBSD and Linux goes away when compiled.
FreeBSD has it’s own network driver subsystem but is adopting Linux’s graphics drivers with source level compatibility…
If you see performance difference it probably comes down to how functionality the driver uses performs differently between the two systems.
Ooooooooh, now it makes sense! 
I think I was getting confused with the various FreeBSD compat layers being used/planned to be used. 
Dang, egg on my face.
Speaking of driver wrappers, would it be possible to integrate some of the work done on ndiswrapper to get Windows network drivers working in Haiku? This was the stopgap measure for Linux until more networking hardware support came their way.
Theoretically… But ndis is buggy anyway and only works on x86. Probably not worth the time/effort these days when most of the time you can swap your WiFi card to a nice working one.
A big difference is ndis on windows isn’t open source… So it was written half blindfolded. Whereas a driver wrapper developer for FreeBSD has all the code to look at right there.
Also ndis actually is a translation layer at runtime since you can’t recompile the driver side of things. So won’t perform as well.
Also with ndis I’ve seen people using it on Linux for wifi adapters that had perfectly working Linux drivers…so it can cause confusion.
you can swap your WiFi card to a nice working one
Not with devices like laptops and netbooks, you can’t. The only exceptions that I know of are older models with ExpressCard slots; the problem is that said cards are almost nowhere to be found these days. USB WiFi adapters exist, but those are usually some subpar hardware that barely works even in Windows. Are there any other possible stopgap solutions to filling in the holes in Haiku’s network adapter support?
Modern laptops use mini pcie cards… Every laptop own and even one desktop I have has a swappable wifi card it’s just inside similar to swapping ram.
The only devices you’ll find that may not have swappable cards are tablets and I bet even alot of those have them. About the size of two quarters.
I can tell you right now that there really are laptops that don’t use mini PCI-E cards for WiFi. My main machine (an ASUS laptop) has a weird way of connecting the WiFI card to the motherboard. It connects using some kind of wire with one end that snaps into a receptacle in the mainboard. And my main laptop is three years old now, so it isn’t one of those newfangled Ultrabooks where many components are soldered.
It doesn’t; FreeBSD’s Linux compatibility layer does not run under our FreeBSD compatibility layer, and there are not any WiFi drivers that use this feature in FreeBSD anyway.
The BCM4313 is supported by a native FreeBSD driver, not a Linux-ported one. The reason I haven’t attempted porting it to our FreeBSD layer is its use of some weird Broadcom-specific busses that will be a pain to get wired into our compatibility layer correctly.
At this point, I’m pretty close to abandoning this approach; FreeBSD’s code here is just a huge mess and not worth that effort. I’m looking at OpenBSD’s drivers instead.
This is also not true. For the most performance-critical functions, most of the wrapping is inlined indeed; but there are still wrapper functions which would be wrappers of wrappers.
There are actually some FreeBSD network drivers dependent on the Linux compatibility layer (some strange 10Gb Ethernet drivers, not anything WiFi related, but still.)
Brilliant derail of the thread guys… 
Shall I move to a new thread?
Leave it be… it’d just be another thread to get derailed after all.
Refuting non features is on topic 
Ok, we’ll get back on topic @humdinger. 
Frankly, hardware accelerated support and support for more WiFI hardware are the only major blockers for (personally) having Haiku as a third operating system. Multi-user support would be nice, but isn’t a priority at the moment.
Well, imho, it already caused some confusion to split threads… maybe things like login wishes and system-wide persistence can be started in a new thread. In fact, I might do that so everyone can focus on saving states across reboots in the future. It’d be a great alternative to ‘sleep mode’ which doesn’t always work so well on PCs anyway. 
Seriously, it seems the only computers I’ve seen that sleep flawlessly are Macs… but that’s just me.
There was similar talk, may be someone find it interesting:
Considering the current method of installing packages, could it be reworked in the future to add containerization abilities to Haiku? With the trend of putting everything in containers, a low latency OS with a fast GUI for interaction having such a feature may prove to be interesting for businesses. Of course, proper multi-user support needs to be implemented first.
I think that is completely orthogonal to Haiku’s package mangement.
What you need to implement containers is hardware virtualization support… perhaps either implementing KVM or BHYVE.
Isn’t KVM specific to the Linux kernel?
I dont think that it would a good idea in the end. If you are in need of a system to run container apps… as a lot of them, you are probably going to want a/the smallest baremetal os, like a specially crafted one (Alpine for example).
Technically yes KVM is linux sepecific. However it has been ported elsewhere such as SmartOS and old ports even to Windows and FreeBSD in various states of completion.
BHYVE may be a better target as KVM is a much faster moving project.
I can definitely see the applications of a low latency OS with a GUI and containerization (for security). The movie industry likes to prevent leaks from coming out and isolating app data from each other in containers could be of significant help. Artists in that field often have to work with machines disconnected from any network, which can be very cumbersome. A containerized Haiku may allow for them to still use the Internet (references, communication, etc.) while not risking confidentiality of their performance-sensitive work.
Remember that BeOS (and Haiku by extension) was the best for multimedia applications back then. What more appropriate fate for Haiku than for it to follow in its footsteps by adding security to it, which is very highly valued in professional multimedia environments.
I suppose that could work if only the container’s were allowed extermal netowrk acess and it was turned for native apps being used for produciton etc…