.NET framework ported to NetBSD(github.com)
github.com
.NET framework ported to NetBSD
https://github.com/dotnet/coreclr/pull/4504/files
9 comments
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.
You helped create the future.
@josteink was one of the main contributors whom ported CoreCLR over to FreeBSD last year. The entire process was a community effort, with minimal help from Microsoft (okay, they provided domain knowledge and guidance). See https://news.ycombinator.com/item?id=9431368 for previous discussions/celebration.
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...
"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...
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.
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.
Ha - gotta say, I feel a little better knowing someone else had a hard time getting mono targeted code to work properly.
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#.
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#.
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.
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 had forgotten about the number of apps, I just remember the postit-note style app in particular. I agree, it was mostly anti-ms fud... but it was still close enough to some really questionable motions by MS that they deserved some of that criticism. I was pretty big into C# at that point, and really liked the work being done.
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.
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.
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.
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 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?
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?
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?
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?
1. No? NetBSD is a classic UNIX system. With rumpkernel though. 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
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
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.
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.
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
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
Nothing for GTK and desktop Cocoa, but they provide Xamarin.Forms for iOS/Android/WindowsPhone8/UniversalWindows: https://github.com/xamarin/Xamarin.Forms
You have Xwt for desktop applications. Xamarin Studio itself uses it: https://github.com/mono/xwt
They haven't implemented anything new in their OS. CoreCLR now compiles on NetBSD, just like it did on FreeBSD, Linux, OS X. That's all.
Can I be the first to call it .NETBSD?
How about "Net-Net"
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!
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!
I was wondering "why NetBSD???", other than as a possible hobby project, but your explanation gives a pretty clear answer. I've never even heard of rump, and know little to nothing about NetBSD, but this sounds really, really interesting. In my spare time I'm writing a "fantasy console" (along the lines of pico-8) that will run in a framebuffer. I wonder if this would be a good fit.
Forget Docker, the future is unikernels! [0] I haven't gotten to play with them much, and the ecosystem is very, very young, but the idea of it all is very intriguing to me.
[0] https://github.com/rumpkernel/rumprun
[0] https://github.com/rumpkernel/rumprun
How can you compare a kernel application vs a process isolation layer? Containers will be adopted to dynamically load kernel modules and then we'll have dynamic "rump" kernels, but saying to forget Docker and the future is Unikernels, doesn't make a lot of sense technically.
How is the rump kernel any different than a unikernel?
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...). 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.
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.
Good information, thanks!
The rump kernel can be used as the basis of a unikernel (see: Rumprun). But, the rump kernel theoretically has applications beyond just use in a unikernel, by providing a common, documented API on one end and hypercall interface on the other which (in theory) enables robust driver and application portability even when used in "traditional" userland / full-OS environment.
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.
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.
Correct.
links with some more information on a conceptual level: http://wiki.rumpkernel.org/Repo#the-big-picture http://wiki.rumpkernel.org/Info:-FAQ
links with some more information on a conceptual level: http://wiki.rumpkernel.org/Repo#the-big-picture http://wiki.rumpkernel.org/Info:-FAQ
Not a whole lot, tbh,
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:
https://github.com/rumpkernel/rumprun
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:
https://github.com/rumpkernel/rumprun
Super helpful explanation & context. Thank you
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. ).
NetBSD really is a nice system and deserves to be as popular as the other BSDs ( Free-, Open-, etc. ).
Great work :)
And Microsoft loves Linux, too.
Wrong way around. Generally we port NetBSD to something else. This headline should be "NetBSD ported to .NET framework"
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 ;)