How (not) to build .NET coreclr on FreeBSD

That's funny, but actually please don't use plain C as a backend language. Stdlib string handling functions alone are horrifying. For example, It's not at all difficult to find strncmp misuse in FreeBSD sources.

shkhln Hehe, yes. I might go back and put a bigger disclaimer ;)

Though the BCHS crowd do have a solution to the unsafe strncmp... Yep, they recommend strlcmp instead! lol
 
.Net is already running in ASM.js it's a project called Blazor has a running demo and everything.
That is pretty much the point I was trying to make. Emscripten has been out for a long time already, large C++ projects such as engines such as Unreal (3 months) and Unity, (1 year) have already been ported, it has taken Blazor many years (3 years?) later to make a port and it is still experimental whereas the others are in a production worthy state. It is because of this sluggishness of porting such a massive codebase that I believe Microsoft is going to be losing interest in .NET technology.

C# is component based while C++ and C

Component based, as in object-orientated? I am not saying that C++ or C vs Java or C# are better languages. In fact I tried hard not to mention languages at all and refer entirely to their underlying platforms, (.NET, native, JVM). This is the crucial part to their success. The actual languages themselves are barely important.

There are a lot of good examples and documentation out there for C# just a ton of examples and videos. You mention Lua- the docs for Lua have become more dense but still pretty minimal. Ok, so I want to cast to a string in Lua and their docs list one "tostring" method and an example- cool!

Again, it isn't how fun or nice the language is to use. I am talking about lifespan. In theory it is possible to make a version of Lua that has a C#-like frontend and the exact same benefits would be seen. The fact of the matter is that the .NET VM and supporting platform is many, *many* lines of code, many of it very platform and architecture specific, whereas the entire Lua VM is about 20 source units of ANSI C. This is why I predict that Lua will outlive VB.NET, C#. C++/clr, IronPython and other .NET based languages.

Unity uses C# one way or another and powers many, many mobile apps like it or not the damage is done and it's still C# so I think trying to say it technically isn't the same design pattern therefore .Net doesn't run on mobile is pre-emptive

.Net Core has AOT as well (CoreRT) and LLVM is showing some good performance starting out with this.

So both of these achieve the same result in very different ways. The first one converts the .NET bytecode (IL) into C++ code which allows Unity to stay quite a bit more portable (It still requires bohems-gc but that is pretty portable these days). Whereas the AOT is basically just a JIT that stores its generated binary. This is less portable and only works on a very limited number of platforms.
So out of these two methods, the Unity one is potentially best but is certainly very tied to their engine and a generic i.e Web app will be very unlikely to work with it directly.
Will Microsoft adopt this approach? If they did, I could see C# living on (not necessarily the .NET Framework, but certainly the C# language itself).

I am not attacking C#, far from it, I would much rather use it than risk the safety issues found in old obsolete C++ or C. However, due to issues with lifespan, I find there is very much a lack of suitable alternatives (Modern C++ is actually pretty good these days and I generally stick with that).
 
.Net is already running in ASM.js it's a project called Blazor has a running demo and everything.
Like most Microsoft things, the rest of the world has moved on to other things--in this case webasm.

I'm surprised that there isn't more "learn Node.js" in the BSD camp since, when it works, it performs extremely well and JavaScript isn't going anywhere anytime soon it looks like.
Node is a web language based on JavaScript so a discussion of it on an operating system forum is less likely.
 
This is exactly why C# on FreeBSD would benefit it is because you can keep a codebase in one language and there is support across many mobile devices and operating systems.
Microsoft is dead on mobile. Microsoft products are a kludge on the internet, too. C# and .NET target Windows and Microsoft products. It makes no sense to use such thing for the internet, mobile, or anything cross platform.

I, too, wonder about learning golang or rust. I spent some time with Go and briefly tinkered with Rust. Go is more important for my web dev company. Rust would be more important for system software but I don't have time for that anymore.
 
please don't use plain C as a backend language.

My company runs two highly performant web sites that you have visited and probably still go to at least occasionally. We continue to do everything in C for four reasons, ignoring the fact that I was a C programmer when I got the contracts.
  • We can interface to virtually everything without issue.
  • We can do everything faster.
  • We can do everything on smaller, cheaper hardware with less need to expand.
  • We are far, far more flexible.
 
  • We can interface to virtually everything without issue.

I agree with all of them but this one in particular is the killer feature!

I like rust (I am even taking the time to learn it because I do think it will still become very relevant in the future) and I am very much liking the fact that people are finally starting to develop native / systems level programming languages / platforms again. However, it cannot interface with C code without wrappers (dreaded bindings!) and a lot of its safety features are lost whilst doing so. This is where Go could potentially win if they were competing.

Direct access to C is crucial and is often overlooked by "normal" developers because they just assume that these nice bindings can be provided to them forever. However in the open-source world (especially *BSD) we realize that we don't get spoonfed "products" by the industry, we often need to do it all ourselves. Bindings take more time to maintain / implement than the project itself haha.

Imagine if C++ could not consume C code directly but instead you had to wrap each function into i.e a CNI_c_fopen(object o) wrapper and do this for every native function you use. Painful! I don't think it would have been nearly as successful.

My one issue with Go is not a technical thing. It is "Google"! Did they really employ the AT&T guys or have they simply kidnapped or blackmailed them?
I cannot imagine Google really gives them the support or research freedom compared to a more ethical company?
 
We continue to do everything in C for four reasons, ignoring the fact that I was a C programmer when I got the contracts.
This is quite interesting. Is it entirely a i.e CGI architecture where everything is done in the C binary?

Or perhaps it is more like a restful thing where much of the logic is done on Javascript in the client side and only true requests such as database queries ask your C based web API?

I am terrible with web development (I simply cannot make things display properly in every browser unless I use tables and then it just seems to become unmaintainable ;)).
My main recommendation against using C as a backend is because most web developers are also terrible and not nearly diciplined enough to be able to use C fullstop, let alone a secure public service!

If you can do it and specialise in C then that is really quite cool for a web app because like you mentioned, you have a large amount of benefits!
 
most web developers are also terrible and not nearly diciplined enough to be able to use C
Absolutely true. Most are only concerned with it showing up in a browser on the web with little to no concern for engineering. Then you have Google, Facebook and others making tools (React, Angular, node) or rules (schema.org, JSON headers) to get around their inadequacies to make up for it while forcing those of us who don't need such things to use them in the interest of SEO.

When almost everyone finds out we do everything in C, they always look at us like we're crazy and give the response: "You're crazy!", "It can't possibly be done!!", "You're reinventing the wheel!!!", "No one does that!!!!", "It's too hard!!!!!" and "Well, for a niche site with no visitors you can do whatever you want."

For the longest time, we actually had a niche site for one company that slowly grew over time. We really didn't have the resources--or the desire quite frankly--to continue with them so they hired another company to take that from us. They were floored when we told them their whole site ran on a 256MB, 20GB VPS and had three different people call to ask if that was correct.

Another site decided we didn't know what we were doing and were convinced, by others, that one can't handle anything without .NET and other Microsoft things. The devs I know, there, said the staff has tripled, along with the server capacity, with no increase in functionality but a definite increase in fumbling and bumbling.

Is it entirely a i.e CGI architecture where everything is done in the C binary?
We are transitioning from using nginx, fastcgi and nginx modules to using nghttp2 but also the h2o server. That is a fascinating adventure with much profit!
 
Oh well. No real loss. It also saves our guys the small bit of effort from removing it from ports again once Microsoft drops .NET entirely.
I am still 99% sure that .NET Core is just the first stage in Microsoft's product discontinuation strategy for the entire .NET ecosystem.
Published today:
Microsoft to bury .Net Framework
Notice, I have this information from a credible inside source, and no I won’t tell you who. However, apparently Microsoft has plans to bury .Net Framework as of version 4.8. This means that version 4.8 will be the last update to .Net Framework to ever be released by Microsoft.
 
My company runs two highly performant web sites that you have visited and probably still go to at least occasionally.

That's quite a riddle. I'm aware of only one site matching that definition and it belongs to a certain Russian social network. You can actually look at the snapshot of a part of their stack here.
 
That is pretty much the point I was trying to make. Emscripten has been out for a long time already, large C++ projects such as engines such as Unreal (3 months) and Unity, (1 year) have already been ported, it has taken Blazor many years (3 years?) later to make a port and it is still experimental whereas the others are in a production worthy state. It is because of this sluggishness of porting such a massive codebase that I believe Microsoft is going to be losing interest in .NET technology.



Component based, as in object-orientated? I am not saying that C++ or C vs Java or C# are better languages. In fact I tried hard not to mention languages at all and refer entirely to their underlying platforms, (.NET, native, JVM). This is the crucial part to their success. The actual languages themselves are barely important.



Again, it isn't how fun or nice the language is to use. I am talking about lifespan. In theory it is possible to make a version of Lua that has a C#-like frontend and the exact same benefits would be seen. The fact of the matter is that the .NET VM and supporting platform is many, *many* lines of code, many of it very platform and architecture specific, whereas the entire Lua VM is about 20 source units of ANSI C. This is why I predict that Lua will outlive VB.NET, C#. C++/clr, IronPython and other .NET based languages.





So both of these achieve the same result in very different ways. The first one converts the .NET bytecode (IL) into C++ code which allows Unity to stay quite a bit more portable (It still requires bohems-gc but that is pretty portable these days). Whereas the AOT is basically just a JIT that stores its generated binary. This is less portable and only works on a very limited number of platforms.
So out of these two methods, the Unity one is potentially best but is certainly very tied to their engine and a generic i.e Web app will be very unlikely to work with it directly.
Will Microsoft adopt this approach? If they did, I could see C# living on (not necessarily the .NET Framework, but certainly the C# language itself).

I am not attacking C#, far from it, I would much rather use it than risk the safety issues found in old obsolete C++ or C. However, due to issues with lifespan, I find there is very much a lack of suitable alternatives (Modern C++ is actually pretty good these days and I generally stick with that).

Except, I think another big issue here is that it is being used as a build tool in open source software. This is the one role which I think gets ignored frequently. Because of reflection and T4 templates it's become a tool to build software written in other languages. If it gets left out then that software also will not port. Lets say for instance Perl disappeared- would a lot of OSS software build? The C++ equivalent to what it can do in that regard is G-Object introspection which if that was a preferred choice would be a lot more popular. Node.js, being a framework heavily tied to C/C++ due to its integration with POSIX, is already used to build much of the OSS world as it is. If I just wanted pure speed I would cache everything but sites have to be dynamic as well, work with DBs, etc.. I would very much rather interface with OAuth, ADFS, WebSockets, WebPack, or GRPC by connecting to it as the component that it is. "An individual software component is a software package, a web service, a web resource, or a module that encapsulates a set of related functions (or data)." And yes, much of the .Net Framework is being shifted over to .Net Standard. These newer languages are exciting and still they are fumbling with some of the basics much like .Net did in the beginning. I think you hit the nail on the head when it comes to suitable alternatives- that's true it's hard to find one. So you can take the approach of being OS specific or not as I see it, sometimes in that decision compromises are made. The same C or C++ code will not run the same way on every platform if there are so many rewards nowadays for cheating the hardware- especially on mobile.

I did something different this time and decided to build a FreeBSD system up and put C# on there and take a look at where it is. NuGet has really improved in the IDE and looks like VSCode is running too which is great! I know Electron was not easy to get running but looks like both IDEs are could be in great shape on FreeBSD with the addition of Core and some tweaking. It would be a shame to lose out on all the work that went into getting it all to run in the first place. Live remote debugging looks very possible as well but have not tried it yet. I was surprised how much more functional it is than what I was expecting.
 

Attachments

  • vscode.png
    vscode.png
    141.1 KB · Views: 300
  • monodevelop.png
    monodevelop.png
    176.6 KB · Views: 323
You mean Windows software and the three things you mention are only editing software for programmers as if no such tool exists on Unix/BSD/Linux now.

If I meant that I would have said Windows software. Which 3 things specifically do you mean? I don't think I understand how reflection or language services are an editing software. Honestly, I didn't reply to a lot of what was said there because it sounds like your trying to take credit for writing Varnish or something and seems like that's probably not true at all. Oh well, come to a thread about .Net expect people who know it well to point out the inaccuracies in what you are saying- most of it is uninformed FUD. I'm sure bringing back CGI is really going to start taking off ;)

Seriously though, its these off-the-wall concepts like what I've seen described here that put the stability of FreeBSD at risk. I came here because people were discussing real software that's really about to come out and came across this lunacy. Probably the safest thing to do for newer developers is not listen to the people whom have limited firsthand experience with whatever/however they are bashing technology "X" right now.

That's quite a riddle. I'm aware of only one site matching that definition and it belongs to a certain Russian social network. You can actually look at the snapshot of a part of their stack here.

Says GPLv2 is assumed?? o_O Sorry- no thanks for obvious reasons. You come on this forum trying to advocate for some copyleft software- I do not sign ANYTHING when I install C# nor do I agree to the GPL2. Just PHP in general? :confused: not interested and haven't been for many years since PECL dumped all their bins out of the blue one day. I'd rather not be tied to FaceBook or what they want to do and probably right now is the worst possible moment.

So- when you have some real stats, licensing agreement, and not just copying the startup world let me know and maybe I'll give it an honest look in comparison to C# so far the strategy of being so derivative you may as well just be a clone is what I see here.
 
It's used in read_ibdiag_config() below on tokenized input from config file, and it's intentional, especially for same strncmp() calls on 'name' part where you obviously don't have terminating NUL and need to compare only the bytes that are meaningful for current token check.
 
It's used in read_ibdiag_config() below on tokenized input from config file, and it's intentional, especially for same strncmp() calls on 'name' part where you obviously don't have terminating NUL and need to compare only the bytes that are meaningful for current token check.

Are you saying it wouldn't match more things than "TRUE" or just that it doesn't matter in that context? (It really doesn't, if that were a serious bug it would be fixed already.)
 
Oh well, come to a thread about .Net expect people who know it well to point out the inaccuracies in what you are saying- most of it is uninformed FUD.
I may have too quickly responded to your post, and I am still only giving a quick response, but any time someone advocates using .NET on FreeBSD--or Linux for that matter--it is often forgotten that .NET, and all its associated software, has the main goal of working with Microsoft and Windows software. People forget or ignore that and dutifully concern themselves with learning these non-native tools because Microsoft, the internet, and reddit told them to--and no other reason--thus inflicting wounds on themselves and ignoring all the built-ins available on their own machine. I suffered these wounds at the hands of Microsoft 15 years ago and will never forgive or forget.

If this is not what your post is about, then sorry, today is exhausting.

Seriously though, its these off-the-wall concepts like what I've seen described here that put the stability of FreeBSD at risk.
FreeBSD has no issues with stability. Unlike Microsoft and their products which are a quagmire of instability.
 
Are you saying it wouldn't match more things than "TRUE" or just that it doesn't matter in that context? (It really doesn't, if that were a serious bug it would be fixed already.)

So I was re-reading the code, and given that strtok() replaces separators with NUL, there's really no reason to use strncmp(), it seems.
 
given that strtok() replaces separators with NUL, there's really no reason to use strncmp(), it seems.

If you say so... I don't really write C code, so I don't have any specific opinion here. I also don't care whether it was programmer's error or intentionally sloppy code, the point is that C isn't a particularly good fit for ad hoc string manipulation.
 
the point is that C isn't a particularly good fit for ad hoc string manipulation.
I don't know what you mean by that but anything any language can do with strings, C can do better, though not as easily in some cases, unless you have functions for those things. But you only write those functions once. C has no issues manipulating strings.
 
I may have too quickly responded to your post, and I am still only giving a quick response, but any time someone advocates using .NET on FreeBSD--or Linux for that matter--it is often forgotten that .NET, and all its associated software, has the main goal of working with Microsoft and Windows software. People forget or ignore that and dutifully concern themselves with learning these non-native tools because Microsoft, the internet, and reddit told them to--and no other reason--thus inflicting wounds on themselves and ignoring all the built-ins available on their own machine. I suffered these wounds at the hands of Microsoft 15 years ago and will never forgive or forget.

If this is not what your post is about, then sorry, today is exhausting.


FreeBSD has no issues with stability. Unlike Microsoft and their products which are a quagmire of instability.

Understood. Yeah it's interesting how on one end I had the same thing happen with PHP and your motivation is a similar experience and that I can totally understand! Certainly I'm not going to say Microsoft is the ideal situation itself however they are *trying* as-in I can actually go to them about FreeBSD in particular and they attempt to do something as-in patch things in CoreCLR specific for the BSD kernel. Really, there are a lot of places in the CoreCLR source where if they used less MacOS specific code and just stuck with the BSD code on Darwin it wouldn't be such a monumental effort to port it in the first place- just due to how much time has passed. I've been developing SharePoint custom solutions for quite some time now (for the government) and in no way will I say until recently they've been on the right path. To top that off I have known devs that did some time in Redmond that explain some of the situations they get in. I tend to agree with their sentiment they are too large and disorganized to be "evil" as they once were to OSS.

I think election season this year has me feeling especially rabid I don't consider us even a worthwhile target (not associated with DoD or anything) but still the door knob rattling around the clock is insane. Just imagine DDoS attempts originating from your A/C control systems- it's crazy! Anyhow, I still love developing on FreeBSD to this day and hope that as a development platform it continues to grow in that regard whichever language anyone chooses to code with. I read through a long discussion on HN recently and seems like there is a younger generation looking to upend just OOP altogether so things are definitely starting to get interesting.
 
This thread has gone off the rails - but I'm not complaining. Great comments by all. .NET Core (or "Standard") sheds much of the windows dependencies that tie .NET Framework to Windows. That ejects all the GUI bits that server apps don't need.

Linux is a great alternative to Windows for running .NET Core apps. Maintaining .NET Core on FreeBSD ensures that Linux is not the only alternative OS to Windows for Core apps. If a few companies adopt FreeBSD because of this - even better.
 
If a few companies adopt FreeBSD because of this - even better.

Agreed. If this additional flexibility allows some innovative companies to step outside the Microsoft square and to an OS platform that better fits their needs, then I am of course glad that Mono (in particular) exists.
I am just hoping that it of course wont drag some more naive companies away from i.e Linux and into the Microsoft prison because they have tied themselves too closely to .NET by bad decisions (and Microsoft's EEE strategy).
 
Back
Top