Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET framework ported to NetBSD

github.com

Post reply on HN
Print view View original

21–30 of 39 posts

Re: .NET framework ported to NetBSD

#21

Post by floatboth »

coredog64 wrote: post #13
nbyouri wrote: post #3

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 a…

Also worth mentioning that only supported arch right now is arm64. Don't get too excited about running a .NET rump kernel on your evbarm toaster.

amd64, not arm64. Do get excited about running a .NET rump kernel on your Xen host!

Re: .NET framework ported to NetBSD

#22

Post by sedachv »

saosebastiao wrote: post #9
nbyouri wrote: post #3

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 a…

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.

Re: .NET framework ported to NetBSD

#23

Post by bloaf »

floatboth wrote: post #20
bloaf wrote: post #18

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…

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 ha…

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.

Re: .NET framework ported to NetBSD

#24

Post by ghuntley »

josteink wrote: post #19

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

@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.

Re: .NET framework ported to NetBSD

#25

Post by sitharus »

bloaf wrote: post #23
floatboth wrote: post #20

Earlier quoted context omitted.

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 ha…

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

Re: .NET framework ported to NetBSD

#26

Post by 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...

Re: .NET framework ported to NetBSD

#27

Post by floatboth »

bloaf wrote: post #23
floatboth wrote: post #20

Earlier quoted context omitted.

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 ha…

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.

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.

Re: .NET framework ported to NetBSD

#28

Post by floatboth »

sitharus wrote: post #25
bloaf wrote: post #23

Earlier quoted context omitted.

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

Nothing for GTK and desktop Cocoa, but they provide Xamarin.Forms for iOS/Android/WindowsPhone8/UniversalWindows: https://github.com/xamarin/Xamarin.Forms

Re: .NET framework ported to NetBSD

#29

Post by swalsh »

josteink wrote: post #19

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

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.

Re: .NET framework ported to NetBSD

#30

Post by themartorana »

callinyouin wrote: post #8
nbyouri wrote: post #3

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 a…

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

Post reply on HN