Is CBL-Mariner going to become Microsoft Linux?
boxofcables.dev
boxofcables.dev
(correction: gregkh works for Linux Foundation, Sasha Levin works for MS).
Azure Sphere OS for embedded is based on the Linux kernel, https://static.sched.com/hosted_files/ossna19/91/Crossover_E...
There's also their NOS for merchant silicon whitebox networking, https://www.linuxfoundation.org/press/press-release/software...
> SONiC is an open source network operating system (NOS) based on Linux that runs on over 100 different switches from multiple vendors and ASICs.. members including Alibaba, Broadcom, Dell, Google, Intel, Microsoft, NVIDIA.. Microsoft founded SONiC.. as open source so the entire networking ecosystem would grow stronger. SONiC already runs on millions of ports in the networks of cloud scalers, enterprises, and fintechs.
DirectX on Linux, https://lkml.org/lkml/2020/5/19/742
Other MS contributors to LKML: https://lore.kernel.org/lkml/?q=microsoft.com
I see they are still going strong on the embrace, extend extinguish strategy.
The general idea behind it are good in my opinion. But the problem is how confusing and slow the god damn thing is.
Try overriding a service definition? You must know to set exec to empty string before you are allowed to override it. Really first line sets to "" second to the value you want. Just weird.
Try getting the logs of the service you just edited and restarted? Wait 10s on a flagship computer for the 5 lines of log to show up.
Systemd stores logs in binary. That takes more storage space than gzipped text. While being about 100x or more slower than zcat and co.
Devuan [1] or freebsd it is for me until an alternative emerges
[1] - https://www.devuan.org/
system-d being spread everywhere is a side-effect of that
Yes, we also add what we like and what we want to see, but companies employ these developers to implement what they need inside Linux.
We have kernel-bypass-networking because of Cloudflare. BSD has extremely fast networking because Netflix and other companies needed it, Linux has better power management because server needed it, etc., etc.
I also have points which I don't like with systemd, but companies are neither new, nor they're gonna leave Linux alone (and, they shouldn't).
Everyone’s free to use it, though. The entire thing is up on GitHub someplace (on mobile, so can’t dig out the repo easily), but some assembly might be required for your use case.
As an anecdote, when I was playing around with it (built a VM, some containers, etc.) I also moved my personal laptop to Fedora because I realized I was out of touch with modern RPM-based distros.
Microsoft may be just doing something for their needs, and putting in the open like a good citizen of the FOSS world, but the older people who remembers whatever happened back in the day have all their rights to be paranoid about MS.
"Eh, this is the old Microsoft, today's one is different" is just a sentence. They still don't (and probably never will) inspire confidence when it comes to Linux and FOSS.
We see what they have done with GitHub, for a start.
(It was a little annoying to get vaguely threatening, but overtly insulting e-mails at my taoofmac.com address the first couple of months, though. Oh, and I’m a Mac user, too. Try to factor that in …)
When these definitions merge, Microsoft looks like a cozy home with a fireplace inside, but built like a spiky poisonous ball outside, designed to crush anything and everything.
I don't want to act like a bone headed old men yelling to the cloud, but from outside, none of this is visible.
Oh, even Microsoft screwed its own supporters with hot-reload support incident in .NET Core.
Whenever I say myself, "OK, past is past. No need to be this rigid", Microsoft does another thing to make me return to my old stance. Maybe Microsoft needs to be able to see itself from outside?
Seems like we're not so different in the amount of history we have accumulated about these things called computers, so we have possibly seen many (if not all) of the big events shaped the industry.
I'm not grim or angry, but have generous reservations for the company and its motives, that's all. I'm seeing Microsoft as an elephant in the china shop, contemplating the most efficient maneuver to break everything at once.
That's all.
They are working from within to make it more sensible for the rest of the world, but progress is hindered by the overwhelming momentum in the opposite direction remaining from those who are not on the same page at all.
Provide free hosting for countless FOSS projects?
and provide the resulting source code to anybody regardless of the source and target license w/o consent via Copilot.
Also, it was free for FOSS even way before Microsoft, so that part doesn't even count.
That is one opinion. Mine is they used the code as allowed under the Github terms of use and/or the principles of fair use. Ultimately it doesn't matter what either of us think. A court will decide.
If this is going to be a desktop offering from Microsoft, I think it will be for remote cloud and potentially WSL2 use only. The future of desktop Linux is a VM under Windows.
Windows deployment isn’t bloated, it just has a ton of actual functionality that real users want and that doesn’t come for free. The UX for the admin is also super nice, with tons of online articles and communities with people who are willing to help you do what you’re trying to do, as opposed to tell you why what you want is bad.
A base Windows installation takes up a lot of space mainly because of Microsoft's compatibility commitments and the implementation strategy it uses to maintain them, and to some extent the way libraries are typically distributed. Neither OS features, nor hardware compatibility, nor the selection of included applications has much to do with that. Microsoft delivers some real value through their compatibility commitment, but it's a different thing than functionality.
> The UX for the admin is also super nice, with tons of online articles and communities with people who are willing to help you do what you’re trying to do
This is frankly a stunning claim. From local configuration being the hodgepodge of many generations of GUIs to the incompleteness to the painful slowness of completing a task through visual imitation to the fundamental hostility automation to the slowness and incompleteness of PowerShell to the absolutely anarchic nature of software management on the platform, administering Windows machines is a cumbersome, manual mess.
> communities with people who are willing to help you do what you’re trying to do, as opposed to tell you why what you want is bad.
This is an illusion afforded to those who come to both operating systems with Windows-centric expectations. In this very forum, you can find Windows users who respond to posters who complain about defects that come up with Microsoft's official Windows port of OpenSSH by telling them they never should have tried to use rsync to transfer files between Windows machines.
With any operating system, there will always be people who respond to questions involving solutions that are at odds with the paradigm, strengths, or cuatoms of the operating system with advice to re-think the problem. (And sometimes, they'll be right!)
> You mean the tons of online articles and communities trying to get you to purchase spyware?
Linux has a substantial amount of communities and support, and with systemd things are getting pretty routine there isn't a lot of ways to mess things up like people in Windows communities telling you to reset various windows components by deleting important system files.
If Microsoft has their way, you mean.
If regulatory agencies were to let them get away with it - which is a very big “if”.
I have always found it funny that Microsoft provides a free service to the Linux community which makes them significantly safer, and for their trouble they get no end of shade from that community.
Is there really any demand for this though? What Linux gui apps exist that windows users want/need? Enough that Microsoft sees an addressable market large enough to get roi?
The inverse seems to have way more practical use cases that could actually drive revenue - games and legacy business applications (as mentioned in the esr prose).
Never used it since. I did have the Linux version of dBeaver installed that way but there is little/no difference just running the native Windows install for that.
The only use I can really think of is doing cross-platform GUI development, but even then MS will say "hey look, native Linux windowing support in WSL" and also "Not yours, no linux version of MAUI for .NET"
Kind of a mixed message.
Since it's likely that some developers at Microsoft have some prior experience with Windows development, I wonder if they find Gnome and GTK philosophy more close to Windows programming experience than KDE, QT etc. I also wonder if we will see a GTK backed for .NET MAUI.
https://web.archive.org/web/20050204084517/http://www.mslinu...
;)
To be clear, I'm not saying that "you should be outraged," necessarily. It's just an interesting thing.
I've probably just gotten inured to apt, but do you say RPM is the least horrible because the interface is more logical/convenient, or just better at managing dependencies?
Interesting take. Care to elaborate?
Arch Linux itself has very few packages— ~10k, around half of what you find Fedora, an RPM-based distro. The DEB packaging format and tools related to it are way more convoluted, and still Debian has several times as many packages as Arch and many, many more maintainers than Arch does.
The only area where the Arch community sees more contributors for packages is the AUR, where contributors are decidedly not maintainers, package quality is low, and packages are not stable. (And users face this in addition to the whole basic integration problem with source-based packages and packages installed via binary repos, of which only the latter is ever considered by pacman's dep solver during upgrades.)
Users like pacman because it's fast. It's not nearly robust enough for use at serious scale. Cutting corners is how it gets that speed.
Alpine's apk is just another lightweight cousin of dpkg that incorporates some higher-level dependency resolution in a barebones way, like ipkg and opkg, like are used on embedded systems or OpenWRT or whatever. It's not some maintainer magnet which has multiplied the (pretty tiny) Alpine repos (which don't even include, for example, a JVM).
Also, Alpine certainly does have a JVM so that statement is flat out false and now sure where you're getting your misinformation from.
As for the substance of your reply:
> Zypper and dnf still use RPM BTW.
Yes, this is what I said. Zypper and dnf are high level package management tools comparable to Pacman. RPM is not.
> stable packages (meaning up-to-date)
That's not at all what the word 'stable' means, but
> Arch Linux and Alpine maintains significantly more [up to date packages] than other DEB and RPM-based distros
This is also false. Look at the numbers: https://repology.org/repositories/statistics/newest
Debian Unstable has > 18k up-to-date packages. Fedora Rawhide has > 14k. openSUSE Tumbleweed has > 9k. Arch has fewer than 9k up-to-date packages.
Arch has fewer up-to-date packages than any of the most prominent RPM-based or DEB-based rolling release distros. It does have a larger percentage of its (relatively very small) total package collection at the latest versions from upstream: https://repology.org/repositories/statistics/pnewest
On that front, the difference between Arch and Alpine is greater than, e.g., the difference between Alpine and openSUSE. Debian Unstable about matches up with the AUR on that metric.
Not to mention that Nixpkgs, whose tooling is pretty much the polar opposite of Pacman's KISS philosophy, has more packages than Arch and the AUR combined and has more packages which are up-to-date than both combined.
I am sure that the simplicity of the PKGBUILD format has been important in the personal journeys of many package maintainers for Arch Linux. But the notion that this means that Arch has attracted so many maintainers that is capable of keeping a greater number of packages up-to-date is absolutely unsupported by the facts. The further claim that this (fictional) superiority reflects fundamental technical virtues in its package management system that make it a better base for enterprise Linux distros than something like Fedora or Debian or openSUSE is a huge leap and a non-sequitur.
Imagine if the people who work at those companies aren't your enemy. But instead are potential customers and potential collaborators, who see value in your work and want it to succeed.
Imagine if there was a good implementation of some idea, expressed as code. And we can all share and contribute to that single good implementation to avoid pointless work and avoid fragmentation. Imagine people from all across the world contributing both financially and via bug reports and pull requests to making that implementation succeed.
This fear of being exploited by big companies seems to motivate a lot of people in the free software world, and personally I find it pretty odious. Why shouldn't big businesses use my code? The better opensource companies (Google, new Microsoft, Facebook, etc) contribute back to the community in all sorts of ways; and I consider that a net positive on the world.
I've seen this fear show up for decades in all sorts of contexts, and I think I disagree with it every time. For example:
- A few years ago I was involved in a big argument over the licence for OpenStreetMaps. There were essentially two camps: the "Oh no what if (big evil corp) uses our community mapping data to make their map better" camp, who wanted a restrictive anti-company license. And people like me who just wanted to give a gift of mapping data to the world.
- This is the gap between GNU GPL (especially GPL3) and BSD/MIT licenses.
As an opensource maintainer, I do have a problem with people who work at big companies expecting me to volunteer my time responding to issues on github. I'd like big companies who file issues to contribute financially in exchange for my attention.
But if they don't pay, I'm more than happy for them to use my code. I made it for everyone. I'd really like it if fewer people needed to reinvent the wheel for silly licensing reasons.
It's unlikely to beat lzo family on decompression speed, but that's a different class of compressor entirely. And probably there are still some more tricks zstd can learn from closed-source Oodle leviathan, but i don't think much more can be learned.
There's a little x86_64 assembly but I don't see a single SIMD instruction anywhere, and no intrinsics neither. Seems like brotli is the same. I assume zstd still gains something from SIMD autovectorization in the compiler, that might be interesting to benchmark with- and without- such a flag.
Since the zstd bytestream got frozen in RFC8478, messing with the layout too much will require a zstd2 and moving the whole world again to use it (linux kernel compression, rpm binary format, etc)
And you don't need anyone's permission to make zstd better. You just need their permission to merge your changes into their (upstream) branch. If you think you can maintain zstd better than facebook, fork their code and compete with them. Its BSD licensed after all! And if your zstd changes are sufficiently compelling, maybe everyone will start using your version instead.
As a general rule, if I opensource some software I've written, I'm under no obligation to accept pull requests in any form. My time is my own. Facebook is free to run their zstd project however they like. They're already doing good in my books by sharing it with the world, for free, under a BSD license. They don't owe you anything more.
Yes, but we'd have to imagine it isn't microsoft doing it.
You'd think people would learn the dozenth time it happens, but no, here we are again with copilot and VS Studio Code.
Copilot is a whole other beast. I don't think there's any simple answers there.
If GitHub, VS code, an MS Linux, and perhaps somehow LinkedIn, prove to be a joint front to EEE the F/OSS community, what can I say...
Seems somewhat unlikely though, given the number of allowances that must be made for that to hold true.
Although if you are to believe the terrible kernel commits they were attempting to make to allow them to do an Nvidia closed source shim then it wouldn't shock me.
The CoPilot thing is new and troubling.
Well, it's a very tiny detail, but VSCode proper is not open source, and you can't built VSCode proper from the available source out there.
Microsoft has arranged things so that actual open-source builds of VSCodium will always be lacking in comparison to their proprietary product.
Errm, this is also my point, written in a slightly ironic form.
This is why I use neither, too.
Cheers!
Being ok with big company participation gets you Linux and / or FreeBSD. Not being ok with it gets you HURD.
I am ok with it.
Participation != appropriation.
As someone who contributes to BSD licensed code, please don’t tell me my users are “appropriating” my work. I’m happy my code is being used, and the more the merrier.
This is completely false. See https://www.gnu.org/licenses/gpl-faq.html#NoMilitary
> I'd like to license my code under the GPL, but I'd also like to make it clear that it can't be used for military and/or commercial uses. Can I do this?
> No, because those two goals contradict each other. The GNU GPL is designed specifically to prevent the addition of further restrictions. GPLv3 allows a very limited set of them, in section 7, but any other added restriction can be removed by the user.
> More generally, a license that limits who can use a program, or for what, is not a free software license.
So BSD/MIT is less restrictive in that sense. There is no obligation to change the license of any code that uses it.
Because free software is in a constant battle for relevance, and they will use your code to make their proprietary offerings strictly superior to the free ones. What do you think would happen if Autodesk were permitted to fork Blender into a paid product, extend it in all sorts of proprietary ways, and push it heavily through advertising campaigns and educational subsidies? Blender would die, is what.
You know, I don’t think it would? If autodesk depended on blender, and the core of autodesk was blender, I think autodesk would throw gobs of money at making sure blender flourished. They’d probably try and hire lots of blender devs too - just to get them to work on core blender features so they could make autodesk better.
There’s plenty of examples of this happening in the wild. Is FreeBSD dead because macos is built on top of a lot of its code? Is redis dead because of redislabs’ proprietary offerings? No.
Is SQLite hurt by all the projects built on top of it? No. The opposite - it’s strengthened by being used.
Of interest, the CBL-Mariner ”system distro” is where the X server is for WSLg. https://raw.githubusercontent.com/microsoft/wslg/main/docs/W...
Yes, they run as containers.
From https://github.com/MicrosoftDocs/WSL/issues/1573#issuecommen...:
WSL distributions (instances) are not VMs. They are best described as "containers" running inside the WSL2 VM. Each WSL2 distribution/instance has its own isolated:
PID namespace Mount namespace User namespace (I believe) Cgroup namespace (And probably) IPC and UTS namespaces WSLg System Distribution (Windows 11 only) init process However, they all share the parent VM's:
Network namespace Device tree (other than /dev/pts) CPU/Kernel/Memory/Swap (obviously) /init binary (and some other binaries that are injected in)
Azure integration
Same reason they brought MSSQL to Linux.
But that doesn't say anything about the majority of the developers out there. From my experience Python and Ruby guys usually do use Linux and macOS, while .NET and Java devs run almost always Windows on their PCs and laptops.
M1 has made a lot of people eager to jump too.
However with containers running directly on top of hypervisors and serverless, it is only a matter of time until the actuall OS of the server room is irrelevant.
Until then, Linux and BSD (which they also support) are business relevant.
I'd have assumed Arch and friends.
> I'd have assumed Arch and friends.
I'm a huge Arch (and NixOS) user. But one of the things that I think is difficult about Arch in an enterprise is that by design it is difficult to standardize enterprise tooling around. Ubuntu, on the other hand, has a bunch of defaults that can be more reliably be predicted for in an enterprise.
I'm a security engineer and I've thought long and hard about why enterprise applications often lack Linux support -- it would be difficult to have something that works across the board (there are so many choices of desktop environments, notification daemons, network subsystems, etc.). If I were to write enterprise applications that targeted Linux I would probably target the default config of the current LTS release of Ubuntu (Gnome as the desktop environment, etc.).
I feel like Ubuntu is the desktop developer environment for the enterprise that is forward enough to support desktop Linux.
I've been trying to have a similar strategy to you with regards to enterprise long-uptime application deployments. I target RHEL and Debian Sid because they move at a almost glacial pace and have quite a bit of documentation.
Do you ever wonder what the trajectory of Microsoft and Canonical looks like with regards to an M&A perspective? It would be a good contender to counter Red Hat's dominance in the enterprise space.
- the procedure for upgrading to a newer release of ubuntu it you run sed as root to fix your sources.list, then you do-release-upgrade, but it doesn't work because it has an undocumented dependency on pciutils
- at this point i should be used to this pciutils thing since ~all software has undocumented dependencies on autoconf, automake, autotools, libtool, cmake, ninja, rust, python2, python3, calling the binary called python in your path and expecting it to be a particular version that is 2 or 3 but some stuff needs 2 and other stuff needs 3, perl, npm but not the latest npm, clang but not the clang in the repositories, gcc, nvm, ruby, lua but not the latest lua, bazel, make, openssl, libressl, libcrypto, a different version of libc that will break almost all software on your machine when you install it, a bunch of optional obscurely named C header packages that install the headers into folders that the build won't search for header files and that turn out not to be optional if you want the thing to work at all, and a hundred different javascript build automation and test automation tools that exist mainly to call each other
- snap will just install broken package updates for you and is incapable of undoing this operation by design
- systemd-resolved will randomly just start taking 250+ms to return cached DNS entries so if you call connect() many times per second you need a much bigger threadpool than you may have expected (and this is maybe an architectural change to your software if your previous threadpool size for connect() offloding was 1 or if you were naively calling connect() on your thread where you do actual work)
- if you thought you knew how to set the open file limit for a user, systemd has rearranged your furniture and by the way this operation now requires you to reboot your computer
so i'm not sure ubuntu has been a great fit, but i'm also not switching to anything else
I no longer recommend Ubuntu for this reason to people looking to get into Linux for the first time for developer-adjacent reasons. My recommendation is now Mint or Pop_OS, as they are effectively Ubuntu without Snap.
Edit: I am not blindly against snap, or against its idea outright. I understand what it is for, and if it delivered on that without issue, I would welcome it. My avoidance of Ubuntu is due to having to repeatedly (and increasingly) help Linux newbies through problems, where lately all of those problems have wound up being based in snap.
you can set up systemd in WSL 2 now, and it's supported, but it gave my Ubuntu distro a lot of problems so I disabled it there. in Debian it works great so I left it on.
Never tried Firefox, cannot day works or not, have Firefox on Windows' side of the things.
Are you talking about upgrading an lts release to the next dot.1 lts release, without dodgy third party apt-sources enabled?
When you skip releases, no distro will officially support such upgrades (except for Ubuntu LTS-to-LTS, without skipping an LTS), and things might break.
Also, when you really want to skip releases, it is often better (IME) to change the sources manually and not use do-release-upgrade, but use aptitude and/or synaptic and/or other such tools to fix the dependencies manually. In any case, you might have to fix some breakage afterwards (or mid-upgrade…), as it is untested & unsupported.
I was curious if this was a saying I'd never heard of or if you just came up with it. Seems you just came up with this?
What's amazing is that Google already has this HN post indexed and you're already the first hit for the phrase. And even weirder, Google says that they (currently) indexed it 56 minutes ago, when HN reports you posted it 23 minutes ago. Google is now apparently predicting the future 33 minutes in advance.
https://www.google.com/search?q=The+Devil%27s+rummaging+thro...
Whatever content appeared on the page after Google indexed it is something Google shouldn't know about.
One interpretation is that Google is lying about the indexing time.
But it seems more likely in this case that they're reporting the indexing time of the page they link to ( https://news.ycombinator.com/item?id=33458756 ), rather than the indexing time of the comment you're responding to ( https://news.ycombinator.com/item?id=33459157 , which can only have been indexed half an hour ago).
In other words, they updated their cache of the page content without refreshing the indexing timestamp.
> Google determines a date using a variety of factors, including but not limited to: any prominent date listed on the page itself or dates provided by the publisher through structured markup.
> Google doesn't depend on one single factor because all of them can be prone to issues. Publishers may not always provide a clear visible date. Sometimes, structured data may be lacking or may not be adjusted to the correct time zone. That's why our systems look at several factors to come up with what we consider to be our best estimate of when a page was published or significantly updated.
https://developers.google.com/search/blog/2019/03/help-googl...
Google is a boring old replayer of trite old stuff and quite right too - that's what it does! I suspect it also reads HN on a tight loop - many of the locals there are also from this parish.
I suspect even the eye of Sauron doom scrolls HN ...
It's just a variation on similar sayings like "the devil's putting on ice skates".
[1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
With Microsoft Linux Enterprise Edition, you can create
scalable multi-tier applications using our new Graphical
User Interface command-Line Technology (GUILT)?. Extend
your productivity with optimized support for Internet
Active-XWindows? Technology and built-in Internet Xplorer
web browser.
...
Hot Topics
Microsoft Invades Cuba
Microsoft Monkey Colony on Mars
MS Linux to have Start Button
MS Linux Faces Competition
It even shipped with GUILT - Microsoft's Graphical User Interface command-Line Technology /s
Man, what a time to be alive! Who would have thought it.
Edit: who's extending, embracing and extinguishing now?!
Still an open question, I'd say.
Be as watchful as you want, be aware that the enemy isn’t coming though.
I think it's more like, "Why run a NT Kernel?" or from an MS internal perspective, "Why fund development and testing of an NT Kernel? We already made it so all legacy Windows apps run natively on Linux anyways"
The day they push some proprietary or oddly licensed technology to be integrated into their Linux is the day a thousands alerts should be raised into the community. Then will come software that runs only, or runs better, on their Linux. WSL was the first step: making something with both Microsoft and Linux in its name accepted by the community.
> The day they push some proprietary or oddly licensed technology to be integrated into their
> Linux is the day a thousands alerts should be raised into the community.
TianoCore is an open source reference implementation of UEFI maintained by Intel; there's no proprietary Microsoft stuff in there.
Microsoft seek to ease development for users who either choose Windows or who are forced to use Windows by an employer. there's no "play" here, no extending or extinguishing. They want, like any reasonable developer would, a better world for software developers.
Here, here. I haven't seen anything yet that isn't straight out of the MS playbook on this.
has Dell, or anyone else, been told to stop selling laptops with Linux in favor of Windows with WSL under threat that they won't be able to sell Windows laptops anymore?
exactly what world are you seeing, because it isn't the one I live on.
MS Linux including MS Support! But install your favourite RPMs...
Probably but Samba already does AD so you don't need Microsoft to do it. I guess PolKit at some point may offer similar functionality as group policy.
AD has been very solid in my experience. Samba has big shoes to fill in my mind. Is it really workable as an AD replacement for a real production AD environment today?
Having said that, as a former directory engineer (iPlanet/Sun/Oracle/ForgeRock) I don't think any of the Azure AD workarounds, including samba's (who really needs CIFS in a world where files can be served up over https with secure OAuth?), are worth all the extra effort. If you need an enterprise directory, you should deploy one. The good news is that both Ubuntu and Red Hat now support Azure AD, so you're not stuck with half measures.
Of course not every shop _needs_ a system/network directory, and both those Linux ecosystems support a range of user and system management options that can do the job. Even if you finally find yourself in need of something more, AWS and GCP offer competitive identity services that can work just as well with non-legacy systems as Azure AD (so long as you don't have any Microsoft PaaS or SaaS dependencies).
eDir is what AD should have been.
I use it as a free 15% go-faster button in my consulting gigs.
Today they "emulate" Linux on Windows (WSL2), tomorrow they will "emulate" Windows on Linux (i.e. all the Win32, etc APIs on Linux - think WINE++).
Rather than windows::nt or gnu::linux, the first "Linux on Desktop" will happen with windows::linux.
In 2015 I bet my friends this would happen in 2025. It might not happen exactly that year, but all signs point towards before 2030.
No. Microsoft tried to bridge the Linux APIs to NT APIs in WSL1 just like WINE does for Windows APIs to Linux APIs. But they ended up running into issues and limitations that made them change their approach.
Now, with WSL2, they just have a virtualized instance of Linux running. This isn't even an odd choice as Windows has already been running on top of a hypervisor for anyone who has Hyper-V enabled (new installs of Windows 11 have it enabled by default to support Virtualization Based Security).
WSL1 doesn’t implement the Linux syscall interface on top of the user-mode Win32 or NT APIs. Rather, it runs in-kernel; it calls kernel-mode NT APIs (only some of which directly correspond to NT syscalls), and (I assume) also implements some aspects of the Linux APIs internally to itself. Its approach is rather different from that of Wine or Cygwin, both of which translate one user-space API to another; and also from the legacy Windows OS/2 and POSIX/Interix/SFU/SUA subsystems, which implement those APIs mostly in user space, on top of the NT user-space API. WSL1 is essentially unique; the closest analog is probably the Linux syscall emulation in FreeBSD/NetBSD, Solaris10/Illumos LX branded zones, and the old Linux iBCS2 personality - although those are all far easier because there is much less mapping in emulating the Linux API on another POSIX OS than one fundamentally non-POSIX.
> But they ended up running into issues and limitations that made them change their approach.
I don’t think those issues were inherently insurmountable, and solving them in the context of WSL1 would have made Windows a better platform, since many of those issues (e.g. poor filesystem performance) also impact native Win32 apps. But, they made a decision on where to invest their resources. WSL2’s implementation strategy requires less engineering work overall to reach a given outcome.
And I also don't think any of the problems were insurmountable. I'm still disappointed that they gave up on WSL1. (At least partially because I thought the whole Windows Subsystem concept was neat design)
It depends on what you mean by "NT APIs". If you mean the NT API exposed to user-mode (NT syscalls), no, that is insufficient to implement WSL1 (or anything else like it). If you mean to include kernel-mode-only NT APIs (including undocumented/private APIs which MS doesn't expose to third parties, even new APIs added specifically for WSL1 to consume), then yes that is.
> the whole Windows Subsystem concept was neat design
Also worth keeping in mind, that WSL1 is not an "environment subsystem" in the sense that Win32 is – or OS/2 and POSIX/etc were. It has a radically different architecture from a classic Windows NT environment subsystem.
Uhh, I think you miss read my post. I agree with you WSL1 was a dead end. It tried to put Linux on top of NT.
I believe MS will try to put Win32, etc on top of Native Linux APIs (removing NT entirely). WINE and Proton have effectively done 90% and MSFT will have a way simpler time of getting it to 100% given they dont have to worry about their own copyright.
MSFT also has the financial motivation to stop developing the NT Kernel, so it’s valuable for them to invest into this “WINE++”.
NT has features which Linux kernel devs have actively opposed including – such as alternate data stream support in its VFS/IFS layer, and a stable device driver ABI. So even supposing – and I'd be rather surprised if it were to ever actually happen – Microsoft were to release the NT kernel under a GPL-compatible license (thereby eliminating many of the legal issues), they still might find it a great struggle to get the necessary features upstreamed.
Important parts of Windows – e.g. synchronisation primitives – cannot be emulated on top of the Linux syscall API as it currently exists (with accuracy and high performance), due to gaps in functionality. See https://lore.kernel.org/lkml/f4cc1a38-1441-62f8-47e4-0c67f5a... for some of the gory details. I note that LKML message appears to have received zero replies, which is not an encouraging sign for any progress on that issue.
> MSFT also has the financial motivation to stop developing the NT Kernel
It would be a huge investment to extend the Linux kernel to be able to support a 100% correct and equal performance emulation of the NT API, and to port that API to run on top of it. Even with such a huge investment, there would be no guarantee of success (what if Linus refuses to upstream the required features?). And, if it legally requires open-sourcing large parts of the existing Windows kernel (due to GPL compatibility), that would greatly improve the viability of Wine/ReactOS/etc, threatening Microsoft's existing Windows revenue stream. The financial case for what you are proposing is far less clear than you think it is.
Apple’s Rosetta 2 and Valve’s Proton have shown that these kind of emulations can be extremely effective. When you control the OS code, and are willing to be extremely hacky for the medium term, anything is possible.
If I were to lead this effort I’d do:
1. Try my best porting the Win32 APIs, Direct3d, to Linux. I’d convert many of them. Use Office, the Windows window manager, Visual Studio, etc as test suites. This can be deployed to users where there is no performance regression.
2. Update any non-legacy applications to use more of WSL2 especially were incompatible with the new Win32 APIs. eg Office, Electron, Chrome, Visual Studio.
3. Build a binary parser like Rosetta that detects use of any incompatible Windows APIs. Mark these binaries as “legacy” (this parsing only needs to be run once per binary). Run legacy binary processes through a hyper visor and slimmed down snapshot of Windows.
4. Investigate more traspiling of binary code like Rosetta, but for Windows APIs to WSL APIs.
5. Announce it and state the intention to migrate.
Many modern apps are Electron anyways. Actively supported apps will slowly migrate to more performant APIs. Legacy apps were not designed for today's hardware anyways and it would work just fine with a little performance degradation but overall still a performance win compared to when the app was released.
Rosetta and Rosetta 2 are CPU emulation with the same underlying OS – so quite a different problem from what WINE/Proton/etc address. And something Microsoft actually already has anyway – their implementation is less impressive than Apple's in terms of performance, although it can do some interesting things which Apple's can't – in particular, mix emulated x86-64 and native ARM code in a single binary image and process (Arm64EC) – Apple fat binaries are two completely separate binaries concatenated together into a single file, only one of which is actually loaded; Windows Arm64EC binaries mix x86-64 and Aarch64 code in a single binary image, so one function can be native and the other emulated. A program can be native Aarch64, but still be able to load legacy x86-64 plugin DLLs, with some performance penalty incurred for the later [0] – something Rosetta or Rosetta 2 can't do, although Classic MacOS had similar support for mixing emulated 68k and native PPC code in a single process.
Valve's Proton is just a fork of Wine, and it works great for a carefully curated subset of games. However, games are a relatively narrow category of applications, there are lots of things other categories of applications will do which games never will.
> 3. Build a binary parser like Rosetta that detects use of any incompatible Windows APIs
Sometimes, the problem is not with the APIs themselves, but particular patterns of using them. A straightforward emulation of a Win32 API under Linux will behave the same for the vast majority of cases, but in rare edge cases will behave differently. Inspecting a binary to detect what APIs it uses won't tell you whether it is one of the minority of APIs which depends on one of those edge cases. Sometimes the developers themselves won't even know, because it is not unheard of for developers to do weird stupid things by accident rather than intention, yet it just so happens they work, and they don't even realise they've done something weird and stupid.
The biggest problem with your proposal, is will the huge dollar investment it would require of Microsoft, actually be worth it for them? Even if (maybe) saves money in the long run, it will cost a lot more in the short-to-medium term. And the fact is, Windows licensing revenue is still massive enough to more than pay for what Microsoft is spending on Windows development, so there is no financial pressure for them to save money in the long-run – and migrating Windows to Linux would make it easier for their customers to migrate away from Windows, hence risking that revenue stream. Why take such a big risk with one of their cash cows for such an unclear benefit for them?
[0] https://devblogs.microsoft.com/windows-music-dev/load-x64-pl...
Those closet ADs will end up dirsync’d to AAD, and their inventory/CRM/etc app will be whichever SaaS figures that out fastest.
The only great argument for running Windows Server is Exchange and Active Directory (or IIS for legacy .Net Framework applications). That being said though, Exchange is so janky you're better off outsourcing that if at all possible.
This kind of thinking is the equivalent of putting no-name retread tyres on an F1 car. Like okay, it’ll function, technically. It will save money. Is it a good idea?
Maybe I‘m spoiled with proper linux posts but MS totally shines though with that. Yuck!