“We’ve finished taking all we need from the Mono project and implemented it into our proprietary .NET implementation for Linux, Android and iOS. Instead of getting flack for killing off Mono (which is open source and would’ve been forked anyways) we graciously give this old husk to the Wine project. We recommend that active Mono users and maintainers of Mono-based app frameworks migrate to .NET. kthnxbye!”
Good thing that it went to Wine I guess, as they do lots of work to get old Windows programs up and running in Linux and that often involves Mono.
Thats bad paraphrasing. .net is not propiatary and is open source and cross platform now because it started from scratch even before they bought xamarin (.net core). Yes mono did help .net become cross platform, no denying that, but they were already making steps to make that possible. They had to for the cloud/azure.
On top of that, for future development mono is no longer needed because .net is cross platform, and as an example ive made desktop apps on linux using avalonia which work on mac, windows, linux, …
Mono’s purpose at this point is only legacy stuff ( aka .net framework projects, aka stuff made with .net 4.8 or lower ) and will not evolve, which is perfect for wine.
I know it looks like microsoft took what they needed and are now ditching it, and its not untrue, but its always better to have something officially supported by the source instead of some 3th party as it will now evolve on all platforms at the same time and not stay behind the facts. It also will have better performance too since there is less translation going on.
Dont be salty about this man. Be salty about maui and how it took xamarin and crippled it ( no linux support )
Assuming that they will do EEE here once more, can the community fork the latest version of. Net and do with it whatever they want, including maintaining cross platform support if MS decides to abandon that part?
The mit license allows forking, merging, modifying and releases of modified code. Yes id assume so yes :)
I have a lot of bad things to say about some microsoft teams and some microsoft managers (cough fluentui webcomponents team cough ), but in general the .net team is a nice one and ive had several nice encounters with few of its devs.
Just dont know what the actual bloody fuck the manager/team was thinking dropping linux when they made maui…
What I would really like to know is the thought process behind using the oldest dependency version in a version range in .NET instead of the newest like literally every other package or dependency manager ever made. That design couldn’t be worse if it was designed to maximize security holes.
If you specify that e.g. a dependency should be between version >= 4.0 and < 4.1 in dotnet and there are versions 4.0.0 and 4.0.1 available pretty much all other systems choose 4.0.1 based on the idea that that will include a fix while dotnet chooses 4.0.0 based on the idea that that is “more stable”.
Ah, thats fair. I think thats fixable using wildcards in the packagereference in the csproj, but id need to check. I too would expect it to choose 4.0.1 unless a patch release needs a big update or something
“We’ve finished taking all we need from the Mono project and implemented it into our
proprietary.NET implementation for Linux, Android and iOS. Instead of getting flack for killing off Mono (which is open source and would’ve been forked anyways) we graciously give this old husk to the Wine project. We recommend that active Mono users and maintainers of Mono-based app frameworks migrate to .NET. kthnxbye!”Good thing that it went to Wine I guess, as they do lots of work to get old Windows programs up and running in Linux and that often involves Mono.
Thats bad paraphrasing. .net is not propiatary and is open source and cross platform now because it started from scratch even before they bought xamarin (.net core). Yes mono did help .net become cross platform, no denying that, but they were already making steps to make that possible. They had to for the cloud/azure.
On top of that, for future development mono is no longer needed because .net is cross platform, and as an example ive made desktop apps on linux using avalonia which work on mac, windows, linux, …
Mono’s purpose at this point is only legacy stuff ( aka .net framework projects, aka stuff made with .net 4.8 or lower ) and will not evolve, which is perfect for wine.
I know it looks like microsoft took what they needed and are now ditching it, and its not untrue, but its always better to have something officially supported by the source instead of some 3th party as it will now evolve on all platforms at the same time and not stay behind the facts. It also will have better performance too since there is less translation going on.
Dont be salty about this man. Be salty about maui and how it took xamarin and crippled it ( no linux support )
I stand corrected, .NET Core is open source and uses the MIT License.
Assuming that they will do EEE here once more, can the community fork the latest version of. Net and do with it whatever they want, including maintaining cross platform support if MS decides to abandon that part?
The mit license allows forking, merging, modifying and releases of modified code. Yes id assume so yes :)
I have a lot of bad things to say about some microsoft teams and some microsoft managers (cough fluentui webcomponents team cough ), but in general the .net team is a nice one and ive had several nice encounters with few of its devs.
Just dont know what the actual bloody fuck the manager/team was thinking dropping linux when they made maui…
What I would really like to know is the thought process behind using the oldest dependency version in a version range in .NET instead of the newest like literally every other package or dependency manager ever made. That design couldn’t be worse if it was designed to maximize security holes.
Care to elaborate? I dont fully follow ^^; Feel free to also dm me or something
If you specify that e.g. a dependency should be between version >= 4.0 and < 4.1 in dotnet and there are versions 4.0.0 and 4.0.1 available pretty much all other systems choose 4.0.1 based on the idea that that will include a fix while dotnet chooses 4.0.0 based on the idea that that is “more stable”.
Ah, thats fair. I think thats fixable using wildcards in the packagereference in the csproj, but id need to check. I too would expect it to choose 4.0.1 unless a patch release needs a big update or something