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 good documentation somewhere for getting set up to develop with modern .NET on Linux?

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.

$ apt search dotnet

p dotnet-apphost-pack-6.0 - Internal - targeting pack for Microsoft.NET p dotnet-apphost-pack-7.0 - Internal - targeting pack for Microsoft.NET p dotnet-apphost-pack-8.0 - Internal - targeting pack for Microsoft.NET p dotnet-host - dotNET host command line p dotnet-host-7.0 - dotNET host command line p dotnet-host-8.0 - .NET host command line p dotnet-hostfxr-6.0 - dotNET host resolver p dotnet-hostfxr-7.0 - dotNET host resolver p dotnet-hostfxr-8.0 - .NET host resolver p dotnet-runtime-6.0 - dotNET runtime p dotnet-runtime-7.0 - dotNET runtime p dotnet-runtime-8.0 - .NET runtime p dotnet-runtime-dbg-8.0 - .NET Runtime debug symbols. p dotnet-sdk-6.0 - dotNET 6.0 Software Development Kit p dotnet-sdk-6.0-source-built-arti - Internal package for building dotNet 6.0 So p dotnet-sdk-7.0 - dotNET 7.0 Software Development Kit p dotnet-sdk-7.0-source-built-arti - Internal package for building dotNet 7.0 So p dotnet-sdk-8.0 - .NET 8.0 Software Development Kit p dotnet-sdk-8.0-source-built-arti - Internal package for building the .NET 8.0 p dotnet-sdk-dbg-8.0 - .NET SDK debug symbols. p dotnet-targeting-pack-6.0 - Internal - targeting pack for Microsoft.NET p dotnet-targeting-pack-7.0 - Internal - targeting pack for Microsoft.NET p dotnet-targeting-pack-8.0 - Internal - targeting pack for Microsoft.NET p dotnet-templates-6.0 - dotNET 6.0 templates p dotnet-templates-7.0 - dotNET 7.0 templates p dotnet-templates-8.0 - .NET 8.0 templates p dotnet6 - dotNET CLI tools and runtime p dotnet7 - dotNET CLI tools and runtime p dotnet8 - .NET CLI tools and runtime p libgtk-dotnet3.0-cil - GTK.NET library p libgtk-dotnet3.0-cil-dev - GTK.NET library - development files

To a point. Making cross platform native desktop apps is still in the hands of 3rd party vendors such as Avalonia and Uno. MAUI was supposed to fix that oversight to a less than stellar results.

That's what you have to compare against, and .NET/C# falls flat.

Er, I don't think this assertion is backed by data. See for example https://pypl.github.io/PYPL.html

Is Kotlin the most "active", "hot", or "up-and-coming" competitor? Possibly. But the "largest"? Its deployed footprint and popularity are nowhere close to Java's at this point in time.

C# and F# get to enjoy the integration that is "much closer to the metal" as well as much richer cross-platform GUI frameworks ecosystem with longer history.

Win32? Silverlight/Blend? XAML? MAUI? They're all windows only.

Gtk? Qt? Sure, they exist, but they're ancient and limited to long outdated paradigms.

I don't know if you can get QtQuick with KDE Kirigami to work on .NET, otherwise that might be one option.

Kotlin Multiplatform is btw a solution for building the same code for kotlin native, JVM and web to target all the OSes at the same time.

While Jetpack Compose is the Android Version of Compose, Compose Multiplatform is Compose for Kotlin Multiplatform.

> subject to the quirks and specifics of JVM implementations, build-systems and package management

That's a massive advantage over the arcane package management and build systems of .NET

Very few languages ever achieve a build and package management system as mature and usable as the Java ecosystem.

I've been waiting for 12 years for .NET to match Java's ecosystem, and it's still not there yet.

So this "it's all for backend now" notion is surprising.

For reference for those unfamiliar with the terms:

.NET Core was the name given to the cross-platform fork of the .NET runtime.

It was forked out of .NET 4.x and dropped support for a lot of things in the first versions.

It ran on various distributions of Linux and MacOS.

At the same time there were forks of other libraries/frameworks in the .NET ecosystem to have 'Core' variants. Often these were dropping support for legacy parts of their code so that they could run on Core.

Later versions of .NET Core brought over support for a many of the things that had been dropped.

.NET Core and .NET had stand-alone versions until .NET Core was renamed to . NET and became .NET 5.

So, if you want to do the most modern cross-platform C# you would use .NET 9.

It is "Core" in a lineage sense, but there's no need to make that distinction any more. The term "Core" is out of date, because the experimental "Core" fork succeeded, and became the mainstream.

For what I do, it's not really "Windows development" in any meaningful way. It is business functionality with HTTP, message queues etc, developed on mostly Windows laptops, and deployed to mostly Linux instances on the cloud. Not that the host OS is something that we have to think about often.

For this, .NET 3.x "the full framework windows only version" services are regarded as very much legacy, and I wouldn't go near one without a plan to migrate to a modern .NET version.

However, YMMV and people are also making windows desktop apps and everything else.

They've now abandoned that strategy, and instead they use it as a way to maintain lock-in at the IAAS/PAAS level (Azure).

> It was forked out of .NET 4.x and dropped support for a lot of things in the first versions.

I love .NET. It’s a great stack, especially for backend web apps. Blazor is a great SPA framework too. But I loathe how Microsoft continue to handle just about everything that isn’t the framework and C# / F#. It’s laughable.

.NET Standard includes various versions of things that MS doesn't even touch.

I stopped doing .NET stuff before .NET 5 so I'm not hugely up to date with the latest shenanigans.

It’s just funny for newcomers to peel back the onion more. Writing a source generator? Target .NET standard 2.0 (not even 2.1) for a whole host of reasons.

But for the last 20-ish years it's really only been applied to things related to the .NET Framework.

So, yes - Visual Basic.NET is a language - it's the language that replaced Visual Basic 6. It compiles to the Intermediate Language (IL) that the Common Language Runtime (CLR) executes. There are other languages that compile to IL, too like C#, F#.

The .NET Framework is really a bunch of libraries and tools that are packaged together.

The .NET Standard is a standard that allows you to build a library to a known set of supported libraries and IL / CLR features.

So, yes, depending on which specific part you're referring to - it's all of those.

A factoid that's shared sometimes (no idea if true) is that Microsoft now employs more Linux kernel engineers than Windows kernel engineers due to Azure.

Bona fides: I have used GCP for 3 years, AWS for 3 years, and Azure for ~ 1 year. As well as the more "bare-metal" types of cloud providers like Linode/Akamai, and Vultr -- all the latter of which are great for self managing your infra.

I also really find the ability to spin up Windows Server and Windows 10/11 etc super useful for builds, testing, Hyper-V.

I really like Azure for huge projects with many moving parts.

The Microsoft of the Halloween Documents[0] is a different Microsoft from the one we see today that understands open source as something good rather than as a threat, and it started with Microsoft being forced to play nice.

"The cloud" as we understand it didn't exist yet.

[0] https://en.wikipedia.org/wiki/Halloween_documents

Strange times.

The UI isn't native, is a Skia canvass with drawn controls. But it'll work on basically every OS and it's pretty good.

Also, you're not writing JavaScript, so that's a win any day in my book.

It is like the Web folks, that don't get anything else, are now pushing where .NET goes, mostly since .NET is now under Azure org chart.

I have done Web and native since "forever", not everything has to be for everything.

There's the first party MAUI which is an updated version of Xamarin Forms. The two best-known third-party implementations are AvaloniaUI and Uno. I prefer Uno, it has more cross-platform targets.

It's (of course) not portable

My point is about running existing applications on Linux, there are still issues with running .Net GUI stuff under wine and Mono was not a perfect implementation.

I read in other comments that the newer .Net cross platform stuff is not a replacement for Mono for running this old applications. (nobody will rewrite them to use the current GUI stuff from MS since are old apps)

Works better in proton from my experience though, but I think that is due to making unity games run better

Sadly some Java tools stopped working if you run latest Java runtime because for some reason some crap was removed from Java and nobody made some easy way to add them back with soem package install.

If I was building a cross platform native app with .NET I'd probably use Avalonia right now.

I think not supporting Linux was a tactical error, though. Some people will put up with a lot for Linux GUI support, and some of those people are the types who can resolve problems with your half-baked GUzi framework.

Sure, Microsoft could pay more employees to work on it faster, but Linux loves and prefers open source from Linux devs "untainted by Microsoft", right?

Were I live and work (IT and consulting in central south-east Norway) it has been the year of the Linux Desktop on and off since 2009.

That was the first time I worked full time at a place that deployed Linux for everyone and everything that didn't have a verified reason for needing Windows.

I think we had one 3rd party trading software running on a Windows machine and maybe the CEO and someone in accounting got Windows.

Everyone else was upgraded to Linux and it worked beatifully. It was my job to support the sales department with desktop related issues and it was absolutely no problem to do it while also being a productive developer.

Since then I have not worked on a place that required Linux, but I think most of the places I have worked on since has had Linux as an option as long as you supported it yourself, and some places also have been very active writing how-tos and working with me to troubleshoot issues that were related to Linux, since many of them were also Linux users.

At the moment I use Mac, but at my current job I'm also allowed to use Linux.

Alternatively, just because you're on .NET doesn't mean you need to use Microsoft sanctioned UI toolkits, just as C++ has no "official" UI toolkit. You're free to pick up some GTK or Qt bindings if you want a native feeling and your application is already architectures correctly. Alternatively, throw Imgui at it if you just need dev tooling, or maybe try other cross platform toolkits in the ecosystem like Avalonia or Uno

Also very easy to throw something together on top of SDL2 with Silk.NET.

Practically speaking it is in a much better place than many languages considered by parts of Linux community to be more """linux-oriented""".

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.

So let's say you google how to do something and the result could be:

  - .NET Framework
  - .NET core 1
  - .NET core 2
  - .NET core 2.1
  - .NET core 3
  - .NET 5+

On stackoverflow, answers sometimes include all versions varieties.

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.

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.

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?

I think telemetry collection alone should be a good reason for Debian to consider repackaging it. I don’t want telemetry to be collected on my GNU/Linux machine, thanks Microsoft, but you already have so much telemetry from my Windows machine, please leave my other machines alone.

as for building from source, i see, thanks! or maybe it's unresolved legal concerns? nobody so far in this thread has known of any, though

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.

debian doesn't require packages to work on all of its architectures. luajit, for example, has not been ported to riscv64, mips64el, or ppc64el https://packages.debian.org/sid/luajit, though lua5.1 is https://packages.debian.org/sid/lua5.1. what the debian policy manual says about architecture-specific packages seems to be https://www.debian.org/doc/debian-policy/ch-controlfields.ht...:

> Specifying a specific list of architectures indicates that the source will build an architecture-dependent package only on architectures included in the list. Specifying a list of architecture wildcards indicates that the source will build an architecture-dependent package on only those architectures that match any of the specified architecture wildcards. Specifying a list of architectures or architecture wildcards other than any is for the minority of cases where a program is not portable or is not useful on some architectures. Where possible, the program should be made portable instead.

i don't think the license you link to would be a problem in itself, because it only applies to certain files which are not useful for running dotnet-core on debian anyway. debian has lots of packages from which non-free-software files have been removed. i don't know anything about diasymreader?

with respect to esp32 and ch32v003, what i meant to point to was not the risc-v architecture (some esp32s are tensilica!) but the limited memory space; jit compilation is not a good fit for 2 kibibytes of ram or even 520 kilobytes of ram

and, correct me if i'm wrong here, but doesn't c# allow you to statically allocate structs just as much as c does? i'd think you'd be able to avoid garbage collection about as much as you want, but i've never written much beyond 'hello, world' in c#

Otherwise, statics are placed in a static values array "rooted" by a respective assembly. I believe each value will be contained by a respective box if it's not an object. This will be usually located in Gen2 GC heap. My memory is a bit hazy on this specific part.

There is no concept of globals in .NET the way you describe it - you simply access static properties and fields.

In practice, you will not be running .NET on microcontrollers with existing mainline runtime flavours - very different tradeoffs, much like no-std in Rust. As mentioned, there is NanoFramework. Another one is Meadow: https://www.wildernesslabs.co which my friend is using for an automated lab for his PhD thesis.

Last mention goes to https://github.com/bflattened/bflat which supports a few interesting targets like UEFI. From the same author there's an example of completely runtime-less C# as well: https://github.com/MichalStrehovsky/zerosharp. It remains a usable language because C# has a large subset of C and features for manual memory management so writing code that completely bypasses allocations is very doable, unlike with other GC-based alternatives.

https://www.nanoframework.net/

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?

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

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?

What kind of moustache-twirly stupidity is this? Yeah, Microsoft maintained a shitty cross-platform SDK so that developers would make worse software, because that's somehow helping any of their main product verticals. By the way, those are (broadly speaking) cloud, client software, and games.

Do you have any evidence to suggest that there was a Xamarin-based application that would have directly competed with Office? How about Fallout? Now, do you have any evidence that Microsoft tried to make Xamarin worse at doing the thing that application was trying to do?

> Next they killed of an open source competitor (Mono) of their product

Microsoft's implementation is also open source, and has been for almost a decade: https://github.com/dotnet/runtime

> that's not competing with them anymore

Sure. Mono is only useful for legacy purposes. Microsoft's own design was always the reference implementation of .NET, regardless of whether it was open-source. Mono existed for the sole purpose of being an open, cross-platform reimplementation. Now that the reference design is itself open-source and cross-platform, Mono is mostly redundant.

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.

By this logic there wasn't a standard executable format for Windows, either (static? zip archive of program and dynamic libraries? .msi file? installer program? UWP? higher-level language like C#?).

Sometimes running old software atop Wine on Windows is the easiest - or even only - option to have said old software work on new Windows.

Dumping endless piles of cash into projects nobody cares about and pretending like you're the dominant player when you control some dwindling 2% of the market is stupid and more companies should learn that lesson

Remember when Microsoft was able to fight off the Web with piss-poor Internet Explorer? Until it didn't.

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.

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.

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.

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.

Windows goes back and beyond for compatibility with existing compiled software and Wine inherits that, is partially why Windows versions under Wine often have a higher chance of running than the native versions (ARK is a great example)

Projects like Flatpak attempt to solve this by the use of runtimes.

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

In the end we decided to just let the management think what they want. I've been more of a Unix person for 40 years but I kind of miss the "good" versions of Microsoft Server - in the 1990s / early 2000s it was a real contender. If they hadn't doubled down on weird things like Powershell it might still be a contender.

Sure, it's got some unique characteristic that more traditional shell users dislike but that's just a matter of taste.

Someone wrote some automation code that handles json payloads using powershell. When we tried to migrate to azure functions which uses 7.x by default things broke because users never cared to check sensitivity of key names.

It’s also slow even for interpreted language standards.

I’ll seriously never use powershell for anything serious ever again even though I admit syntax and design feels kinda nice.

It's just best to think about Powershell 5.1 and Powershell Core 7.x like Py2 -> Py3. Most of code works as is, some doesn't, and you should use latest when you can.

>Someone wrote some automation code that handles json payloads using powershell. When we tried to migrate to azure functions which uses 7.x by default things broke because users never cared to check sensitivity of key names.

Azure Functions are nightmare in its own. Not sure how much of that is Powershell fault vs Azure Functions.

>It’s also slow even for interpreted language standards.

Actually, it's blown Python out of the water at work. It's startup time can be painful as it's interpreting everything but once it gets going, it really moves. We use it to churn through 4GB CSV at work replacing a Python script, it's much much faster.

>I’ll seriously never use powershell for anything serious ever again even though I admit syntax and design feels kinda nice.

Your loss. Despite the few problems I run into, I really like it and wish more *nix people gave it a try. It's much better then bash nightmares I've seen.

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

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

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.

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.

Free software is typically described as "free as in freedom" or "free as in free beer". (This is probably a limitation of English tho, my language has 2 different words for permissions and costlessness.) GP above proposes the "free as in puppy" variant, which means that it is a burden of maintenance. I can't recall any real examples for this.

Sorry but no it doesn’t. These words have the other meanings you mentioned, but they don’t include either of the meanings of “free”.

If you said you were giving away “gratuitous software”, native English speakers wouldn’t know what you were talking about. The only way to understand it would be to realize that those words are etymologically cognate to words in European languages that do have those meanings.

"Gratuitous" also has that definition, though it's far less common in use. See the dictionary definition, e.g., here: https://www.dictionary.com/browse/gratuitous

> 2. given, done, bestowed, or obtained without charge or payment; free; complimentary.

It's more of a stretch there, because the primary definition of gratuitous has a connotation of unnecessary, even undesirable. If you didn't have at least some hint of disapproval of a service, you'd reach for the word "free" long before "gratuitous".

Similarly you would say someone who’s gotten out of prison is now “free” (or libre in French or Spanish) but you wouldn’t say they’re “liberal”.

Strangely enough, I think the LaTex distribution qualifies, too. I tried to install it recently, and it wanted 1 GB of disk space! That's multiple times the size of the entire system disk when LaTeX was created...

Sooner or later a lot of the web is going to run on WASM, at which point we'll have a virtual machine running in a user program running on an OS which incompletely virtualizes the bare machine (hence why we've ended up with WASM). Extra gratuitousity if the browser is an Intel binary being run on an M* processor via Rosetta translation... Maybe eventually we'll realize that the OS needs to provide a full virtual machine, complete with window to draw in, filesystem isolation like Plan 9, etc. But, inertia will probably make it take while.

There is the TinyTeX distribution, which is smaller. (Despite its name, it isn't tiny, or small, or medium in size, but it is also large. But smaller than the default LaTeX distribution with all the possible packages, source code and documents.)

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.

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.

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

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