Microsoft: Linux Is the Top Operating System on Azure Today
thenewstack.io
thenewstack.io
If MS did a better job at supporting headless Windows distros to compete with Debian (and similar linux) distros, it would be more popular.
For 9/ 10 tasks, it's way easier to spin up Debian , install a web / db / app server and have a running solution.
With windows you're still running through dozens of MSI packages, setup screens. It's too inconsistent.
There are workarounds to this, but they are not as mature & familiar as the corresponding linux setup.
It's the UX not the platform.
Red Hat, Suse and Canonical do charge.
Just because RH, Suse and Canonical charge, does not mean those are requirements. You can always opt to have linux and not pay for their support.
You are leaving a gaping hole in your servers if you are not patching them (the distro's that charge and you decide not to pay)
also, many org's opt to pay for Ubuntu Pro for piece of mind.
But the real key is that do-release-upgrade sucks because it's too conservative because they roll back when there are any errors or dependencies they can't resolve. If you do your release upgrades manually, you can always work through those issues. Debian/Ubuntu busybox includes dpkg, so even if you end up in a very broken state (glibc version mismatch, coreutils don't work, bash is broken, etc.). You just need a copy of busybox installed, tmux, and maybe a portable SSH daemon and a statically compiles curl, and you can do everything the release upgrade process does but with the ability to rescue a failure instead of rolling back or dying. It's probably good to follow the same upgrade path as that tool likes though (only directly upgrade between adjacent releases or from one LTS to the next LTS), so you may have to do this a couple of times if your servers are really old.
(I guess you don't really even need any of those statically compiled tools, either— you can just use Nix to provide whatever you need instead since no Nix-provided tools care about the libs provided by the underlying Ubuntu system.)
At a past job I upgraded in-place some Ubuntu 14.04 web servers to 20.04 through some release-upgrade failures this way. It's generally better to rebuild on a new, clean image, but in-place upgrades on Linux rarely fail and are pretty much always rescuable when they do.
- you can choose to pay RedHat, Suse and Canonical
- you cannot choose not to pay Microsoft
It really comes down to the requirements for your app as defined by the vendor and/or the internal team.
Plus, Linux is way lighter when compared to Windows. I can easily fit a stable and reliable server inside 512MB of RAM with a couple of services on top of it.
You can only dream this on Windows. CPU requirements has the same gap. Linux is way lighter.
Lastly, Linux can be tweaked from terminal completely. You need to do complex tricks to do the same in Windows.
More specifically than just "lighter", the Linux distro metaphor and ecosystems have already adapted to decomposed use cases. You can run the same Debian or whatever image in a Docker container that you do on the bare server (or RPi/SBC) that you do in a Desktop VM or a Xen cloud host. Your ssh-based deployment and maintenance scripting works the same, etc...
Windows gets sticky and weird the farther you get from a desktop deployment. It's a soup of special case tooling and "Here's How You Do This One Thing". So when those things change, Linux folks just tweak their install scripts a bit where Windows users need to wait for someone to Design a Product for the niche.
This is what everyone was saying back at the dawn of cloud hosting, and it's exactly how it's played out. Windows can be made to work, but... why would you?
You open a serial port the same way you open any file. Same call, single line.
In Windows that was 30+ lines to begin with. NT is not bad, but it’s not UNIX, and designed to be complete opposite of it. No user land can change that. Even “subsystem” functionality can’t make it replace Linux as we see today.
A lot of the software written for Windows assumes that there is a UI available. This makes it harder to automate things.
> Windows as an OS is not as resilient as Linux when it comes to non-ideal operating conditions.
macOS, for example, operates a comparatively limited set of hardware platforms.
And it runs on super underpowered boards too, on which windows doesn't even have any chance of booting
The Windows ecosystem supports a ridiculous variety of hardware.
Yes it does. RedHat deprecates older drivers, but it's their problem. I connect too many stupid things to my Debian box, and they're enumerated and initialized instantly. These drivers get bug fixes too.
The Windows that comes preinstalled with most computers truly "supports a ridiculous variety of hardware", but that happens because some professional has already spent some time with the installation of Windows together with all the device drivers provided by the vendors of the various weirder components included in that computer.
When I had to install Windows on embedded computers I had countless problems. I had to use frequently some complicated methods to give device drivers to the Windows installer at an early phase, because it was not able to boot on those computers. Their BIOS/UEFI lacked many legacy features, while Windows lacked drivers for some modern features, so they were mismatched.
Even after Windows was eventually installed, some of those computers had SSDs with low writing speeds, which made them unbelievably slow in Windows due to some stupid and useless Windows services, which by default were writing continuously the SSD and it was very difficult to disable them. Fortunately, that was Windows Enterprise, so it was possible to disable Windows Updates. On some of the computers with problematic SSDs, after the initial installation, booting required more than an hour, because that much was required every day to perform Windows Updates. Only disabling both Windows Updates and various indexing and swapping services has lowered the booting time to normal values.
On the other hand, Linux booted immediately on any of those computers, without having to do anything, and in comparison with Windows it was blindingly fast. Obviously, because those computers were intended to be used as embedded computers they did not have any of the peculiar peripheral devices that are usually included in laptops and for which their vendors provide neither documentation nor Linux device drivers, so they are unusable in Linux unless successfully reverse-engineered, while working fine in the preinstalled Windows.
That kernel runs on cheapest phones, and on largest supercomputers. With a similarly wide diversity of software. A much more heterogeneous environment than Windows can dream of.
> With container workloads, "Linux" is just the kernel; userland can be largely absent.
It supports the $200 junkbox your gran bought from Walmart to $20,000 enterprise racks and is expected to support all of those different workloadsDell sells a PC and it has to work with any number of possible storage devices. Users might swap out the modem. It is expected to work with any PCI-E device. It supports hundreds of classes and models of devices like printers and scanners. etc. etc.
Saying that "it is used on phones" doesn't really mean much when there are only what? 5? 6? major phone manufacturers supporting a limited and largely homogeneous set hardware configurations. Same for cars; a small pool of manufacturers and suppliers on identical hardware configurations.
Fair, but let's not forget a couple of facts.
First of all, most of the early Linux woes stemmed from two main roots. Drivers, and bad implementations of standards (ACPI & APIC most prominently). Lower cost Windows machines always needed "vendor drivers" to workaround what sins vendors committed with bottom of the barrel hardware, so these drivers handled the non-standard things they did with the already crippled hardware.
Let's also not forget that Microsoft tried their best to weaponize standards to break Linux (in a similar fashion they broke Dr. DOS). See: Halloween Documents [0].
So given your hardware implements the standards correctly, and you have drivers for your hardware, Linux works way better on the same hardware than Windows. This brings us to
> It supports the $200 junkbox your gran bought from Walmart to $20,000 enterprise racks and is expected to support all of those different workloads and insane variety of software that can be installed.
I have two Intel N100 boxes. One is running W11, the other one is running Debian Testing w/KDE. Former is my parents', latter is mine. Mine is using less RAM, running way cooler, and uses less CPU cycles to accomplish harder tasks, while supporting all the hardware on it, at full speed. So, given your hardware implements the standards, and you have drivers, there's no difference in support. It's not a design/kernel issue. It's a support/willingness issue.
I just remembered that Valve's Source Engine ran 25% faster on Linux after porting without any post-port optimizations, which is a great example how Linux is generally lighter and how well it can perform if given proper drivers for any piece of hardware.
> In contrast, I'd make the case that the majority of Linux distros are running in large data centers like AWS, Azure, and GCP where there's a relatively high degree of homogeneity of the underlying hardware and the operating environment on top of that.
I'm an HPC admin managing clusters close to two decades. The problems you encounter on these systems when something goes wrong is way complex than you see on desktop systems. All of these resiliency features create tons of complexity while helping you. Linux runs on these systems better for a longer time, because these systems are implementing standards correctly for a longer time, and you pay for expensive hardware and correct implementation of it, so kernel bundled drivers work correctly 99.9% of the time when you change the hardware.
> macOS, for example, operates a comparatively limited set of hardware platforms.
XNU is for all intents and purposes is BSD kernel, and macOS can be considered a BSD. Give proper drivers, macOS can also run on from your spoon to a satellite. It's POSIX compliant. They even contribute back to BSDs.
It's that windows isn't POSIX compliant. It's easier to port libraries, etc. to run on OSX than it is on Windows. There's all sorts of weird gotchas when porting to windows as well. Setting up many language runtimes, compilers, etc. is all very different and oftentimes poorly supported. There's far smaller of a critical mass of libraries that will run on windows either (natively not on a VM).
IIRC Kubernetes could have windows node as well?
EDIT: yep... https://kubernetes.io/docs/concepts/windows/intro/
https://learn.microsoft.com/en-us/virtualization/windowscont...
Microsoft can easily drop a fork of windows, slam out all of the com crap, leave .net core and include some IIS, but why, you already have someone doing it in Linux.
That then makes Windows less appealing to the infra-as-code crowd, which is growing to be “almost everyone” these days.
It’s not just having an image with those things, it’s the entire surrounding ecosystem. Eg my experience with exe or msi installers is that using them without a GUI ranges from “difficult to find the right CLI switches” to “just not gonna happen”.
Also, I think a lot of that com crap is used by Powershell, so gutting it also means giving up CLI access to stuff.
This was my student job during college :) wrapping installers in scripts so they'd install headlessly.
My favorite part was that windows would need to be rebooted CONSTANTLY. Seriously. Provisioning a new box for some environments would result in TEN OR MORE reboots depending on exactly what shitware you had picked to install. And by shitware I do of course mean exorbiently-expensively-licensed academic/scientific software. The more scientific it was, somehow the exponentially worse the installer experience would be.
We had one package where we were literally forced to cram in a step where you would literally pick up the phone and call IT and someone would come over and plug a USB in while the install proceeded. The software was able to be network-licensed but only post-install, the installer itself never got the memo and wanted the usb to be physically present on the box during install.
Death by a thousand cuts (and some big gashes), Windows is just not built to work headlessly/scriptably, period. And trying to make it work like that takes tremendous investment, constant babysitting, and it's still fairly shitty even in the end.
Meanwhile we just apt install shit in dockerfiles and it just works.
It's more lucrative to license Windows + SQL server + MS 365 + etc etc than hourly VM rates.
SQL server is also offered as a managed service on Azure, and you can query it from your linux server just fine.
There's some automation, but the maturity level is 2/10 compared to linux.
So there's a chicken-egg issue that Windows doesn't provide adequate automation out of the box to create the automation ecosystem that has led to the turnkey solutions available to linux customers.
I can also run PowerShell
When you set up your next Windows workstation, set a rule that you perform all of your configuration (incl. application settings, as far as is possible) via PowerShell or other automation. It very quickly becomes immensely frustrating, but doing the same on Linux is much less so (Mac is somewhere in the middle).
You'll also find that when it comes to achieving something you don't yet know how to do, even finding a scriptable solution on Windows is kind of a nightmare because both the Microsoft documentation and every third-party website and blog is flooded with (useless, for this exercise) manual GUI garbage.
DSC is nice, though.
Linux's share holders are the community around the developers and users. They want to continually make a better products. There are no stock holders to court.
This is why Microsoft will not produce a more viable product that people are looking for in the server and embedded market. Their Oligarchy locks them into company IT infrastructure and PC gaming. I would also argue that Mac OS is a better personal OS when gaming is not a requirement but they are cost prohibited by the average person, so Microsoft eats that cake too.
However even if they were much better than they currently are, many people go to Linux workloads due to licensing.
Unless the applications they are deploying depend on Win32 features.
A substantial problem for the Linux ecosystem on Azure is that Azure Files is not POSIX compliant. With Container Apps, ephemeral storage is POSIX compliant. However, if you mount a persistent Azure Files file system and use it directly, some applications break. One workaround is to use rsync in the background to replicate data from ephemeral to Azure Files, but we can lose data this way (and ephemeral storage is limited to 8 GiB).
It'd also be nice if "Consumption Only" container apps would have more than 4GB of memory. It's so nice to use these.
NFS is fine for configuration files or read only. But workloads that do any sort of intensive writes will probably not like NFS, from SQLite up.
The newest NFS versions might fix some of the issues around caching that cause problems for write operations though.
Is this a paid ad we are reading, or a news article? Genuinely confused.
Yes, we know.[0]
[0] https://www.kickscondor.com/satya-nadella-'reads''games'-hac...
Is there a paved path for bringing up NixOS on Azure VMs? I haven’t looked hard yet, but I’m about to so if this is a known thing I’d be grateful for any pointers.
https://techcommunity.microsoft.com/t5/windows-os-platform-b...
I'm assuming Microsoft has pivoted to SaaS and the Cloud, and the OS plays a lesser role in the current form of Microsoft. Gone are the days of Steve Ballmer. Windows and Office are no longer the primary cash cows.