• @anamethatisnt@lemmy.world
    link
    fedilink
    English
    20
    edit-2
    4 months ago

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

    • DacoTaco
      link
      fedilink
      English
      23
      edit-2
      4 months ago

      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 )

      • @trolololol@lemmy.world
        link
        fedilink
        English
        14 months ago

        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?

        • DacoTaco
          link
          fedilink
          English
          1
          edit-2
          4 months ago

          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…

          • @taladar@sh.itjust.works
            link
            fedilink
            English
            14 months ago

            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.

            • DacoTaco
              link
              fedilink
              English
              14 months ago

              Care to elaborate? I dont fully follow ^^; Feel free to also dm me or something

              • @taladar@sh.itjust.works
                link
                fedilink
                English
                14 months ago

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

                • DacoTaco
                  link
                  fedilink
                  English
                  14 months ago

                  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