I worked on Mono a lot back in the early 2000s (back in the SVN days before it moved to Git, even). This move makes a lot of sense. Things evolved a lot over the years. Mono's legacy goals, which are to be a portable CLR (.NET) runtime for platforms that Microsoft didn't care about, don't make much sense today.
Mono made a lot of sense for running places where full .NET didn't, like in full AOT environments like on the iPhone where you can't JIT, or for random architectures that don't matter anymore but once did for Linux (Alpha, Itanium, PPC, MIPs, etc.). When Microsoft bought Xamarin (which itself was born out of the ashes of the Novell shutdown of the Mono effort) and started the DotNET Core efforts to make .NET more portable itself and less a system-provided framework and merge in a lot of the stuff Mono did a single more focused project made more sense.
Mono was still left out there to support the edge cases where DotNET Core didn't make sense, which was mostly things like being a backend for Wine stuff in some cases, some GNOME Desktop stuff (via GTK#, which is pretty dead now), and older niche use cases (second life and Unity still embed mono as a runtime for their systems). The project was limping, though, and sharing a standard library but different runtimes after much merging. Mono's runtime was always a little more portable (C instead of C++) and more accessible to experiment with, but we need that less and less, but it's still perfect for Wine. So, having it live on in Wine makes sense. It's a natural fit.
Is there somewhere where someone new to the ecosystem can get a simple introduction to all of these different terms and which ones are still relevant today? I looked into .NET somewhat recently and came away with the apparently mistaken impression that Mono was how .NET did cross-platform. I guess I must have been reading old docs, but I'm pretty sure they were at least semi-official.
Is there good documentation somewhere for getting set up to develop with modern .NET on Linux?
i want to love dotnet-core, especially since godot switched from mono in godot 3 to dotnet-core in godot 4, but so far i haven't been able to
currently debian has a mono package but no dotnet-core package. i'm not sure why this is; usually when debian lacks a popular nominally open-source package like this, it's either because it fails to build from source, or because it has some kind of tricky licensing pitfall that most people haven't noticed, but diligent debian developers have
does anyone know why this problem exists for dotnet-core?
also, does dotnet-core have a reasonable aot story for things like esp32 and ch32v003?
It never had any sense, and it never had any future. We told Miguel he would be playing the chase game with Microsoft and he will always be behind and never being sure if MS won't use the patent card if Mono actually becomes dangerous (and they can get quite nasty when pissed off - see the accusations against ReactOS).
But he was in love with COM/DCOM, registry, and many other things that MS shipped. Some of these things made Gnome much slower than it could be.
I always assumed Microsoft did not condone Wine or other re-implementations of their APIs (like ReactOS), but that they were protected by DMCA reverse engineering provisions and anyway too insignificant to send the legal team after.
Wikipedia says,
> Until 2020, Microsoft had not made any public statements about Wine. ... On 16 February 2005, Ivan Leo Puoti discovered that Microsoft had started checking the Windows Registry for the Wine configuration key and would block the Windows Update for any component. As Puoti noted: "It's also the first time Microsoft acknowledges the existence of Wine."
> In January 2020, Microsoft cited Wine as a positive consequence of being able to reimplement APIs, in its amicus curiae brief for Google LLC v. Oracle America, Inc.
I think Microsoft has finally realized that its animus toward projects like Wine and pre-acquisition Mono was ultimately unproductive, and a net negative for Microsoft itself.
I still don't trust MS's motives in general, but I think they at least recognize that Wine/Proton helps make the Win32 and DirectX APIs a sort of de-facto cross-platform standard when it comes to things like desktop gaming, and that this is a good thing for them.
On the server side, MS knows that Linux is by far the most popular server OS, and official support for running .NET backend apps on Linux from MS themselves is a win for them as well.
Microsoft in 2024 feels like a different beast. All the MS devs I know seem fully on board with totally cross-platform support. Half of them are coding on MacBooks and I would hazard a guess that a good proportion of .NET web sites being built are being deployed onto Linux boxen.
If Windows Update replaced components of Wine, that would (a) break people's Wine installs, and (b) give those users a way to legally get Microsoft's versions of those components for use outside of Windows.
Even if Wine had become drop in replacement for modern Windows distribution, I doubt it would hurt much. Business would likely still buy Windows, because of support and security patches. Consumers would get their Windows preinstalled. Some manufacturers would probably do Wine installations - but then it would depend on support. Don't want to sell machines to people who are not tech savvy, that are not getting updates. That is a potential for returns and massive cost and headache.
AWS Supports one of the tools for porting out of AWS. Supporting something that looks like an escape valve (whether it works or not) keeps the antitrust people off your neck.
I mean, if wine is a problem they did basically the same thing with the WSL, especially version 1 (version 2 is just a VM, but the concept of running unmodified Linux binaries on Windows like they are native application is the same).
I think that they don't care about going against the open soruce community, given that Microsoft uses a lot of open source software in their products (also, probably violates the terms of the GPL license of such software).
Fun fact: Second Life, the virtual world, has an in-world scripting language called LSL, and it gets compiled to bytecode that gets run on a virtual machine. Initially, it got compiled to bytecode that ran on an in-house virtual machine, but in 2008, they switched over to compiling LSL to Mono bytecode to run on the Mono virtual machine. I wonder if that's still how it works. (I haven't been involved with SL for a long time.)
We're hard at work adding Luau (https://luau.org) as a supported language for both in-world scripting as well as client/viewer-side scripting. As a handy byproduct of that, LSL will also gain the ability to be compiled to Luau bytecode, allowing us to eventually (someday, at least) shed any need for our custom-patched version of Mono 2.6. More juicy details here: https://wiki.secondlife.com/wiki/Lua_FAQ
Microsoft's own FOSS multiplatform implementation of the .NET runtime is now much more performant and feature complete than Mono.
However Mono is easier to embed into other applications and easier to port to new platforms. That is for example why it's used for the .NET/Blazor WebAssembly stuff. Microsoft still maintains their own fork of Mono for this specific use case.
Mono also implements some of the legacy Windows Desktop GUI frameworks like WinForms and WPF that Microsoft never bothered to port to their new .NET runtime. This is probably why the Wine developers might be interested in Mono.
Wine has (or used to have anyway, not sure if it still does) a version of Mono it used to run .NET stuff within Wine; I'd assume this has to do with that, that they were relatively alone in having a continuing interest in the Mono codebase vs. the dotnet core stuff.
I think it's just hurting someone at Microsoft less if they give it a home that isn't /dev/null.
Edit: quick hat tip to Mono.Cecil which I've used a couple of times to crack .Net components to bypass licensing code. It's not that we didn't pay for them but we couldn't be bothered to deal with license deployment and maintenance.
Mono was very useful in university. Must have been 2005 when I got asked if I wanted to use Java or C# for the programming course. Being bored with Java I picked C#. We were a very small group of two students.
But as I just had a Powerbook I used Mono to run it on OS X. At the end of the course someone from Microsoft came to the university to answer any of our question about upcoming features in .NET and C#. And as we were a small group I set directly in front of him with the shiny apple point at him.
Very interesting language at that time. .NET not so much. Also still remember that we were tasked to implement 3 sort algorithms of our choice. One of mine was bogosort and with Mono on PPC it could sort up to 7 elements, before becoming really slow.
8! is 40320. Even if it took 10 times as many iterations to find the correct order, it would still only be less than 4 million swaps. Just how slow was that computer?
A bit off-topic, but this makes me wonder about the relationship between Microsoft and Wine. Do they consider it a threat? An ally? Both?
This is my first time seeing Microsoft acknowledge Wine's existence, and in this case, it was at least in a friendly manner? Or could there be bad faith behind this 'donation'?
Another poster quoted Wikipedia somewhere here; MS implicitly acknowledged Wine's existence back in 2005 when they added a check for some of Wine's registry keys which would disable Windows Update if it found them. And in 2020 MS filed an Amicus brief in that Google/Oracle lawsuit in support of free re-implementations of APIs, citing Wine as a positive example.
While I am still wary of Microsoft after their previous anti-competitive behaviors, I think they've taken a more pragmatic view of late, and realize that projects like Wine are actually good for their platform as a whole. I expect if Wine/Proton did not exist, we'd see more (for example) Windows-only games ported to macOS or Linux. With Wine/Proton, those ports are mostly not necessary, and Microsoft gets to say that Win32/DirectX is something of a cross-platform gaming "standard".
What could WINE possibly do to them? Rob them of all kinds of enterprise and cloud business? WINE is a single LED on a nuclear powerplant control panel.
The best Wine environment is still a Windows install. You need a lot of things to do to run some of the mill Win32 app, so Wine is not a direct threat for MS in any foreseeable future.
I know it's a long-standing empirical truth that anyone involved with Mono is required to prefer doing just about anything besides thinking about or touching what's on the Mono project website, but this announcement really deserves to be put on page unto itself with a URL all its own, rather than shoehorned into an anonymous div on the Mono landing page and at the top of /news.
It seems like the link we got (https://www.mono-project.com) might be the URL for the announcement - that's to say, this is the last update on that website, and will stay there indefinitely.
Thank you, I’ve been looking for an explanation of this. So Mono is useful to Wine because its users care more about licensing and running legacy software: Mono is free software and an acceptable runtime for pre-.NET 5.0 stuff.
I like the strategic approach. Pay attention software publishers, and hardware manufacturers! You can gain some significant public accolades.
When a publisher or manufacturer wants to end a product line, instead of shutting it down, spin it out as F/LOSS, and give it some seed money. If the thing is good, people will pick it up and it will survive. If not, the company still gains public appreciation.
This dovetails well as a potential solution into the problem we are discussing in the Smart TV, smart home, smart vehicle articles.
For everyone who is confused by what is going on, here's the explanation:
Today, there are 2.5 Mono's:
Mono that lives in https://github.com/mono/mono. This is the original Mono codebase that was written back then and was the .NET Framework for Linux, with corresponding compat. and such, pioneered by Miguel De Icaza, who now seems to be happier in Swift land. At the present day, it was receiving very little maintenance and I don't believe was actively used. Please correct me if I'm wrong.
Mono that lives in https://github.com/dotnet/runtime/tree/main/src/mono. This is the Mono that got merged into .NET, becoming the building block for multiple components and one of the official runtime flavours. It is actively maintained and is at relative feature parity with CoreCLR, predominantly serving mobile targets (iOS, Android) and WASM as well as exotic or legacy targets like ARMv6, LA64, s390x(?), ppc64. It is also useful for initial stages of new platform bring-up process. Note that you are not expected to use it for targets that support CoreCLR due to a massive rift in performance between the two. When you are using it, you do so as a part of standard .NET toolchain - it is picked automatically for appropriate targets, or can be opted into with some configuration.
Mono that lives in https://gitlab.winehq.org/wine-mono/mono which is a Mono fork actively maintained by Wine for its own usage. Going forward, any possible ambiguities regarding ownership and stewardship are considered resolved and the ownership of mono/mono and everything related to it is transferred to WineHQ.
Honorable mention also goes to private Mono fork used by Unity which they are (painfully) trying to migrate from.
I'm genuinely curious, for someone who develops web application backends and larger distributed systems & infrastructure, predominantly using Go and Python, exclusively targeting Linux, is there anything in the .NET ecosystem that anyone would recommend I take a look at? Many thanks.
.NET Core is my favorite way to quickly implement an app to run on a Raspberry Pi. Just basically copy & paste into a folder, chmod the executable and off you go.
I have a number of these devices running in the house doing various things.
Modern .net on Linux is lovely, you can initialize a project, pull in the S3 client and write a 1-3 line C# program that AOT compiles to a single binary with none of the perf issues or GIL hand-wringing that plagues life in Python.
Given modern Python means type annotations everywhere, the convenience edge between it and modern C# (which dispenses with much of the javaesque boilerplate) is surprisingly thin, and the capabilities of the .net runtime far superior in many ways, making it quite an appealing alternative especially for perf sensitive stuff.
> for someone who develops web application backends and larger distributed systems
Blazor: It's Microsoft's way of doing in-browser C#. It can do quick-and-dirty server-side HTML, and professional-grade, in-browser WASM.
Why is this useful "for someone who develops web application backends"?
The nice thing about server-side Blazor is that you can make a management console, or otherwise port ops scripts, into a self-service page. Because you can choose to render on the server, you don't have to write an API, serialize your response, ect. You can do a SQL-ish query (with LINQ and Entity Framework) in the middle of HTML.
(Granted, for production-grade pages Blazor can run in the browser as WASM and use industrial-strength APIs.)
As someone in same spot I'll say that .NET looks more than interesting after so many years using 6-8 languages daily. And I'm more "make it works, not shine" type.
Why .NET > Go in my opinion?
- performance-wise the gap is not big and probably even .NET can be quicker
- development time can be reduced, tooling is great for .NET and even funny-not-funny error handling is cleaner
- still much easier to find people in .NET than Go where I live and work
Now it's time to verify those assumptions - I'm going to implement next real project in .NET and see how it went. Hobby or "trials" in .NET resulted in fun and speed, but it often happens on first date :)
Although the SQL-like form isn't always favoured, and quite a lot of the time I use the plain OO one.
Oh yes, extension methods: do you want object X to support method Y, but can't change object X? Well, provided you don't need access to anything private, you can just add a method and do X.Y()
Can anybody speak to the accounting implications of "donating" software to a foundation/501(c)3? Can there be any kind of tax write-off? (It looks like this might already have been owned by a foundation, but I'm still generally curious)
This will sound pretty dumb, but with all the amazing cross platform games written in Unity - which I thought was Mono or some form of cross platform library with .NET as one of the primary languages, I always wondered why there was not a more 'business app version' of this. After using Xamarin, Appcelerator, and dozens of other 'cross platform tools', with to be let down from ALL of them in the end and/or support dropped.... Having to support multiple platforms, esp. IOS vs. Android still seems to be stuck in the stone ages, esp. for small dev teams that can't allocate massive resources to multi-platform...
If you want a consistent UI (non-native look), your best bet may be Blazor Hybrid currently. Yes, it's web technology (with the overhead that comes with that), but at least it uses the native browser components, so it's not nearly as "heavyweight" as something like Electron. My main concern has always been the lack of Linux support, but maybe that's not an issue for you.
I have only used mono a couple times, but I am a bit confused by the wording here and it is likely because I don't know the full story of Mono.
But:
> Microsoft maintains a modern fork of Mono runtime in the dotnet/runtime repo and has been progressively moving workloads to that fork.
Does that mean that this mono project and its associated repo and what is within the dotnet repo are not the same and could (if they have not already) diverge?
Mono has no reason to live anymore, hence the lack of commits and contributions
It is a dead project, I wonder what winehq has in mind here
edit: as pointed by the comments, mono supports .net runtime before the newer ".net core" (which is not compatible). Because wine wants to be able to run older windows code, they probably still use this.
> Does that mean that this mono project and its associated repo and what is within the dotnet repo are not the same and could (if they have not already) diverge?
Yes, they have diverged. Just as Microsoft forked the CLR to create CoreCLR, so too has mono been forked. Features like multiple AppDomains have been removed from this fork. Here is an example pull request:
The thing the .NET team maintains is (a fork of) the Mono Runtime/JIT. Mono's implementation of the .NET Framework BCL (= stdlib) isn't part of modern .NET.
> We want to recognize that the Mono Project was the first .NET implementation on Android, iOS, Linux, and other operating systems.
Is this true? The pre-releases and version 1 of .Net came with the source for a reference implementation of the CLR that ran on Linux or BSD. I can't remember what license it had and I thought Mono was a separate project, but maybe Mono was based on it. Not that it matters now.
You are thinking of Rotor. FWIW, I also feel as if Portable.NET--which was rebranded at some point to DotGNU when I think it was even donated to the FSF--had predated Mono in functioning?
The Mono website has an archive of an old mailing list post which at the time talks about even-older origin of the project. It is (of course) heavily biased for Mono, and hilariously gives me an awkward shout out ;P.
Mono is still really the only way to run older .NET (pre FOSS runtime/Core .NET) on non-Windows platforms.
So Wine has historically kept a fork of mono for use within Wine for supporting .NET apps.
Modern .NET can be built for Linux, etc so this is less relevant now but there are still a lot of apps that depend on old .NET and Wine still gets value out of that.
There are a bunch of downstreams that get used for various purposes (Microsoft uses mono for webasm embedded .NET for example) so it makes sense to give over ownership of Mono to the Wine community as they are best aligned with the original upstream's intended use case (as a full replacement for .NET).
So yes it's on life support but arguably more in the sense that it has since specialized into a bunch of downstream projects. The upstream will probably mainly be used for coordinating common improvements that all of the downstream forks care about (which are mainly Wine and Microsoft).
Look at the release history and you'll see it was already on life support. MS stopped adding new features to .NET Framework with 4.8 but Mono has yet to reach parity with that.
What does 'donate' mean? Does it essentially mean that they're abandoning it and pull all resources, while the Wine team is welcome to continue maintaining it if they want to?
Also, I'm not sure how relevant Mono is in the context of Wine. .NET Core is no longer an OS component, but just a runtime that ships with software. Imo their focus should be on getting said runtime working, rather than maintaining a .NET fork.
I'm not a gamer so forgive me if I see connections that aren't there. Does this in any way impact game emulation? Isn't wine part of proton or stream attempts to run windows games on Linux? I suppose .net and clr play some time in win32, how is that usually emulated?
I think it makes sense. Considering that they are two competing technologies which more or less try to accomplish the same thing - make Microsoft technologies compatible with other platforms.
Is this a "dropped on community" project like Borg/Kubernetes fiasco with most PRs ending up in the following, and just corpo-sponsored changes and patches getting through?
> The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
wine-mono for one. It's also used for some desktop apps, crucially for those built with the WinForms framework, since the newer, .NET Core versions of that are Windows-only.
Based on how Xamarin performed prior to the MS acquisition, I'd guess dead.
The license cost was high, and the MS acquisition came right around the time React Native and Flutter started to enter v1. I think they'd of been blown out of the water pretty quickly. At least Microsoft allowed Xamarin to get into enterprise .NET shops pretty quickly. There's a lot of B2B form based apps written in Xamarin. I worked on a pretty big one that made (and continues to make) a lot of money.
I've long assumed the point of the acquisition was because Xamarin did basically all the hard work of allowing .NET to be cross platform.
Perhaps us C programmers should be telling the Rust programmers to stop shitting up the industry for everyone else because "C" is too hard to get right?
Really, point aside, there is no place for zealots and many places for a rational decision analysis in what tools to use. Absolutes and extremism are all bad.
> If Rust is "too hard", find some other profession and stop shitting up the industry for everyone else.
If you really like Rust you should promote it by using it to write great tools that inspire others to use it, instead of shitting on people who use other tools to do actual work.
That’s the old code base which has been in maintenance mode for 5 years and which Microsoft doesn’t want to maintain anymore. New development still happen in a fork which remains under the stewardship of Microsoft.
Second paragraph of the article by the way, just saying.
Another perfect execution of embrace(Microsoft became the steward of the Mono Project when it acquired Xamarin), extend(Microsoft maintains a modern fork of Mono runtime in the dotnet/runtime repo and has been progressively moving workloads to that fork), extinguish(we recommend that active Mono users and maintainers of Mono-based app frameworks migrate to .NET) for anyone who thought MS had actually changed since the bad old days.
Only wrinkle is that Mono was originally a .NET runtime for Linux. So they weren't embracing an external standard but a knock-off of their own. But I still agree with elements of your statement in principle. However, giving Mono back to open source is an interesting development and I don't know how it fits in your narrative.
That's not what EEE is. For starters, the term applies to standards, not to implementations. The standard here is .NET, which Microsoft controlled from the start.
Some comments were deferred for faster rendering.
zbowling|1 year ago
Mono made a lot of sense for running places where full .NET didn't, like in full AOT environments like on the iPhone where you can't JIT, or for random architectures that don't matter anymore but once did for Linux (Alpha, Itanium, PPC, MIPs, etc.). When Microsoft bought Xamarin (which itself was born out of the ashes of the Novell shutdown of the Mono effort) and started the DotNET Core efforts to make .NET more portable itself and less a system-provided framework and merge in a lot of the stuff Mono did a single more focused project made more sense.
Mono was still left out there to support the edge cases where DotNET Core didn't make sense, which was mostly things like being a backend for Wine stuff in some cases, some GNOME Desktop stuff (via GTK#, which is pretty dead now), and older niche use cases (second life and Unity still embed mono as a runtime for their systems). The project was limping, though, and sharing a standard library but different runtimes after much merging. Mono's runtime was always a little more portable (C instead of C++) and more accessible to experiment with, but we need that less and less, but it's still perfect for Wine. So, having it live on in Wine makes sense. It's a natural fit.
lolinder|1 year ago
Is there good documentation somewhere for getting set up to develop with modern .NET on Linux?
kragen|1 year ago
currently debian has a mono package but no dotnet-core package. i'm not sure why this is; usually when debian lacks a popular nominally open-source package like this, it's either because it fails to build from source, or because it has some kind of tricky licensing pitfall that most people haven't noticed, but diligent debian developers have
does anyone know why this problem exists for dotnet-core?
also, does dotnet-core have a reasonable aot story for things like esp32 and ch32v003?
neonsunset|1 year ago
guappa|1 year ago
Does the wine project have the resources and knowledge to maintain it?
Or is it just so that microsoft can say they aren't the ones discontinuing it?
dvfjsdhgfv|1 year ago
But he was in love with COM/DCOM, registry, and many other things that MS shipped. Some of these things made Gnome much slower than it could be.
sebazzz|1 year ago
pipes|1 year ago
johnwheeler|1 year ago
hacker_88|1 year ago
adriamaker|1 year ago
rgovostes|1 year ago
Wikipedia says,
> Until 2020, Microsoft had not made any public statements about Wine. ... On 16 February 2005, Ivan Leo Puoti discovered that Microsoft had started checking the Windows Registry for the Wine configuration key and would block the Windows Update for any component. As Puoti noted: "It's also the first time Microsoft acknowledges the existence of Wine."
> In January 2020, Microsoft cited Wine as a positive consequence of being able to reimplement APIs, in its amicus curiae brief for Google LLC v. Oracle America, Inc.
kelnos|1 year ago
I still don't trust MS's motives in general, but I think they at least recognize that Wine/Proton helps make the Win32 and DirectX APIs a sort of de-facto cross-platform standard when it comes to things like desktop gaming, and that this is a good thing for them.
On the server side, MS knows that Linux is by far the most popular server OS, and official support for running .NET backend apps on Linux from MS themselves is a win for them as well.
qingcharles|1 year ago
jimrandomh|1 year ago
Brian_K_White|1 year ago
varispeed|1 year ago
hinkley|1 year ago
ijidak|1 year ago
It's hazy to me when reverse engineering of APIs is and isn't allowed.
alerighi|1 year ago
I think that they don't care about going against the open soruce community, given that Microsoft uses a lot of open source software in their products (also, probably violates the terms of the GPL license of such software).
troymc|1 year ago
toastercup|1 year ago
We're hard at work adding Luau (https://luau.org) as a supported language for both in-world scripting as well as client/viewer-side scripting. As a handy byproduct of that, LSL will also gain the ability to be compiled to Luau bytecode, allowing us to eventually (someday, at least) shed any need for our custom-patched version of Mono 2.6. More juicy details here: https://wiki.secondlife.com/wiki/Lua_FAQ
Source: I work at Linden Lab. If these sorts of things excite anyone, we're hiring! https://lindenlab.com/careers
qingcharles|1 year ago
rickcarlino|1 year ago
dtquad|1 year ago
However Mono is easier to embed into other applications and easier to port to new platforms. That is for example why it's used for the .NET/Blazor WebAssembly stuff. Microsoft still maintains their own fork of Mono for this specific use case.
Mono also implements some of the legacy Windows Desktop GUI frameworks like WinForms and WPF that Microsoft never bothered to port to their new .NET runtime. This is probably why the Wine developers might be interested in Mono.
jcims|1 year ago
zerocrates|1 year ago
minkles|1 year ago
Edit: quick hat tip to Mono.Cecil which I've used a couple of times to crack .Net components to bypass licensing code. It's not that we didn't pay for them but we couldn't be bothered to deal with license deployment and maintenance.
nedt|1 year ago
But as I just had a Powerbook I used Mono to run it on OS X. At the end of the course someone from Microsoft came to the university to answer any of our question about upcoming features in .NET and C#. And as we were a small group I set directly in front of him with the shiny apple point at him.
Very interesting language at that time. .NET not so much. Also still remember that we were tasked to implement 3 sort algorithms of our choice. One of mine was bogosort and with Mono on PPC it could sort up to 7 elements, before becoming really slow.
fluoridation|1 year ago
pentagrama|1 year ago
This is my first time seeing Microsoft acknowledge Wine's existence, and in this case, it was at least in a friendly manner? Or could there be bad faith behind this 'donation'?
kelnos|1 year ago
While I am still wary of Microsoft after their previous anti-competitive behaviors, I think they've taken a more pragmatic view of late, and realize that projects like Wine are actually good for their platform as a whole. I expect if Wine/Proton did not exist, we'd see more (for example) Windows-only games ported to macOS or Linux. With Wine/Proton, those ports are mostly not necessary, and Microsoft gets to say that Win32/DirectX is something of a cross-platform gaming "standard".
datavirtue|1 year ago
justsomehnguy|1 year ago
cxr|1 year ago
See <https://simonwillison.net/2024/Jul/13/give-people-something-...>.
romwell|1 year ago
__s|1 year ago
nequo|1 year ago
WaitWaitWha|1 year ago
When a publisher or manufacturer wants to end a product line, instead of shutting it down, spin it out as F/LOSS, and give it some seed money. If the thing is good, people will pick it up and it will survive. If not, the company still gains public appreciation.
This dovetails well as a potential solution into the problem we are discussing in the Smart TV, smart home, smart vehicle articles.
whyenot|1 year ago
(if you respond, please, lets not get into his politics; HN is not the right place to have that kind of discussion)
zbowling|1 year ago
neonsunset|1 year ago
Today, there are 2.5 Mono's:
Mono that lives in https://github.com/mono/mono. This is the original Mono codebase that was written back then and was the .NET Framework for Linux, with corresponding compat. and such, pioneered by Miguel De Icaza, who now seems to be happier in Swift land. At the present day, it was receiving very little maintenance and I don't believe was actively used. Please correct me if I'm wrong.
Mono that lives in https://github.com/dotnet/runtime/tree/main/src/mono. This is the Mono that got merged into .NET, becoming the building block for multiple components and one of the official runtime flavours. It is actively maintained and is at relative feature parity with CoreCLR, predominantly serving mobile targets (iOS, Android) and WASM as well as exotic or legacy targets like ARMv6, LA64, s390x(?), ppc64. It is also useful for initial stages of new platform bring-up process. Note that you are not expected to use it for targets that support CoreCLR due to a massive rift in performance between the two. When you are using it, you do so as a part of standard .NET toolchain - it is picked automatically for appropriate targets, or can be opted into with some configuration.
Mono that lives in https://gitlab.winehq.org/wine-mono/mono which is a Mono fork actively maintained by Wine for its own usage. Going forward, any possible ambiguities regarding ownership and stewardship are considered resolved and the ownership of mono/mono and everything related to it is transferred to WineHQ.
Honorable mention also goes to private Mono fork used by Unity which they are (painfully) trying to migrate from.
Rochus|1 year ago
Not that massive; factor 1.8 as we found out recently.
unknown|1 year ago
[deleted]
pdmccormick|1 year ago
starik36|1 year ago
I have a number of these devices running in the house doing various things.
BeetleB|1 year ago
dmw_ng|1 year ago
Given modern Python means type annotations everywhere, the convenience edge between it and modern C# (which dispenses with much of the javaesque boilerplate) is surprisingly thin, and the capabilities of the .net runtime far superior in many ways, making it quite an appealing alternative especially for perf sensitive stuff.
gwbas1c|1 year ago
Blazor: It's Microsoft's way of doing in-browser C#. It can do quick-and-dirty server-side HTML, and professional-grade, in-browser WASM.
Why is this useful "for someone who develops web application backends"?
The nice thing about server-side Blazor is that you can make a management console, or otherwise port ops scripts, into a self-service page. Because you can choose to render on the server, you don't have to write an API, serialize your response, ect. You can do a SQL-ish query (with LINQ and Entity Framework) in the middle of HTML.
(Granted, for production-grade pages Blazor can run in the browser as WASM and use industrial-strength APIs.)
misiek08|1 year ago
Why .NET > Go in my opinion? - performance-wise the gap is not big and probably even .NET can be quicker - development time can be reduced, tooling is great for .NET and even funny-not-funny error handling is cleaner - still much easier to find people in .NET than Go where I live and work
Now it's time to verify those assumptions - I'm going to implement next real project in .NET and see how it went. Hobby or "trials" in .NET resulted in fun and speed, but it often happens on first date :)
hakanderyal|1 year ago
Binaries will be huge tho compared to Go. I’ve a few CLIs that I that I my customers need to use, I’m planning to rewrite them in Go for this reason.
pjc50|1 year ago
https://learn.microsoft.com/en-us/dotnet/csharp/linq/get-sta...
Although the SQL-like form isn't always favoured, and quite a lot of the time I use the plain OO one.
Oh yes, extension methods: do you want object X to support method Y, but can't change object X? Well, provided you don't need access to anything private, you can just add a method and do X.Y()
lostmsu|1 year ago
Refactoring tooling is unmatched.
philip1209|1 year ago
IshKebab|1 year ago
methods21|1 year ago
bootloop|1 year ago
And making a cross platform app framework which looks like native UI is much harder.
In contrast, Unity's UI systems are all terrible and looking native isn't even one of their goals.
dax_|1 year ago
hilux|1 year ago
I'm a little out-of-the-loop here.
Does this announcement mean that Microsoft used to fund developers to work on this project, and now will cut that funding?
nerdjon|1 year ago
But:
> Microsoft maintains a modern fork of Mono runtime in the dotnet/runtime repo and has been progressively moving workloads to that fork.
Does that mean that this mono project and its associated repo and what is within the dotnet repo are not the same and could (if they have not already) diverge?
JackSlateur|1 year ago
Since then, microsoft supports https://github.com/dotnet/runtime, which is MIT licensed
Mono has no reason to live anymore, hence the lack of commits and contributions
It is a dead project, I wonder what winehq has in mind here
edit: as pointed by the comments, mono supports .net runtime before the newer ".net core" (which is not compatible). Because wine wants to be able to run older windows code, they probably still use this.
MarkSweep|1 year ago
Yes, they have diverged. Just as Microsoft forked the CLR to create CoreCLR, so too has mono been forked. Features like multiple AppDomains have been removed from this fork. Here is an example pull request:
https://github.com/dotnet/runtime/pull/47955
YoshiRulz|1 year ago
unknown|1 year ago
[deleted]
masfuerte|1 year ago
Is this true? The pre-releases and version 1 of .Net came with the source for a reference implementation of the CLR that ran on Linux or BSD. I can't remember what license it had and I thought Mono was a separate project, but maybe Mono was based on it. Not that it matters now.
saurik|1 year ago
The Mono website has an archive of an old mailing list post which at the time talks about even-older origin of the project. It is (of course) heavily biased for Mono, and hilariously gives me an awkward shout out ;P.
https://www.mono-project.com/archived/mailpostearlystory/
tredre3|1 year ago
Lagacy .Net never supported OSes other than Windows. Mono, released in 2004, was the first attempt to bring it to other OSes.
donatj|1 year ago
Wytwwww|1 year ago
jacoblambda|1 year ago
Mono is still really the only way to run older .NET (pre FOSS runtime/Core .NET) on non-Windows platforms.
So Wine has historically kept a fork of mono for use within Wine for supporting .NET apps.
Modern .NET can be built for Linux, etc so this is less relevant now but there are still a lot of apps that depend on old .NET and Wine still gets value out of that.
There are a bunch of downstreams that get used for various purposes (Microsoft uses mono for webasm embedded .NET for example) so it makes sense to give over ownership of Mono to the Wine community as they are best aligned with the original upstream's intended use case (as a full replacement for .NET).
So yes it's on life support but arguably more in the sense that it has since specialized into a bunch of downstream projects. The upstream will probably mainly be used for coordinating common improvements that all of the downstream forks care about (which are mainly Wine and Microsoft).
unknown|1 year ago
[deleted]
YoshiRulz|1 year ago
signa11|1 year ago
torginus|1 year ago
Also, I'm not sure how relevant Mono is in the context of Wine. .NET Core is no longer an OS component, but just a runtime that ships with software. Imo their focus should be on getting said runtime working, rather than maintaining a .NET fork.
YoshiRulz|1 year ago
alberth|1 year ago
https://www.bloomberg.com/news/articles/2016-02-25/microsoft...
stefanos82|1 year ago
This way will allow them to improve Mono accordingly? Who knows? /me-thinks...
repelsteeltje|1 year ago
tapoxi|1 year ago
Games themselves typically aren't .NET but ancillary components, like launchers or map editors, are.
Y_Y|1 year ago
but it is indeed the basis for Proton
justsomehnguy|1 year ago
alchemio|1 year ago
pyeri|1 year ago
DrNosferatu|1 year ago
DrNosferatu|1 year ago
purplezooey|1 year ago
Havoc|1 year ago
Or is this more of a steward role rather than technical connection
aussieguy1234|1 year ago
Kwpolska|1 year ago
peppertree|1 year ago
bawolff|1 year ago
unknown|1 year ago
[deleted]
voytec|1 year ago
> The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
hobo_in_library|1 year ago
SuperNinKenDo|1 year ago
ineedaj0b|1 year ago
hexxington|1 year ago
munchler|1 year ago
kcb|1 year ago
YoshiRulz|1 year ago
klyrs|1 year ago
pjmlp|1 year ago
No wonder Miguel de Icaza is now focused on Swift, Godot and Apple's ecosystem, all the promises done at Xamarin acquisition time are gone now.
Mono Develop killed, after being renamed into VS4Mac, gone through a rewrite, only to be killed shortly after the rewrite reached 1.0.
Xamarin.Forms rewriten into MAUI, with incompatible APIs.
MSIL Linker had a better chance as a critical piece of Blazor WebAssembly and Native AOT.
The whole dotnet reload drama.
Now Mono donation, and then .NET team is surprised .NET uptake on UNIX shops isn't as they expect.
In alternative universe when the Xamarin acquisition didn't happen, where would we be now?
aspeckt112|1 year ago
The license cost was high, and the MS acquisition came right around the time React Native and Flutter started to enter v1. I think they'd of been blown out of the water pretty quickly. At least Microsoft allowed Xamarin to get into enterprise .NET shops pretty quickly. There's a lot of B2B form based apps written in Xamarin. I worked on a pretty big one that made (and continues to make) a lot of money.
I've long assumed the point of the acquisition was because Xamarin did basically all the hard work of allowing .NET to be cross platform.
whalesalad|1 year ago
eddythompson80|1 year ago
randomdata|1 year ago
sswam|1 year ago
[deleted]
0xedd|1 year ago
[deleted]
RobRivera|1 year ago
[deleted]
commercialnix|1 year ago
[deleted]
minkles|1 year ago
Really, point aside, there is no place for zealots and many places for a rational decision analysis in what tools to use. Absolutes and extremism are all bad.
jefurii|1 year ago
If you really like Rust you should promote it by using it to write great tools that inspire others to use it, instead of shitting on people who use other tools to do actual work.
petesergeant|1 year ago
bangaroo|1 year ago
[deleted]
larsrc|1 year ago
RandomThoughts3|1 year ago
Second paragraph of the article by the way, just saying.
RobRivera|1 year ago
pstrateman|1 year ago
Lockal|1 year ago
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
stcroixx|1 year ago
djmips|1 year ago
fluoridation|1 year ago