"Stardate 2020. There is a mainstream OS with great driver support and the best gaming performance, that everybody uses (Linux). There are two other OSs battling for survival: One run by open source fanatics that release open source editors, browsers and programming languages and which frantically tries to emulate the mainstream OS (WSL), and one where stuff constantly breaks on upgrades, fundamental hardware like keyboards doesn't work, and keeping enter pressed logs you in as root (OSX)."
Sure some get a performance boost, but I believe more get a performance hit than a boost (and that's not counting the ones that don't even run at all).
...on servers. It's still far, far from "mainstream" for desktops.
Still, that's a really big deal. I work for what is firmly a Microsoft shop, and nobody bat's an eyelid now if we use Linux VMs (as long as they're cloud-based).
I think 3 things in particular have driven the rise of Linux as a mainstream server OS:
1. docker/containerisation. Sure, Windows containers exist, but have you ever seen one in the wild?
2. The shift to the cloud, in conjunction with (3)
> 1. docker/containerisation. Sure, Windows containers exist, but have you ever seen one in the wild?
I have. What is done on .NET stays on Windows, for UNIX like OSes we get to use Java.
Yes there is .NET Core, it is the future, not all MS shops are buying into it due to the current limitations, waiting to see how .NET 5 will actually look like.
I'm truly surprised you've seen Windows containers in the wild - across dozens of engagements with very firm Microsoft shops, I've never seen them, nor seen the need. Gods, even MSSQL runs on Linux these days!
I'm also very surprised you'd claim that not all Microsoft shops are buying into dotnet core - I've seen the very opposite; every client I've worked with has known dotnet framework has been superceded by core, and has been eager to move. A decent portion of this is driven by certain containerisation, which (realistically) means dotnet on Linux.
The only real limitation with dotnet core has been the lack of managed C++ support - a niche use case, and only relevant on Windows, but even this has been resolved in dotnet core 3.1.
Considering the not insubstantial performance improvements in dotnet core, and of course the benefit of cross-platform code, I'm really interested to hear about the limitations of dotnet core you've found (the switch for me and all the enterprise clients I've worked with has been great)?
Plenty of Microsoft shops are deeply invested in technologies like WCF, EF6, ODP.NET, WPF/Forms component libraries, commercial CMS stacks (e.g. Sitecore), and aren't willing to allocate budgets to rewrite what is working perfectly fine.
The kind of enterprises where deployments on IIS, with AD infrastructure on premises, Windows on all company layers are still the name of the game, with some Linux servers for running SAP and a couple of other Java based services.
What is missing from .NET Core 3.1?
Besides what I have listed above, EF 6 on Core doesn't support the Visual Studio graphical tooling nor the EF 6 .NET Framework EF providers, WPF/Forms designers are still WIP and have issues with commercial component libraries, WCF well, no one is looking forward to rewrite their working code with gRPC.
And many are still a little burned with Silverlight and how the whole WinRT, UAP, UWP story went.
Back in the .NET Code 2.0 days, I had a project to rewrite a .NET Application into Java, because the customer in question saw a better business value in doing so than investing in .NET Core. Mainly because .NET Core didn't had support for some critical libraries being used in the .NET Application, while the libraries vendor did support a Java counterpart for them.
Yes, they will eventually move to .NET Core, when it makes business sense to allocate budget to do so.
> It's still far, far from "mainstream" for desktops.
Desktops themselves are far from mainstream! The vast majority must be owned by gamers and video editors; both groups use predominantly non-Linux for reasons mostly unrelated to support that is or isn't in the kernel.
It was always possible to uninstall it. Just a nuisance that you have to, while clearly no users ever desired it. It was also terrible that all search requests went plaintext to Amazon.
Updates since 2004? It's like they took an old snapshot of BSD userspace and some of the syscall interface, except somewhat broken (see the long saga of broken select/kqueue in OSX). Fundamentally Darwin is a completely different beast based on Mach. It's radically different from the core BSD kernel. Most of their userspace is built on Objective-C, which has 0 overlap with BSDs.
It's cool that the Mac community used some BSD code way back when — that's why we use a permissive license — but they've forked whatever they took; they never work to integrate their changes back upstream. To the extent that they're a BSD, they're a very very divergent fork of a historical BSD. And that's fine, for them. I don't know if that makes them a BSD or not in some ontological sense.
To be clear, they mostly publish their changes under open or even copyleft (APSL) licenses. The problem isn't one that the GPL solves. They just dump the modified sources on their FTP and make no attempt to interact with upstream.
The limited exception is Clang/LLVM, where to some extent they are the upstream.
(A clarification: I also like the MIT license, but the majority of BSD is published under the so-named BSD license, with some number of other clauses. You might already know that, and if so, sorry for repeating the explanation; I wasn't sure from your comment. They're both permissive, but not identical licenses.)
Open-source, for one, but that's more than just a philosophy in BSD. One of the key design considerations touted by BSD communities is that the kernel and userspace are distributed and built as one cohesive system for which you can get all the source / rebuild on your system. And that's done far more often than in Linux and other more mainstream OSs. But it's not a BSD kernel and what's distributed / used is very far removed from open-source Darwin and anything you could rebuild yourself. On the more subjective side of things, BSDs tend to value simplicity and correctness over new features. OpenBSD takes this to an extreme, but FreeBSD still takes it a lot further than Apple does.
But other than having more claim to the UNIX title than Linux and having some BSD userland, it's really not technically a BSD at all. I'll grant you it's arguably a distant descendant of BSD under the surface or in your shell.