Microsoft themselves call it "Purpose-Built for Azure", why cannot the other Microsoft/Windows salesmen also call it that instead of "general purpose server and container distribution"?
> It could also be general purpose for what you can run on it.
Yeah of course, it's a Linux distribution. But feels like a marketing push when multiple people suddenly go "oh yeah Microsoft building a general purpose Linux distribution" when that's not what's happening. So what if it isn't general purpose and built purposefully for Azure? It doesn't remove anything, just being more accurate with how it's being marketed.
When you create a VM on these cloud platforms the categories are like "general purpose, high memory, high cpu, high gpu" and there's various types of VMs to select from. They are simply using the terminology that DevOps folks use when discussing instance types. General purpose just means it's not tuned to favor anything in particular. Don't overthink it. You are not the audience.
> General purpose just means it's not tuned to favor anything in particular
Agreed, that's why it doesn't make sense to call this "general purpose", since it's specifically tuned in favor of Azure:
> Azure Linux was built with that principle in mind: a single, Microsoft-supported Linux foundation designed to work across every Azure compute surface [...] with a predictable update cadence designed around Azure infrastructure
It's quite literally tuned for Azure and Microsoft...
I think the GP used the word "tuned" incorrectly / to make the wrong point here.
A general-purpose OS is one to which you can build a stack on top of it for any use-case you can think of, and it will cope with whatever stack you lay on it about equally well, because it hasn't been forced into a particular shape where it's much better at some things but much worse at other things. A "jack of all trades, master of none" OS.
Microsoft would call all consumer and server editions of Windows "general-purpose OSes." But Windows Datacenter Edition and Windows IoT Core would be non-general-purpose OSes — the former only exists to run hypervisors/SANs, and it doesn't support "stripping off" that layer, so if you used it for anything else, that layer would always be there, bloating things up; and the latter only exists to run on embedded devices, and it doesn't support "adding back" the extra frameworks and services regular Windows has, that would be required to use it for "more" than embedded use-cases.
An OS being "tuned" for a particular substrate (what the OS is good at running on), meanwhile, has nothing to do with the OS's use-case (what can be run well on the OS.)
An analogy: each mobile OEM's spin of Android only works on that OEM's own phones, because that OEM's phones have the required hardware wired to the right SoC pins, and the Android spin ships with a BSP that defines a device tree that matches that expected wiring. Thus, those OEM Android spins are "tuned for" those phones.
But in the end, they're all just Android phones, and they can all do the same things. All of these Android spins are "general-purpose OSes." They're all made to enable you to put any Android software you like on top of them, and run it just fine. (Contrast Android spins made by industrial vendors specifically for automotive or kiosk use-cases, where a given car company or kiosk manufacturer then produces a hardware-customized-and-tuned spin of that already-appliance-purposed spin. You wouldn't use a car-infotainment Android upstream for other use-cases; you'd have to undo all the car-infotainment stuff.)
Azure Linux is exactly like a phone-OEM "tuning" of Android (and unlike a vertical-specific Android spin.) Azure Linux is also like, for another example, the vendor-specific Linux "distros" [really, tunings] that ship as (usually binary-only) images for various Single-Board Computers.
In all three cases, a "tuned" fork of an OS is still intended to run anything a user might want to run on the platform the "tuned" fork was forked off of. It exposes a general-purpose surface to the developer — just one that happens to do some of the general-purpose things you ask it to do, more performantly than a non-"tuned" OS would on the same hardware/substrate.
And, in all three cases, the "tuned" fork accomplishes that by relying on device-specific knowledge and capabilities (i.e. drivers, device-tree entries, kernel patches, etc) that have been burned into the "tuned" fork rather than upstreamed. There's still a HAL between you and that stuff; your workload doesn't need to know the "tuned" fork has been tuned. It just benefits automatically, from the OS having a deeper understanding of the hardware/substrate.
That is not a given. There are Linux distributions that run anywhere but are not general-purpose. For example, the various "immutable" Linux distros that exist solely to be used as Kubernetes nodes to host containers.
Your statement is contradicting with stating it was Purposely built for Azure.
Someone would have to make a Ubuntu equivalent and use Azure Linux as the base to turn it into a general purpose Linux OS.
Personally, I don't trust Microsoft and their Linux distro with how they Enshitified Windows OS and all of their other software products. Add in the fact that Microsoft likes to multi-count CVEs, per distro, instead of the actual flaw to try and make Windows OS look better when it comes to security.
Even within MS Azure Linux is at odds because it is not working in WSL out of the box. Folks had to port stuff to AZL away from ubuntu but without an easy path to use WSL to continue development. Sure you could adopt it but there is something fundamentally fragmented if such an adoption vector is missing in WSL. Now this… why do I need AZL desktop?
my theory is Microsoft's infrastructure does not yield as well do the best AI tools right now, which is all bash based; so they're struggling to 'catch up' so they can achieve at the least minimum gains.
I am more excited about WinUI Reactor than anything else. the gap between Compose/React thinking and XAML thinking is enormous, and Reactor just bridges it. I am curious about interoperability - how would one include a Reactor-based component into existing WinUI 3 app? how would one include a XAML-based control from some other library into a (future) modern WinUI Reactor app?
I retired last year but I too had to use a Mac for a year. It was the first and last time I ever used a Mac. I hated it. So many quirky behaviors, window controls on the wrong side, just wow I had a whole list I could have articulated last year but thankfully it's a distant memory now.
I used Macs my whole life until I built a PC in 2020 and put Linux on it. Recently I’ve started using a Mac again for work (and KVM switching between it and my Linux box), and I really do prefer Linux at this point. I have a variety of gripes, but Apple’s popup based “{App} wants to do {thing}” permissions model drives me bonkers, in particular.
This isn't a new observation by any means. You could literally have said that anytime in the last 3 or 4 decades about trying a mac when you're used to other systems.
And guess what? You can say exactly the same thing the other way around.
The thing is, I'm not talking about POSIX or CLI; I'm strictly speaking about the desktop GUI. macOS keeps going into a direction which is actively preventing being efficient with it, all the while making weird net-negative decisions about looks for reasons which can only be explained by UI and UX designers trying to sell themselves as useful internally. I used to be an early adopter, now I'm waiting for the enterprise-forced upgrade of major versions, which is the only reason I'm upgrading at all.
the macOS desktop GUI really is...not great. I tolerate it only for the hardware, and I'm only able to tolerate thanks to a bunch of little utility apps, and even there's some functionality that's not even possible (like setting a window to be always on top).
Finder's only saving grace is miller columns, it sucks in nearly every other way.
Windows+PowerToys is far more enjoyable and productive to use, as is basically any Linux DE.
macOS is fine if your usage involves one or two apps, all each with only one active window. The moment your work involves multiple widows of the same app (say 3 browser windows, a bunch of open Excel docs, multiple terminals) the entire apps are separate from their windows paradigm starts to break down. On Windows being able to alt+tab through browser tabs along with the rest of your open windows is great.
The average Joe? My wife has used Linux since the mid-2000's. Her career was in Sales, far removed from anything technical. She loves Linux compared to Windows, her new laptop came with Windows and she bugged my for months to upgrade it to Linux, which I did recently. She doesn't use the terminal at all. Kubuntu, btw.
Funnily enough the terminal which was the reason people said linux is too much of a hassle is the very thing that now makes it so you can easily fix your computer with natural language.
Sure the problem is it will still come with problems out of the box but that's mostly on laptop manufacturers. At least now you can easily fix them with an agent.
For me it's much more fun to tell my computer what I want and to get it than to scroll through a settings GUI but to each his own
That's what KDE (and gnome, to a lesser extent) have been trying to do for a long while.
The fundamental issue is that a GUI is a static abstraction over a CLI that allows for millions of potential combinations. You can only expose so many options in a menu before the interface becomes completely unusable.
To expand on your analogy, it’s like running a restaurant that only uses automated vending machines to serve food. It works perfectly fine if someone just wants toasted bread. But the moment a customer asks for more than toasted bread, you're toasted.
Imho, the best bet for the future is a bunch of pre loaded llm skills and clis an agent can work with: getting the chef to use pre-approved hardware, sorta, that can cook up anything that is needed.
> The fundamental issue is that a GUI is a static abstraction over a CLI that allows for millions of potential combinations. You can only expose so many options in a menu before the interface becomes completely unusable.
But is that an issue? Macs have had this solved for almost half a century: You expose things in the GUI that normal people need, not everything. For hackers, they can still go to the command line to hack.
> > The fundamental issue is that a GUI is a static abstraction over a CLI that allows for millions of potential combinations. You can only expose so many options in a menu before the interface becomes completely unusable.
>
> But is that an issue? Macs have had this solved for almost half a century: You expose things in the GUI that normal people need, not everything. For hackers, they can still go to the command line to hack.
Good point. I'd say, Linux has inherent complexity across multiple dimensions (less hardware integration, multiple stacks (is it running systemd-networkd ? Or maybe dns
macOS also exposes more advanced things through the GUI but not by default. Its largely undiscoverable, but holding option before clicking something generally offers more options (e.g., hold option and click wifi in the menu bar to get all the detailed connection information).
I like that method, keeps the default GUI clean but still offers GUI options for most things if you know where to look.
I agree but its becoming increasingly clear that "chatbot-as-the-CLI" is likely a "worse is better" situation. It's clearly crappier and slower than just hitting a button, but everyone knows what they want and they know how to put it into text. CLIs in the past never could cope because they relied on exacting, esoteric syntax, so mere mortals had to learn a lot about how to translate what they want "Send a copy of this photo to my friend Sally". So a button is abstracted that says "Send" and "Attach" and some file-based metaphor is built up to allow the work to map better to what people know and understand and can intuit.
My mom can't find the button in the GUI though, and odds are it would be buried in menus she'd get lost in. She can type "Send Sally this picture" into a box and hit go. Anyone literate can.
One thing that's been really useful for many years is the Help menu in MacOS. You click it and start typing the command you are looking for, and MacOS conveniently opens the menu and any submenus and shows you the command with a big blue arrow. Wouldn't this be easy to pair with a simple AI, so that people can more freely type what they want to do? Maybe even make it Spotlight accessible.
I like the visual and thus get along much better with drag-and-drop than any text based interface. So for me (and maybe your mom) the best solution would be that Sally was a window you could open and drag things to. Surprised that Apple and nobody else ever did this on desktop. At least on iOS, your friends are pictures that appear whenever you press share, but it's not perfect.
Great work! I really hope it can be designed to be agent-friendly. The current CodeX/Claude code sandbox functionality is very limited; it would be wonderful to use this as a sandbox.
Microsoft Linux... what an abomination. But each generation has to learn the lessons of the previous one, again and again. Have fun with the lock-in and e.e.e. Microsoft-fans!
> It is a general purpose server and container distribution.
My god, it isn't, where are people getting that from? The previous submission (https://news.ycombinator.com/item?id=48407499) from the very same author got it wrong both times?
Microsoft themselves call it "Purpose-Built for Azure", why cannot the other Microsoft/Windows salesmen also call it that instead of "general purpose server and container distribution"?
Both of those things are true in different ways.
Purpose built for azure probably means integration with azure meta data APIs and kernel specific tweaks for the hardware.
It could also be general purpose for what you can run on it.
Basically it's a curated distro. Not complicated or anything different from what AWS and GCE are doing.
> It could also be general purpose for what you can run on it.
Yeah of course, it's a Linux distribution. But feels like a marketing push when multiple people suddenly go "oh yeah Microsoft building a general purpose Linux distribution" when that's not what's happening. So what if it isn't general purpose and built purposefully for Azure? It doesn't remove anything, just being more accurate with how it's being marketed.
When you create a VM on these cloud platforms the categories are like "general purpose, high memory, high cpu, high gpu" and there's various types of VMs to select from. They are simply using the terminology that DevOps folks use when discussing instance types. General purpose just means it's not tuned to favor anything in particular. Don't overthink it. You are not the audience.
> General purpose just means it's not tuned to favor anything in particular
Agreed, that's why it doesn't make sense to call this "general purpose", since it's specifically tuned in favor of Azure:
> Azure Linux was built with that principle in mind: a single, Microsoft-supported Linux foundation designed to work across every Azure compute surface [...] with a predictable update cadence designed around Azure infrastructure
It's quite literally tuned for Azure and Microsoft...
I think the GP used the word "tuned" incorrectly / to make the wrong point here.
A general-purpose OS is one to which you can build a stack on top of it for any use-case you can think of, and it will cope with whatever stack you lay on it about equally well, because it hasn't been forced into a particular shape where it's much better at some things but much worse at other things. A "jack of all trades, master of none" OS.
Microsoft would call all consumer and server editions of Windows "general-purpose OSes." But Windows Datacenter Edition and Windows IoT Core would be non-general-purpose OSes — the former only exists to run hypervisors/SANs, and it doesn't support "stripping off" that layer, so if you used it for anything else, that layer would always be there, bloating things up; and the latter only exists to run on embedded devices, and it doesn't support "adding back" the extra frameworks and services regular Windows has, that would be required to use it for "more" than embedded use-cases.
An OS being "tuned" for a particular substrate (what the OS is good at running on), meanwhile, has nothing to do with the OS's use-case (what can be run well on the OS.)
An analogy: each mobile OEM's spin of Android only works on that OEM's own phones, because that OEM's phones have the required hardware wired to the right SoC pins, and the Android spin ships with a BSP that defines a device tree that matches that expected wiring. Thus, those OEM Android spins are "tuned for" those phones.
But in the end, they're all just Android phones, and they can all do the same things. All of these Android spins are "general-purpose OSes." They're all made to enable you to put any Android software you like on top of them, and run it just fine. (Contrast Android spins made by industrial vendors specifically for automotive or kiosk use-cases, where a given car company or kiosk manufacturer then produces a hardware-customized-and-tuned spin of that already-appliance-purposed spin. You wouldn't use a car-infotainment Android upstream for other use-cases; you'd have to undo all the car-infotainment stuff.)
Azure Linux is exactly like a phone-OEM "tuning" of Android (and unlike a vertical-specific Android spin.) Azure Linux is also like, for another example, the vendor-specific Linux "distros" [really, tunings] that ship as (usually binary-only) images for various Single-Board Computers.
In all three cases, a "tuned" fork of an OS is still intended to run anything a user might want to run on the platform the "tuned" fork was forked off of. It exposes a general-purpose surface to the developer — just one that happens to do some of the general-purpose things you ask it to do, more performantly than a non-"tuned" OS would on the same hardware/substrate.
And, in all three cases, the "tuned" fork accomplishes that by relying on device-specific knowledge and capabilities (i.e. drivers, device-tree entries, kernel patches, etc) that have been burned into the "tuned" fork rather than upstreamed. There's still a HAL between you and that stuff; your workload doesn't need to know the "tuned" fork has been tuned. It just benefits automatically, from the OS having a deeper understanding of the hardware/substrate.
> Yeah of course, it's a Linux distribution.
That is not a given. There are Linux distributions that run anywhere but are not general-purpose. For example, the various "immutable" Linux distros that exist solely to be used as Kubernetes nodes to host containers.
Your statement is contradicting with stating it was Purposely built for Azure.
Someone would have to make a Ubuntu equivalent and use Azure Linux as the base to turn it into a general purpose Linux OS.
Personally, I don't trust Microsoft and their Linux distro with how they Enshitified Windows OS and all of their other software products. Add in the fact that Microsoft likes to multi-count CVEs, per distro, instead of the actual flaw to try and make Windows OS look better when it comes to security.
Microsoft is a bad actor.
More on Azure Linux 4.0:
https://news.ycombinator.com/item?id=48407499 Azure Linux 4.0 is Microsoft's first general-purpose Linux (boxofcables.dev)
1 day ago | 143 comments
Even within MS Azure Linux is at odds because it is not working in WSL out of the box. Folks had to port stuff to AZL away from ubuntu but without an easy path to use WSL to continue development. Sure you could adopt it but there is something fundamentally fragmented if such an adoption vector is missing in WSL. Now this… why do I need AZL desktop?
Of course not, people talk about what they don't know.
This was released this week, and Microsoft clearly stated it is coming to WSL later this year.
But people love to take conclusions without informing themselves.
> it is not working in WSL out of the box
I added a bunch of weird stuff for the GUI and PowerShell for fun.
The base container boots out of the box just fine.
my theory is Microsoft's infrastructure does not yield as well do the best AI tools right now, which is all bash based; so they're struggling to 'catch up' so they can achieve at the least minimum gains.
I am more excited about WinUI Reactor than anything else. the gap between Compose/React thinking and XAML thinking is enormous, and Reactor just bridges it. I am curious about interoperability - how would one include a Reactor-based component into existing WinUI 3 app? how would one include a XAML-based control from some other library into a (future) modern WinUI Reactor app?
Don't be, if the WinUI team past performance is anything to come by.
They will leave it half baked like everything else since Project Reunion was announced in 2020.
The year of the Linux desktop.
Meanwhile I’m stuck on macOS for work. Oh the irony.
I retired last year but I too had to use a Mac for a year. It was the first and last time I ever used a Mac. I hated it. So many quirky behaviors, window controls on the wrong side, just wow I had a whole list I could have articulated last year but thankfully it's a distant memory now.
I used Macs my whole life until I built a PC in 2020 and put Linux on it. Recently I’ve started using a Mac again for work (and KVM switching between it and my Linux box), and I really do prefer Linux at this point. I have a variety of gripes, but Apple’s popup based “{App} wants to do {thing}” permissions model drives me bonkers, in particular.
This isn't a new observation by any means. You could literally have said that anytime in the last 3 or 4 decades about trying a mac when you're used to other systems.
And guess what? You can say exactly the same thing the other way around.
It isn't a problem as long one understands the difference between UNIX and GNU/Linux.
For me Linux had been mostly the UNIX that we have back at home, while most work was done in Solaris, HP-UX, Aix, DG/UX.
I am not attached to Linux specifically.
The thing is, I'm not talking about POSIX or CLI; I'm strictly speaking about the desktop GUI. macOS keeps going into a direction which is actively preventing being efficient with it, all the while making weird net-negative decisions about looks for reasons which can only be explained by UI and UX designers trying to sell themselves as useful internally. I used to be an early adopter, now I'm waiting for the enterprise-forced upgrade of major versions, which is the only reason I'm upgrading at all.
the macOS desktop GUI really is...not great. I tolerate it only for the hardware, and I'm only able to tolerate thanks to a bunch of little utility apps, and even there's some functionality that's not even possible (like setting a window to be always on top).
Finder's only saving grace is miller columns, it sucks in nearly every other way.
Windows+PowerToys is far more enjoyable and productive to use, as is basically any Linux DE.
macOS is fine if your usage involves one or two apps, all each with only one active window. The moment your work involves multiple widows of the same app (say 3 browser windows, a bunch of open Excel docs, multiple terminals) the entire apps are separate from their windows paradigm starts to break down. On Windows being able to alt+tab through browser tabs along with the rest of your open windows is great.
We're getting there. But I doubt your average joe will ever use anything that may require even once to type something on a terminal.
The average Joe? My wife has used Linux since the mid-2000's. Her career was in Sales, far removed from anything technical. She loves Linux compared to Windows, her new laptop came with Windows and she bugged my for months to upgrade it to Linux, which I did recently. She doesn't use the terminal at all. Kubuntu, btw.
The thing is now the average Joe doesn't need to. Just tell Claude to fix it
Imagine if different sectors worked like that. To go to a restaurant, each customer brings their own private chef to let loose in the kitchen.
Wouldn't it make more sense for OS makers to "tell Claude" to make a user friendly GUI for their terminal commands?
Funnily enough the terminal which was the reason people said linux is too much of a hassle is the very thing that now makes it so you can easily fix your computer with natural language.
Sure the problem is it will still come with problems out of the box but that's mostly on laptop manufacturers. At least now you can easily fix them with an agent.
For me it's much more fun to tell my computer what I want and to get it than to scroll through a settings GUI but to each his own
That's what KDE (and gnome, to a lesser extent) have been trying to do for a long while.
The fundamental issue is that a GUI is a static abstraction over a CLI that allows for millions of potential combinations. You can only expose so many options in a menu before the interface becomes completely unusable.
To expand on your analogy, it’s like running a restaurant that only uses automated vending machines to serve food. It works perfectly fine if someone just wants toasted bread. But the moment a customer asks for more than toasted bread, you're toasted.
Imho, the best bet for the future is a bunch of pre loaded llm skills and clis an agent can work with: getting the chef to use pre-approved hardware, sorta, that can cook up anything that is needed.
> The fundamental issue is that a GUI is a static abstraction over a CLI that allows for millions of potential combinations. You can only expose so many options in a menu before the interface becomes completely unusable.
But is that an issue? Macs have had this solved for almost half a century: You expose things in the GUI that normal people need, not everything. For hackers, they can still go to the command line to hack.
> > The fundamental issue is that a GUI is a static abstraction over a CLI that allows for millions of potential combinations. You can only expose so many options in a menu before the interface becomes completely unusable. > > But is that an issue? Macs have had this solved for almost half a century: You expose things in the GUI that normal people need, not everything. For hackers, they can still go to the command line to hack.
Good point. I'd say, Linux has inherent complexity across multiple dimensions (less hardware integration, multiple stacks (is it running systemd-networkd ? Or maybe dns
macOS also exposes more advanced things through the GUI but not by default. Its largely undiscoverable, but holding option before clicking something generally offers more options (e.g., hold option and click wifi in the menu bar to get all the detailed connection information).
I like that method, keeps the default GUI clean but still offers GUI options for most things if you know where to look.
I agree but its becoming increasingly clear that "chatbot-as-the-CLI" is likely a "worse is better" situation. It's clearly crappier and slower than just hitting a button, but everyone knows what they want and they know how to put it into text. CLIs in the past never could cope because they relied on exacting, esoteric syntax, so mere mortals had to learn a lot about how to translate what they want "Send a copy of this photo to my friend Sally". So a button is abstracted that says "Send" and "Attach" and some file-based metaphor is built up to allow the work to map better to what people know and understand and can intuit.
My mom can't find the button in the GUI though, and odds are it would be buried in menus she'd get lost in. She can type "Send Sally this picture" into a box and hit go. Anyone literate can.
One thing that's been really useful for many years is the Help menu in MacOS. You click it and start typing the command you are looking for, and MacOS conveniently opens the menu and any submenus and shows you the command with a big blue arrow. Wouldn't this be easy to pair with a simple AI, so that people can more freely type what they want to do? Maybe even make it Spotlight accessible.
I like the visual and thus get along much better with drag-and-drop than any text based interface. So for me (and maybe your mom) the best solution would be that Sally was a window you could open and drag things to. Surprised that Apple and nobody else ever did this on desktop. At least on iOS, your friends are pictures that appear whenever you press share, but it's not perfect.
Great work! I really hope it can be designed to be agent-friendly. The current CodeX/Claude code sandbox functionality is very limited; it would be wonderful to use this as a sandbox.
I use bubblewrap inside Ubuntu inside WSL. https://github.com/nix-tools/bubblebox
I had issues with bubblewrap inside the container and creating namespaces. Need to dig into a bit further.
someone once said - windows will die or will be killed by Microsoft - when they start pushing a windows flavored linux distro.
with all the arm chips coming into consumer hardware - seems we are about to be there.
Microsoft Linux... what an abomination. But each generation has to learn the lessons of the previous one, again and again. Have fun with the lock-in and e.e.e. Microsoft-fans!
Devs already forgotten the IE lesson and have offered the Web on a plate to Google.
The return of Xenix :)
That’ll be deprecated in 6 months. Nope.
This is not official.
Azure Linux 4.0 is the next version of Azure Linux (duh), and WSL base distro.
is it replacing CBL-Mariner as the utility distro for WSL?
Yes, Azure Linux 4 is the evolution of CBL Mariner.
Search for Linux talks on Microsoft Developer channel, related to BUILD 2026.
Bluecurve? Is this some type of delayed April Fools?
I was hoping someone would catch that.