Why is this important?
Programs for NetBSD can be run in a stripped down NetBSD kernel and libc (a unikernel) called rumpkernel, which can be run on any platform, including on bare metal.
It is also extremely minimal - an operating system image for nethack was a mere 4MB.
Rump can also run on any architecture that NetBSD runs on (including MIPS, VAX, m68k, as well as standard platforms like amd64 and ARM) and also on those without fully NetBSD support, but just with a functional C compiler (like RISCV).
Many people use rump as an extremely lightweight container - it can run on Linux and others.
Rump was recently used to port NetBSD audio drivers to GNU/Hurd.
Caveats: doesn't run in rump yet, but this is a big step towards it. .NET is also not self-hosting yet, and requires assemblies (CoreFX) to be cross-compiled from Linux.
The work was done almost entirely by Kamil Rytarowski, a NetBSD developer, in his free time. Good job Kamil!
What is unique about NetBSD is that they have been structuring their driver code on top of well-specified portable APIs inside the kernel (AFAIK beginning with bus_space in NetBSD 1.2 in 1996: http://netbsd.gw.com/cgi-bin/man-cgi?bus_space++NetBSD-curre...). At first this was to increase portability by making it possible to write a single device driver that would work on different architectures and over different buses (contrast to Linux, where you basically have to write a new driver for the same device over PCI vs USB).
Having these well-specified API layers is what makes it easy to take the NetBSD drivers and use them outside of the NetBSD kernel, which is what rump does. This makes it possible to write and debug drivers in NetBSD userspace (and run them too, there are proposals that are essentially steering NetBSD into a microkernel: https://wiki.netbsd.org/projects/project/userland_pci/). You can also implement the NetBSD APIs that the drivers use in your own kernel and run the NetBSD drivers.
There was a similar project for Linux drivers (DDEKit: http://os.inf.tu-dresden.de/ddekit/) but the ad-hoc nature of how Linux device drivers interact with the rest of the Linux kernel and the major changes across different Linux versions make such a project much harder to use and keep current.
So, in short, a rump kernel is a building block that can be used to build a unikernel, but the rump kernel can also be used in other contexts as well.
links with some more information on a conceptual level:
The idea is to run directly on the hypervisor/hardware, and they both do that.
In actuality they're pretty far from each-other but conceptually they are the same.
Here is the rumprun unikernel:
This is why I like open-source. If my toaster one day runs .NET, I'll be able to say I helped make it happen ;)
You helped create the future.
"Officially" supporting alternative platforms gives me the opportunity to write code in a language I prefer for the handful of Linux boxen I've had here. I'm looking forward to poking around with this in NetBSD. I've had a box doing virtually nothing here for a while running an old version -- guess it's time to upgrade!
The thing that still makes me hang on to other languages is uptake. I haven't looked in a little while, but back when Mono was "it", the number of applications available outside of Windows was pretty small. Basing an application on Mono tended to come with grief lobbed at the developer. Has any of that changed or shown signs of changing since CoreCLR was released?
 I'll be the first to admit that these problems had workarounds I wasn't familiar with at the time and though I had no similar problems with a handful of CoreCLR apps I've written, I was far more researched at my second attempt and would have probably been successful with either had I bothered to try.
 I tried to find examples - my memory is not serving me well but I thought a component of OpenSUSE or something along those lines was written targeting Mono and was later scrapped for another technology due to weak community support. The best example of complaints I could find is http://www.linuxuser.co.uk/features/mono-a-gratuitous-risk-t...
Some of the negative feedback was deserved, but I think most of it was FUD. I tried to run Mono for some things earlier on, and it was just a lot of effort for things that worked so well in Windows at the time. I think the CoreCLR work and acquiring Xamarin definitely show some work in the right direction here.
I've been doing mostly node.js dev for the past few years, may consider .Net again... tbh, more interested in looking at Go for something though, as an excuse to learn. I do miss some niceties with VS though.
I can't remember what I ran into specifically, but I remember the usual StackOverflow/Google route for solving the problem yielded either nothing, or in the case of google, a bunch of forum posts with replies like "Well, the problem is you're targeting Mono and that's a terrible thing to do for [insert reason here]" so I gave up.
I'm firmly planted in the .Net camp developing software for Windows specific products, but I've been a C/C++ developer in the past and have begun the long process of modernizing my C++ background. It's always good to have a few languages to call upon when a problem presents itself, but it's ideal to have a core one that can be used in many places and if all goes well, that'll be my case in a bit. I thoroughly enjoy writing code in C#.
A particularly good example, I think, was the music app Banshee, which I thought was a much better application than what it replaced and what in turn replaced it in the Ubuntu default install.
Another example from that time was F-Spot, a photo library tool.
Apps built specifically for Mono, most of which were directly using Gnome's Gtk UI library (via the Gtk# bindings) were great apps. A lot of the hate really was just anti-Microsoft (and/or anti-Novell at the time) FUD. The fact that Mono had an on disk footprint about as much as Python was the useful tool in what was mostly (from my perspective) a useless debate.
I was mostly doing web apps (still am) and that story wasn't nearly as good as the desktop side of things. I still feel that C# is a really great language, and the bindings to native methods from managed code are still the best I've worked with... far better than JNI and other tooling. Probably why it was such a great fit, and why GTK# works so well.
I never bought the "but microsoft will always be ahead" argument, as the gtk apps that worked under mono wouldn't magically stop working because .Net kept moving forward.
Vala was an attempt to provide enough c# like features to provide an alternative and while it hasn't exploded in popularity it probably has filled the gap to some extent.
The issues of control were definite FUD, as Mono at the time was always an open source project first and foremost and it shouldn't have mattered that most of its contributors were Novell employees at the time or Xamarin employees when Novell divested itself of much of its open source development staff.
The "decline in Mono" in Ubuntu had everything to do with FUD. Arguably Mono itself has never really seen a decline, it's always been out there for the installation and usage. Even when priorities were focused elsewhere (because mobile efforts first at Novell and then at Xamarin paid the bills), Mono has seen stable development.
(Now you could say that Mono is in "decline" in today's world, but only because first Roslyn and now .NET Core have been supplanting Mono as cross-platform open source efforts for C#/.NET.)
As for Vala, I still don't understand why as a developer I'd ever want to write Vala rather than C#. Vala still seems like a strange choice to me. Why build a "Gnome-specific language" that isn't really useful outside of the bubble of Gtk?
1. Am I correct in thinking that this is sort of what NetBSD has done?
2. Does this mean that through Roslyn + RyuJIT, NetBSD gets to run programs written in C#, F#, and other visual-* languages?
3. How close to support for things like WPF/UWP does this get NetBSD?
2. Yes. But running those languages was possible even before that, thanks to Mono. CoreCLR is just the new, shiny, lightweight and MS official thing.
3. Hahahahaha nope. WPF and UWP are proprietary. I don't think there are any alternative implementations of them. Mono has an implementation of good old WinForms though :D
3. My question was how close it came. In other words, what else would your OS need in order to be compatible with something like a cross-platform app created in Xamarin.
Cross platform Xamarin apps are different. Xamarin has its own GUI library wrappers but do not provide a cross platform library (or at least they didn't last time I checked. They'd need to create one for GTK/Qt/X/whatever and devs would have to write for it
NetBSD really is a nice system and deserves to be as popular as the other BSDs ( Free-, Open-, etc. ).