I believe Japanese ISP's used netBSD in their hardware. I think it's used in many embedded systems as another user pointed out. NASA has used NetBSD in the past as well.

https://netbsd.org/gallery/research.html#sams-ii

https://www.netbsd.org/gallery/products.html

The good old AirPort Extreme runs on NetBSD.

NetBSD are mostly embeded systems.

and dragonfly don’t get deployed =)

edit: dragonflybsd is mostly a playground for those innovative ideas and features

Sega Dreamcast owners :) https://wiki.netbsd.org/ports/dreamcast/

At University

I used it. As Desktop, daily driver, and on servers. The same way I used Gentoo. The thing is, if you compile from source, and don't need proprietary apps which assume linuxisms, anything which is compiled from source runs just the same way, as it would under Linux, or even(slightly) better. But that seems to be an almost lost art, nowadays? (Assuming you have fully supported hardware, drivers, and such, which was the case for a while with some systems) Meanwhile they also have a package manager for binaries, but I've never used that because I've been used to using sources :-)

http://netbsd.org/docs/pkgsrc/using.html

( https://pkgsrc.se/ is like FreshPorts for FreeBSD )

However, I've got lazy, too, and now use some ready made distro booted from USB-keychain, running from RAM.

Besides that, what would be the usecase? The base system is small, lean & mean, and in my experience rock solid, as in UNKAPUTTBAR. The organization and style of source was more understandable to me, as was the framework to recompile the base via build.sh (make world in FreeBSD terminology), and applications from their 'Ports/Portage/AUR' which is called PKGSRC there.

The same goes for the filesystem layout, /etc, init, and so on. It's just really nice, all in all.

Thinking about it, the question is like what would be the usecase for Alpine-Linux? Some people are using that as desktop, too, for probably similar reasons, but enjoying better hardware driver support.

I think the highest hurdle for people has been the 'strange concept' of using 'slices' and 'BSD-Disklabels' to further split apart MBR-style partitions.

Like explained here: http://netbsd.org/docs/guide/en/chap-inst.html#chap-inst-ins... & https://en.wikipedia.org/wiki/BSD_disklabel

I don't know how that applies to UEFI/GPT-partitioning and secure-boot actually. Haven't tried that, so far. Seems to be another hurdle, though I know from others that it runs, at least without secure-boot. Seems to be that 'The Guide' and FAQs are lagging behind reality. As often is the case, need to read mailing lists then, sigh...

Or simply searching for UEFI and GPT on their wiki, which leads to:

https://wiki.netbsd.org/Installation_on_UEFI_systems/ & https://wiki.netbsd.org/users/spz/moderndisk/

Furthermore: different device names. And an INIT which is neither SysV, nor systemd.

http://www.mewburn.net/luke/talks/auug-2003/ & https://www.netbsd.org/docs/guide/en/chap-rc.html

Which wasn't even mentioned in all the (mainstream) discussions of SysV vs. systemd because NIH?

I don't know exactly how to say this, but IMO you've missed out on an experience, if you don't know it. No matter how inconvenient initial installation or hardware support is.

This belongs under your belt.