freesco from @ryoshu [IRC Freenode #NetBSD]
"NPF, the firewall I'm fond of most, but I may be biased, since it's the only I really know how to use, hence the only I feel confident using"
So you never really managed anything like a central corporate iptables based firewall with over 10000+ rules including various SNAT/DNAT, layer7 filtering, packet marking, QoS, time based rules, port forwards and logging to various formats like text files and mySQL through ulogd.
Please list exact list of missing features you miss in the NetBSD networking.
ulogd is by definition iptable-only. Do you need a version for NetBSD?
Performance wise I don't say nbsd is behind linux but the overall functionality is a lot less whilst all the bsds have a complete different syntax and firewall rule evaluation logic than linuxes.
In NetBSD we maintain NetBSD and compatibility with other BSDs has the same priority as Linux compatibility with firewall daemons in Windows or MacOSX.
Pretty much the same goes for the hardware support, we all know that netbsd runs on everything including your kitchen toaster however by saying it runs you mean that often all you have is a serial console, end of story. The lack of well written drivers really comes out on the client side when we talk about BSDs:
-Cups and wide range of printer support is missing
This is an Apple product, not Linux. It works first on Apple that is BSD-based and by a convenience an ubuntu employer maintains it on Linux.
Mostly the same support is on BSDs as on Linux.
-Bad audio drivers (talking of 5.1 7.1 8.1, usb headphones, bluetooth headphones and other extras)
bluetooth audio works, usb audio works.
-Touch screen drivers (almost non-existent in BSDs)
I know at least a single NetBSD developer with a laptop with a fully functional touchscreen on NetBSD. I tested this feature myself with my fingers and worked.
This functionality just works out of the box and is generally considered as simple input device.
-Bluetooth/IRDA device support zero
NetBSD was a pioneer in bluetooth support.
There are IRDA device drivers, but last time I used IRDA was like 15 years ago.
-Novueau -> this driver is the worst ever in history especially with older cards like Geforce 4x 5x series it can crash your system like not even magic sysrq key helps or trying to login remotely
Every OS (even Linux) is plagued by DRMKMS device driver bugs, e.g. modern report:
"i915 GPU HANG
I also suffer from a hanging i915 driver which renders the system completely unusable – rebooting the system is the only help.
Lenovo Thinkpad P52s"
And these were just "some" right off the bat.
So far I don't feel impressed.
Let's talk about file systems a bit:
Have you ever had to work with smbfs/cifs in the bsd environment? In Linux no problem, since Samba 4 can do as much as modern Win2016 based domain controllers and clients can mount these filesystems as well. However in BSD land, I don't know about nbsd but for obsd the ONLY tool exist for you to mount these filesystems, and I dont even talk about CIFS because they still stuck 10 years in the past with smbfs is usmb which is a completely slow piece of garbage resulting you 1MB/s performance on a 10gbit network link, no improvements, not even planned.
pkgsrc/net/samba is known to work, if there is need for a newer version it is just a userspace daemon working as well as on Linux.
And if we are talking of filesystems I think it's a complete joke that in 2020 none of the BSD's filesystems is mountable to RW by Linux 5.x kernels whilst we have NTFS-3G full rw support, we can even save down and restore whole windows 10 systems with partimage. So tell me why is that, the crappy BSDs cant even mount each others file systems and let's not talk about easy to use, no one wants to fiddle around with entering disk sizes in bytes in 2020.
Do you request NetBSD developers to write FS drivers on Linux? Is this serious request? OK, we might do it for you but please fund it with real money from your pocket.
But even if it is serious demand, we did the work. We support pretty all NetBSD filesystems in R+W mode through rumpkernels on all relevant OSs. NetBSD filesystem code was also used in the wild in embedded devices with custom OS (no-kernel) software stack and in unikernels. The same applies to other device drivers, sel4 supports our networking device drivers, HURD supports audio device drivers, etc.
Virtualization is also a joke on BSDs, jails don't count as virtualization. What you have is only VirtualBox (last time I checked it had like limitation on usb passthrough and other things compared to Linux) while we have Vmware, VirtualBox, KVM, Docker, Xen, OpenVZ ... list goes on ... on Linux.
VMWare is a proprietary software stack. This argument is like blaming Linux for Windows-only computer games.
KVM is Linux-only and specific to Linux APIs. We support NVMM and HAXM as a drop-in replacement. We run NetBSD+NVMM/HAXM with qemu and can use libvirt stack as is.
Xen - NetBSD was the first OS with mainstream support for Xen dom0 in mainline.
OpenVZ is kind of patched Linux kernel for containers, today in the age of Docker probably irrelevant (sorry OVZ people).
It is true that we still miss native container API and Docker on top of that, but we will reach this point hopefully sooner than later. This target is more sensible for us than patching the Linux kernel for NetBSD Filesystems.
With all this I dont say nbsd or other bsds are bad but they are a decade behind Linux with a tiny egghead userbase. The mainstream still using Windows, Linux only has popularity on servers and BSDs, they are the low 1% of Linux users. Also the faith of large monolithic unix systems like AIX/HP-UX or Solaris is sealed, these are dead. Most of the dev teams retired as well, they had a lot of interesting features back in the 90s but these days they are all replaced by Linux servers.
The popularity argument is true. We can make use of your help in marketing.
Recently the real problem is with systemd and related software. Certain persionalities enforce Linux-only libraries and interfaces wherever possible trying to enforce vendor-lock: libudev, libinput, libmount, cgroups, namespaces etc. Design of these APIs is questionable as they are not flexible to support anything beyond Linux. It's time to untangle from that.