Microsoft donates the Mono Project to the Wine team

https://www.mono-project.com/

by itherseed • 2 years ago

1436 466 2 years ago

mono-project.com

larsrc• 2 years ago

"Donates"? A code base is a maintenance burden.

pstrateman• 2 years ago

Yeah if this doesn't come with a substantial endowment it's not a donation.

rnd0• 2 years ago

So ...throwing it over the fence into the neighbor's yard, then?

RandomThoughts32• 2 years ago

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.

farhaven• 2 years ago

So Microsoft gave the Wine project the software equivalent of a stained mattress?

RobRivera• 2 years ago

Feel free to donate me a 90s Honda Civic

nerdjon2• 2 years ago

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?

JackSlateur• 2 years ago

Mono was the .net implementation for Linux (and others ?) years ago while microsoft published the windows .net runtime

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.

nicce• 2 years ago

Winehq is probably the only org who might have needs to add something in there. So why not have a control of it, even if the contributions are rare.

Edit: To add, isn’t the above about ASP .NET Core? Mono is mostly about the time before Core, and it is not the same.

filmor• 2 years ago

Mono has support for app domains (and is in general closer to .NET Framework), a more powerful C API and runs on more architectures.

nerdjon2• 2 years ago

So if I am understand correctly, what I mentioned is correct?

On the website (where my quote comes from) it links to https://github.com/dotnet/runtime/tree/main/src/mono which is a mono within what you linked too.

So this is a case of 2 different mono's?

Sorry just trying to make sure I am understanding what is happening here properly given the exact same name in 2 places...

jabl• 2 years ago

I know little of dotnet beyond trying various semirandom things to make some .net apps work on linux. With that out of the way, my understanding is that

- Originally there was .Net Framework, by microsoft, for windows only. Versions 1.0 -> 4.8 were released.

- Then mono came along as a somewhat clean-room reimplementation of .Net framework, focusing on making it run on Linux. Though mono does not implement windows gui widgets, so for that there's stuff like Gtk#. And you cannot run windows GUI applications on mono for this reason, even though the core parts might be portable. Eventually Microsoft acquihired the Mono team.

- Later on Microsoft made the core of .net open source and portable, creating .Net Core. Or .Net Runtime, linked above, which is apparently the same thing (not sure when they dropped the "Core" part of the name). Applications written for .Net Framework can't just be recompiled for .Net Core/Runtime, there is porting work that needs to be done. And similarly as for .Net framework, even though the core is portable and open source, the windows gui libraries are not. So again windows GUI applications written using .Net Runtime cannot run on Linux. Not sure if there exists anything like Gtk# for .Net Runtime, allowing creating native Linux GUI applications with .Net Runtime?

- Finally, we have wine which is an implementation of the Windows API on Linux. And in a wine environment you can install e.g. .Net Framework including GUI libraries, so you can run .Net GUI applications that way.

bri3d• 2 years ago

Mono has no reason to live anymore

This isn't really true. Mono functions as a complete replacement for the ".NET Framework" - something that can be used to run any .NET app, including "legacy" apps targeting old ".NET Framework" versions, on any supported platform, even when the app was built to target Windows.

dotnet/runtime is intended to run more modern applications that target ".NET Core" - basically, stuff that's cross-platform on purpose.

There are tons of subtle differences relating to these goals but also some glaringly obvious ones, like mono having an implementation of Windows.Forms.

hence the lack of commits and contributions

Microsoft have been actively forcing contributors out of mono/mono and into the dotnet/runtime repo for several years now, while Wine kept a weird halfway fork at https://gitlab.winehq.org/wine-mono/mono . Formally transferring `mono/mono` and the Mono name over to Wine will in theory allow `mono` to more effectively accept code which works to improve legacy .NET Framework support for compatibility reasons, while dotnet/runtime can continue to evolve as the way to run intentionally targeted .NET Core code.

Rochus6• 2 years ago

Mono has no reason to live anymore

More targets, much leaner (< 10 MB clr + mscorlib), less than factor two performance difference to current CoreCLR, written in C, easier to compile than CoreCLR, etc.

MarkSweep3• 2 years ago

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:

https://github.com/dotnet/runtime/pull/47955

YoshiRulz5• 2 years ago

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.

donatj• 2 years ago

Is the correct interpretation, reading between the lines that the original Mono project is being retired, and basically put on life support?

Wytwwww• 2 years ago

I think this has already been the case for years? Mono didn't really have much of a point after MS opensource .NET and ported it to other platforms.

rererereferred• 2 years ago

And Wine will probably not do much more than maintenance so applications targeting .net 1-4 work on Wine.

CuriousCosmic• 2 years ago

Somewhat?

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

YoshiRulz5• 2 years ago

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.

rickcarlino• 2 years ago

I feel like I’m missing some context here. Is this a “free as in take this puppy” situation? How do the wine developers benefit from this?

minkles• 2 years ago

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.

jcims• 2 years ago

How has ’free as in puppies’ not reached its rightful place on the podium?

spiderfarmer• 2 years ago

Because nobody wanted to maintain it.

ragebol• 2 years ago

I'm not a dog person: a puppy would be a burden (financially and time-wise) and provide me barely any fun.

bawolff3• 2 years ago

I love this. Definitely using this next time someone tries to guilt me into becoming maintainer of some abandonware foss project.

matthewbauer• 2 years ago

I guess this is in the context of "free as in beer" and "free as in speech".

codersfocus• 2 years ago

White elephant has usually been the go to animal for this kind of idiom

langcss• 2 years ago

Please tell me there is a separate French word for free (as in puppies).

nashashmi• 2 years ago

It should be a “free for adoption” idiom

zerocrates• 2 years ago

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.

dtquad• 2 years ago

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.

Phrodo_00• 2 years ago

Mono also supports winforms. I don't think they're supported in dotnet (but there's libraries for Gtk, although you could also use Vala with a bit extra effort).

neonsunset21• 2 years ago

A shoutout goes to a project that aims to simplify CoreCLR embedding UX to prevent the issues stemming from embedding legacy Mono: https://github.com/StudioCherno/Coral

lloydatkinson3• 2 years ago

Winforms and WPF are both very maintained and supported for .NET 8 on Windows, to clarify. Good cross platform desktop frameworks include Avalonia.

stefanos82• 2 years ago

My assumption is that it must have something to do with https://en.wikipedia.org/wiki/Wine_(software)#Microsoft_appl...

This way will allow them to improve Mono accordingly? Who knows? /me-thinks...

zbowling2• 2 years ago

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.

lolinder2• 2 years ago

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?

older• 2 years ago

This is the official one: https://learn.microsoft.com/en-us/shows/visual-studio-code/g...

Blot2882• 2 years ago

Mono was, but newer versions of .NET run on Linux and Mac.

You can install at the link below, and then making a project is just `dotnet new console` and run with `dotnet run`

https://learn.microsoft.com/en-us/dotnet/core/install/linux

pionar2• 2 years ago

dot.net is the official starting point. It'll point you to getting setup with .NET dev on Linux. You can either use VSCode or Intellij Rider.

SideburnsOfDoom5• 2 years ago

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,

History here https://en.wikipedia.org/wiki/.NET

.NET Core 1.0 (2016) was the first cross platform prototype. It got good in a release in 2018 or 2019, I even forgot which now. And took over steadily after that.

We don't even think about it any more. "which OS is the prod env on" isn't a factor that causes any support worries at all.

Getting set up would start at https://dot.net/

And the download page, which should show you content for your current OS https://dotnet.microsoft.com/en-us/download

But also other targets are here https://dotnet.microsoft.com/en-us/download/dotnet/8.0

You'll want the latest SDK 8.0.x

hsbauauvhabzb• 2 years ago

You’re not alone.

I would say I’m not ‘new’ and even developed .net 4.5 for a number of years. I’m just as stumped by the naming mess that Microsoft made across the board in that space.

Edit: I say 4.5 because I mean the original thick .net which is not dotnet core, which I think is the way to differentiate between versions, but also all the sub libraries like the orm were iirc named the same but did different things.

They should have rebadged everything with a new name that didn’t involve a word that is fairly painful to google (‘core’) can be used in development as well as the name of a framework.

3np2• 2 years ago

As the OP notes, MS use their own fork of Mono for the .NET Core runtime these days. So you're not wrong but they are different codebases these days.

YoshiRulz5• 2 years ago

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?

Not really. It's legacy cruft all the way down.

But the good news is that if you stay on the beaten path, using the latest SDK and targeting the latest Runtime, everything Just WorksTM.

bmitc3• 2 years ago

For modern .NET, you don't need to know anything about the legacy terms of Mono, .NET Core, .NET Framework, .NET Standard, etc. All you need is .NET 8 SDK. It's fully-cross platform and installs support for both C# and F#.

For example, just download .NET 8 SDK on whatever platform, which is usually very easy on most platforms, and then run `dotnet fsi` to get into an F# REPL.

Lutger• 2 years ago

Aside from following the default 'start here' documentation, there are various timelines made for fun and profit that visualize the full history, for example:

https://time.graphics/line/291016

This is quite overwhelming, but it can still be useful when reading an article about .NET that is either older or refers to history as you can quickly see where in time it is located.

kqr• 2 years ago

If you just want to get into .NET (C# or F#) on non-Windows platforms, the latest .NET release (at the time of writing, 8.0) is what you want. The development experience is good these days.

For a historic summary of why it used to be a confusing situation (up until maybe 2020), see https://two-wrongs.com/dotnet-on-non-windows-platforms-brief...

That also has some background on why the Mono project found itself in a weird spot.

neonsunset21• 2 years ago

In many ways, .NET today finally fulfills the original Mono goals, and does so in a very performant manner.

kragen13• 2 years ago

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?

Goz3rr• 2 years ago

Even with AOT compilation, as someone who loves C# and also does embedded development in C I would personally say a garbage collected language like C# has no place there.

mdasen2• 2 years ago

You can add add Microsoft's repo to install it on Debian: https://learn.microsoft.com/en-us/dotnet/core/install/linux-....

Does Debian require packages to work on all of its architectures? If so, that could be the issue. .NET Core only supports x86, x64, and Arm64 (I think Arm32 has been discontinued and RISC-V is experimental at this point).

It's possible that they object to .NET Core having certain license restrictions on the Windows port (https://github.com/dotnet/core/blob/main/license-information...). .NET Core is mostly MIT or Apache licensed, but the Windows SDK has some additional terms. Skimming the third party licenses, that doesn't seem like an issue (mostly MIT/BSD/Apache or similar).

I think the licensing situation is an interesting question: if you have software that's 100% open source when compiled for your OS, but requires non-free stuff to run on Windows, is it ok to include in Debian? It looks like none of the non-free stuff (like WPF) gets distributed with the non-Windows SDK builds. Binaries created from your code only depend on MIT-licensed stuff on macOS and Linux, but might depend on something closed-source when targeting Windows - though it looks like almost all of that stuff is either WPF (so you wouldn't be able to develop on Linux/Mac anyway since those libraries wouldn't be in the SDK on those platforms) or were removed as a runtime dependency in .NET 7. It looks like `Microsoft.DiaSymReader.Native` might be the only thing left. Maybe that's what is holding it back?

also, does dotnet-core have a reasonable aot story for things like esp32 and ch32v003?

"Reasonable" can be a lot of things to a lot of different people. People have been working on RISC-V support. Samsung seems interested in it. But I probably wouldn't recommend it at the moment - and Mono doesn't really have RISC-V support either.

davidhyde• 2 years ago

I believe that you would use dotnet nano for something like that. I used it (or some previous version of it) once many years ago and was very impressed with the productivity and ease of use it offered. Ultimately the lack of community surrounding it drove me to other technologies. Might have changed since then though, who knows!

https://www.nanoframework.net/

MarkSweep3• 2 years ago

.NET Core is available for Debian, you just have to add Microsoft's APT source [1].

Fedora [2], Ubuntu [3], and FreeBSD [4] build .NET from source themselves. A lot of work has been done to make it possible to build .NET from source [5] without closed source components, so it might just be a matter of someone being motivated to create the package for Debian.

[1] https://learn.microsoft.com/en-us/dotnet/core/install/linux-...

[2] https://src.fedoraproject.org/rpms/dotnet8.0

[3] https://launchpad.net/ubuntu/+source/dotnet8

[4] https://github.com/freebsd/freebsd-ports/tree/main/lang/dotn...

[5] https://github.com/dotnet/source-build

johnwheeler• 2 years ago

Trip down memory lane touching several points in my career. Rip /.

guappa• 2 years ago

It's a natural fit.

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?

hacker_88• 2 years ago

Was their Version Control a Monorepo

pipes• 2 years ago

Hi, what does wine use mono for? Is it to support full fat .Net? Interesting post btw, thanks :)

sebazzz• 2 years ago

Mono also had (limited?) support for ASP.NET non-Core. I wonder how many companies actually used that.

adriamaker• 2 years ago

Interesting. Perfect fit for Wine!

dvfjsdhgfv• 2 years ago

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.

munchler3• 2 years ago

.NET now runs on Linux and other platforms, so what is the purpose of maintaining Mono separately at this point?

kcb2• 2 years ago

Mono can run old .NET framework applications directly.

munchler3• 2 years ago

OK, but that doesn't require any further changes to Mono. It should essentially be a read-only project going forward.

YoshiRulz5• 2 years ago

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.

masfuerte2• 2 years ago

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.

tredre3• 2 years ago

.Net Core 1.0 released in 2016 supports Linux yes.

Lagacy .Net never supported OSes other than Windows. Mono, released in 2004, was the first attempt to bring it to other OSes.

saurik• 2 years ago

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.

https://www.mono-project.com/archived/mailpostearlystory/

masfuerte2• 2 years ago

Thank you!

So it ran on Windows, FreeBSD and Mac OS X making it the first non-Windows implementation of .Net, but it didn't run on Linux. It also had a fairly useless licence, so Mono was separate.

https://en.wikipedia.org/wiki/Shared_Source_Common_Language_...

Edited to add: and thanks for the link. Only three developers and there's already drama! :-)

peppertree• 2 years ago

Never miss a good tax write-off.

bawolff3• 2 years ago

I dont think this makes sense. What value would even be written off here?

KeplerBoy• 2 years ago

A value you come up with hoping the IRS will not one day disagree.

cxr• 2 years ago

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.

See <https://simonwillison.net/2024/Jul/13/give-people-something-...>.

romwell2• 2 years ago

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.

repelsteeltje• 2 years ago

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?

Y_Y• 2 years ago

Wine Is Not an Emulator

but it is indeed the basis for Proton

tapoxi• 2 years ago

Via wine-mono

Games themselves typically aren't .NET but ancillary components, like launchers or map editors, are.

justsomehnguy2• 2 years ago

You are probably mix up .NET and C# somewhat.

troymc• 2 years ago

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

qingcharles5• 2 years ago

Thank you, that explains the Mono in SL.

toastercup• 2 years ago

It does indeed still work that way! We even still support the old, in-house VM, known as LSO2: https://wiki.secondlife.com/wiki/LSO

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

officeplant• 2 years ago

Always nice to see that SL is still going. I'll probably never remember my login to my old 2006 era account but the years of weird virtual world memories remain.

PinkMilkshake• 2 years ago

Cool! LSL is such an interesting language. Having an explicit state with entry and exit functions is quite unique I think, and seems like it could be useful outside of SL. Given that scripts are isolated and communicate via messaging over channels (IIRC), was there ever any interest in executing it on the BEAM virtual machine?

neonsunset21• 2 years ago

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.

Rochus6• 2 years ago

due to a massive rift in performance between the two

Not that massive; factor 1.8 as we found out recently.

neonsunset21• 2 years ago

This is not an accurate assessment, I'm afraid.

The comparison we discussed was for unrepresentative code that used none of the features that make .NET fast (generics, SIMD, expected forms of inheritance and abstraction and devirtualization they enable, CoreLib APIs). The closest case in there was JSON serialization which CoreCLR was 385% faster at. It is unfortunate that you feel a need to say this, knowing that it doesn't even show a tip of the iceberg.

Please do not mislead casual readers here with such comments.

They will have a bad time running basic programs - the original Mono is outdated and cannot execute assemblies that target non-legacy versions, and the Mono that lives in dotnet/runtime (which you have to go out of your way to use on CoreCLR platforms) tends to have all kinds of regressions on user-provided code that is not as robust on runtime checks to ensure that Mono does not accidentally go onto the path that that it has especially bad regression on. Even CoreLib code nowadays uses more and more struct generics assuming monomorhpization which performs poorly on Mono. There is very little work done to improve performance on Mono with effort invested mostly in WASM area and to ensure it does not regress further. Major platforms like Android and iOS are in the slow but steady progress to migrate to CoreCLR/NativeAOT (there are other reasons not in the least much smaller binary size). And for WASM there is NativeAOT-LLVM experiment that is likely to make Mono obsolete for that target too.

The workloads that matter and are representative are the ones produced by C#, F# and VB.NET compilers as well as projects that care about exercising the standard library and/or produce recommended CIL forms (like https://github.com/FractalFir/rustc_codegen_clr).

Rochus6• 2 years ago

If we compare the last major release of Mono back in 2019, where there was a real improvement to the CLR (not just bug and security fixes), with the CoreCLR versions at that time, the factor is rather 1.1 (see e.g. https://www.quora.com/Is-the-Mono-CLR-really-slower-than-Cor...).

__s• 2 years ago

https://wiki.winehq.org/Mono#Microsoft_.NET for why Mono is relevant to Wine

nequo2• 2 years ago

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.

high_5• 2 years ago

Wine is becoming like archive.org, but for win32 runtimes.

whalesalad• 2 years ago

What is the mono logo? a gorilla with a hat? or a pile of poop? serious question.

randomdata2• 2 years ago

A portrayal of someone's attempt at giving a "thumbs up" with a broken thumb, obviously.

eddythompson80• 2 years ago

It's a Monkey's head. Mono is Monkey in Spanish. The original author, Miguel de Icaza, is Mexican-American.

rgovostes• 2 years ago

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.

jimrandomh• 2 years ago

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.

rescbr• 2 years ago

Microsoft’s EULA would still apply to (b).

It’s the exact same situation as downloading a Windows ISO from Microsoft’s website and running it with an activator.

kelnos4• 2 years ago

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.

kragen13• 2 years ago

anthropomorphizing complex social institutions such as corporations is ultimately unproductive and a net negative for clear thinking

bonesss• 2 years ago

I think it's just such a clear business-razor because of the cloud: can I take my app and spin up a bajillion cheapo servers with no licensing costs using that stack?

If the answer for .Net was 'no' then there are meaningful domains where people would just jump ship in a second. Research, academia, teaching, and certain government areas pop to mind. Keeping Linux support, because of that server dominance, is a core concern for them.

deelowe2• 2 years ago

Microsoft as a company is extremely myopic. Budgets are scrutinized down to the penny every few months at very senior levels. This drives a culture of immediacy. Wine was a threat until Microsoft realized everyone in tech had moved to service based business models (aka "cloud"). Only afterwards, did they "realize" Linux as a threat to their long term viability no longer mattered.

shopvaccer• 2 years ago

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.

I'm not sure if it benefits microsoft in the long term, because the "backwards compatibility" features of Wine need to be implemented in Windows already as a part of the system. So in the long run wine/proton/mono will implement windows features on linux in an optional/replaceable/modular way in user-space while keeping backwards compatibility for older windows software, while windows is forced to implement (and distribute these features) with their OS and has to sacrifice backwards compatibility if they want to simply their OS.

I would say that the adoption of wine/proton helps the linux ecosystem a lot more because there wasn't a standard executable format for linux beforehand (static? tarball of program and dynamic libraries? .deb file? AppImage? Flatpak? Higher-level language like java?). How do you reliably link to libraries like mesa or even glibc? Now there is a solution: just distribute a windows program and test it to confirm it works in wine/proton. Perhaps it is better for DirectX adoption, but it seems like Vulkan/OpenGL/WebGPU are still superior in terms of cross-compatibility, regardless if you use wine or not.

mark3362• 2 years ago

If MS was smart, they would try to get the devs working on Xbox projects to use their coding platforms for other type of development.

RadiozRadioz• 2 years ago

Wine/Proton helps make the Win32 and DirectX APIs a sort of de-facto cross-platform standar

There are perfectly fine _actual_ cross-platform standards like Vulcan and OpenGL. If your goal is cross-platform, making a Windows app that you hope will be converted well enough is a strange way to approach it.

BurnGpuBurn• 2 years ago

I disagree. MS was completely succesfull in their goals. They kept a ton of developers busy learing useless Xamarin, thus keeping them from developing products that can actually compete with Microsoft products.

Next they killed of an open source competitor (Mono) of their product, stole the usefull bits to put it in .Net, and now they dump the leftover project (that's not competing with them anymore) back into the OS world.

How is that not a smart way of doing business?

berkes• 2 years ago

I still don't trust MS's motives in general

I think it's the same for any global enterprise: profit.

In that regard, "trusting" something like MS is like evaluating their stock: what do they make money off, what is a threat to that. Which makes it rather easy to "trust" them: if they can make money off SomeOpenSourceProject they'll help it along, if it doesn't help, nor threat, they'll ignore it. If it's a threat, they'll put (some) money towards fighting it.

For me the difficult part, and why I still don't fully trust MS, even with Github or VScode lies in their internal competition: MS has projects that directly compete eachother. Business-wise it makes no sense to me (and is the primary reason I'll stay away from investing in MSFT). But also their internal competion between profit now and delayed profit. MS has often done things (or not done things) that increase the bottom line this quarter, but harm them over years. In that regard too, MS makes no sense to me Business-wise. I guess having a cash-cow-"monopoly" for decades kinda absolves them of the responsibility to run the entire company in a way that makes sense business-wise.

Brian_K_White2• 2 years ago

Maybe they feel the same about Wine as I do about WSL.

You can argue that the my-thing-wrapped-inside-your-thing increases exposure to my-thing and that's a net good outweighing any other factors, but you can just as validly argue it helps divert from actual adoption of my-thing and facilitates never moving from your-thing, since no one has any actual empirical study, it's all just feelings and beliefs.

Maybe one logical argument that might have some meat is maybe WSL/Wine just means that the exposure vs crutch aspects cancel each other out (for every user who is exposed to foreign-thing and maybe decides to adopt it, there is another user who thanks to the swallowed version does not ever have to to move), and if that's true, then any imbalance in effects comes down to the the innate virtues of the two things. Both groups of people are equally exposed to both platforms and have equally good-enough use of both platforms, and neither has to actually change to get the benefits of the other, and so the user will choose whichever actually seems to serve their needs the best as their native platform.

I wonder if it's possible to make a desktop backed by WSL that would be a better experience than the current ad/spying-riddled Windows native desktop? Then MS would be forced to try to enshittify WSL so that it doesn't provide an escape and superior experience from the current Windows experience. Is WSL a good thing THEN?

At least for now, WSL has absolute crap access to hardware, not even just like gpus for gaming but even simple things like access to a usb-serial adapter. So, it's probably not possible to make a functional WSL desktop yet. Maybe such things will intentionally never be fixed in WSL just for this reason, so you can only ever use it for pure web app development no different from a cloud instance.

qingcharles5• 2 years ago

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.

sublimefire• 2 years ago

Few work on Macbooks, it is more about using WSL on the dev machines or even using DevBox instances.

gnu8• 2 years ago

I imagine very few of the MS devs are using BeOS.

stackskipton6• 2 years ago

.Net SRE here, all our .Net REST APIs are deployed on Kubernetes. Devs are still mostly on Windows because Visual Studio.

I've worked with Azure team, all greenfield they do for Azure goes on Linux as well. Windows Server is pretty much dead to Microsoft though it will be continue to be supported and released because $$$.

junto• 2 years ago

Our .NET teams are increasingly choosing MacBooks with Jetbrains Rider.

Aachen• 2 years ago

I'm sure the vast majority of individuals, especially those doing the technical work, are normal people wanting good things and pushing to do good work. It's the organisation as a whole that turns into a different beast making business decisions

alerighi• 2 years ago

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

ijidak• 2 years ago

So, would these provisions protect a reverse engineering of CUDA?

It's hazy to me when reverse engineering of APIs is and isn't allowed.

tambourine_man4• 2 years ago

You are not alone. It’s not a well defined problem, hence lawsuits. API is also such a broad term, it’s hard to establish borders.

hinkley2• 2 years ago

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.

internetter• 2 years ago

What tool is that?

varispeed• 2 years ago

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.

Brian_K_White2• 2 years ago

Life hack! Freeze your Windows from further unwanted updates by just fabricating some wine registry entries!

pentagrama• 2 years ago

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'?

kelnos4• 2 years ago

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

datavirtue• 2 years ago

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.

justsomehnguy2• 2 years ago

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.

voytec• 2 years ago

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.

Lockal• 2 years ago

Yes, some things never change:

https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

DrNosferatu2• 2 years ago

They could also donate comparability with modern MsOffice.

DrNosferatu2• 2 years ago

*compatibility :D

philip1209• 2 years ago

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)

IshKebab2• 2 years ago

At best you would be limited to the value lost which is essentially zero, so no.

nedt2• 2 years ago

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.

fluoridation2• 2 years ago

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?

nedt2• 2 years ago

So it was a PowerPC, not so much Software was optimized. Then it was a new language written to be used on Windows. And that was run via Mono, which was a 3rd party actually writing it for Linux and not a BSD derivative on a CPU that no one is using with a kernel that's different. It might not have been that horrible, but it was just a quick presentation. Nothing that should even run for a minute.

Havoc• 2 years ago

How is .Net/Mono connected to Wine?

Or is this more of a steward role rather than technical connection

pjmlp6• 2 years ago

Yet another piece of Xamarin/Mono that falls down.

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?

aspeckt1125• 2 years ago

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.

pjmlp6• 2 years ago

Ever heard of Rotor?

https://www.codeguru.com/dotnet/net-nuts-bolts-the-joy-of-ro...

Or DotGNU?

https://www.gnu.org/software/dotgnu/

What happened to Xamarin looks like Microsoft took whatever IP was relevant, and left everything else go, which this decision is a confirmation thereof.

It is kind of interesting to see Miguel's feedback, now that he his allowed to talk about how things went down.

pdmccormick• 2 years ago

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.

BeetleB• 2 years ago

You may want to look at F#. Because it's .NET you have a large list of libraries you can use

zakki2• 2 years ago

For a beginner, high school but zero experience in programming, which one easier to learn, C# or F#?

dmw_ng• 2 years ago

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.

dwoldrich• 2 years ago

Do your civic duty and disable telemetry everywhere you go. :)

export DOTNET_CLI_TELEMETRY_OPTOUT=1

starik362• 2 years ago

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

lostmsu3• 2 years ago

C# is IMHO still better language than Go.

Refactoring tooling is unmatched.

xandrius• 2 years ago

If with C# you can create a fully static binary which runs on an empty scratch docker, I will properly consider your opinion. Until then: Go à gogo!

misiek08• 2 years ago

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

hakanderyal2• 2 years ago

It’s great for web application backends. Switched to it after 10+ years of Python. Couldn’t be happier.

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.

MStrehovsky• 2 years ago

Is AOT compiling your binaries [1] an option for you? The starting size of AOT compiled C# can beat Go in size [2] and from there it really depends on what you do and how you do it. Some simple ASP.NET server with https and routing can comfortably fit under 10 MB and there are compilation options that can help optimize further [3].

[1] https://learn.microsoft.com/dotnet/core/deploying/native-aot... [2] https://github.com/MichalStrehovsky/sizegame?tab=readme-ov-f... [3] https://learn.microsoft.com/dotnet/core/deploying/native-aot...

pjc504• 2 years ago

The feature I always suggest as uniquely C# flavoured is LINQ.

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

TheCapeGreek• 2 years ago

I last touched LINQ in college in 2016 - isn't it basically an ORM for C#? Not super unique but I assume very relevant to use when working with C#.

gwbas1c• 2 years ago

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

klyrs• 2 years ago

"Free as in beer" just became "free as in pony?"

whyenot• 2 years ago

What is Miguel de Icaza up to these days? I saw on Wikipedia that he left MS in 2022 to take some time off, but surely he's working on something now?

(if you respond, please, lets not get into his politics; HN is not the right place to have that kind of discussion)

zbowling2• 2 years ago

He is making terminal emulators for iOS, iPadOS, and VisionOS and loving Swift these days.

hnarayanan• 2 years ago

And Godot!

aussieguy12343• 2 years ago

This makes me curious. Could MS secretly be using wine for some of their Azure services?

Kwpolska6• 2 years ago

Why would they use Wine when they have free and unlimited access to the real deal?

aussieguy12343• 2 years ago

Well, let's say they wanted to use Linux, but run their windows software on it.

ineedaj0b2• 2 years ago

i think this is related to Xbox soon launching a handheld gaming device like the switch/steam deck. anything that directly refutes this hunch?

hexxington2• 2 years ago

Me. I directly refute this hunch. Nothing to do with xbox ever entered the discussion.

ineedaj0b2• 2 years ago

thanks!

I kept thinking Microsoft needs to port a windows version for their handheld, doesn't want to use steamos, but also needs to work with 'interesting' hardware. Their answer would be a linux port imo, but having too much there could annoy trust regulators so they divested from mono. but I had zero proof for any of these hunches.

methods21• 2 years ago

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

bootloop• 2 years ago

Mostly because business apps have to appear similar to the platform UI. Games do not, they have to look the same regardless of the platform in use.

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_• 2 years ago

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.

hilux• 2 years ago

We are happy to announce that the WineHQ organization will be taking over as the stewards of the Mono Project

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?

signa11• 2 years ago

reminds me of classic mitch-hedberg quip “here, you throw this away”, when some hands you a flyer on the street.

torginus• 2 years ago

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.

YoshiRulz5• 2 years ago

The .NET Core Runtime works great on Linux, but it can't run .NET Framework apps, hence wine-mono.

alberth• 2 years ago

Does this allow Microsoft to have a $400M tax write-off?

https://www.bloomberg.com/news/articles/2016-02-25/microsoft...

pyeri• 2 years ago

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.

WaitWaitWha• 2 years ago

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.

hobo_in_library• 2 years ago

I wonder what kind of a tax write off this can turn into

stcroixx• 2 years ago

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.

djmips• 2 years ago

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.

fluoridation2• 2 years ago

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.

SuperNinKenDo• 2 years ago

That's a funny way to spell "fobs off".

purplezooey• 2 years ago

This seems to happen a lot. The thing gets acquired, makes somebody rich, then is completely written off on the balance sheet 5 years later.

alchemio• 2 years ago

Embrace, Extend, Extinguish, Endow

Microsoft donates the Mono Project to the Wine team

Related Stories