
.NET framework ported to NetBSD - nbyouri
https://github.com/dotnet/coreclr/pull/4504/files
======
nbyouri
NetBSD is a very portable BSD-licensed operating system. This is CoreCLR, the
open source .NET framework from Microsoft.

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!

~~~
saosebastiao
How is the rump kernel any different than a unikernel?

~~~
sedachv
Think of rump kernels as a portable library of drivers with a well-specified
API.

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...](http://netbsd.gw.com/cgi-bin/man-
cgi?bus_space++NetBSD-current)). 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/](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/](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.

~~~
iamabhi9
Good information, thanks!

------
josteink
From a former contributer's point of view, it's fun checking the commits it
took to make this happen. From what I can tell, some of the work I put in to
get CoreCLR work on FreeBSD (which again built on others work to make it run
on Linux and OSX), now makes it happy to run on NetBSD too.

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 ;)

~~~
swalsh
A toaster running freebsd that connects to azures machine learning service,
and automatically tells you if the Virgin Marys face is burned on there.

You helped create the future.

------
mdip
As a .NET developer, and lover of all things C#, I couldn't be more happy.
There's always been that nagging feeling in the back of my mind that I'm
pigeonholed with a language I can't easily use on other platforms (Mono's been
around for a while and I've used it but I ran into a variety of problems the
last time I targeted it[1]).

"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[2]. Has
any of that changed or shown signs of changing since CoreCLR was released?

[1] 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.

[2] 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...](http://www.linuxuser.co.uk/features/mono-a-gratuitous-risk-the-
free-software-column)

~~~
tracker1
IIRC there was a note taking app that was included with Ubuntu for a while. It
was mainly removed to save the disk space (the target at the time was CD
size), but there was a lot of negative feedback about it at the time.

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.

~~~
WorldMaker
It wasn't just the note taking app. There was nearly a half-dozen mono-based
applications included out of the box on Ubuntu in one brief "mono spring" in
Ubuntu before the hate hit.

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.

~~~
shirro
There was a lot of concern over patents and control but I think the decline of
Mono had a lot more to do with Novell going bust and developers disappearing.

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.

~~~
WorldMaker
The concern about patents was sort of fair, but was as much a FUD red herring
as anything else. There was the debate whether Microsoft's .NET open patent
promise at the time applied to Mono in general or just OpenSUSE's distribution
of Mono. In the time that the Ubuntu community spent debating that they could
have done the simple thing that Red Hat did back then which was ask Microsoft
to generalize the promise a bit more...

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?

------
bloaf
I've been reading around to try to get a clearer picture of what is going on
under the hood in Microsoft land. Essentially, I'm curious what it would take
to build an OS like Inferno, but that provides the CLR as a VM for CIL instead
of Limbo.

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?

~~~
floatboth
1\. No? NetBSD is a classic UNIX system. With rumpkernel though.
[http://rumpkernel.org](http://rumpkernel.org) I guess you could build a
system like that with rumprun maybe…

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

~~~
bloaf
1\. I was just curious if, by implementing the CLR, they have effectively
implemented a VM for CIL in their OS, not if they reproduced Inferno.

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.

~~~
sitharus
3) Not close at all. UWP and WPF are proprietary Windows technologies that
rely on the Windows APIs. They're closed source so nobody really knows what
they need.

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

~~~
floatboth
Nothing for GTK and desktop Cocoa, but they provide Xamarin.Forms for
iOS/Android/WindowsPhone8/UniversalWindows:
[https://github.com/xamarin/Xamarin.Forms](https://github.com/xamarin/Xamarin.Forms)

------
CiPHPerCoder
Can I be the first to call it .NETBSD?

~~~
draw_down
How about "Net-Net"

~~~
stephengillie
Net.NET

~~~
happycube
netbsd.net works too, and actually goes to the home page ;)

------
Hydraulix989
Wrong way around. Generally we port NetBSD to something else. This headline
should be "NetBSD ported to .NET framework"

------
iamabhi9
Great work :)

------
kingmanaz
NetBSD scales well. See SDF.org for working example. Hundreds of users from
around the world online simultaneously at any given moment, thousands of Unix
commands and services being used and consumed, and despite all that, a great
security record and good performance.

NetBSD really is a nice system and deserves to be as popular as the other BSDs
( Free-, Open-, etc. ).

------
toomanythings2
And Microsoft loves Linux, too.

