What I said is that it is a fraught proposition to try to keep up with
the rate of change in the Linux kernel from outside of the Linux kernel.
And that "outside of the Linux kernel" includes the part of the Universe
containing Microsoft. It, too, has a struggle, even with its vast
resources, keeping up with the pace of Linux kernel development.
A) you are clearly speculating about the "resources" you think
that Microsoft can apply to Windows. B) you have not
acknowledged that, whatever resources MSFT can bring to bear,
Linux can _bring more_.
To which I replied that almost certainly the inverse is true; i.e., that
the Linux kernel folks probably have access to several orders of
magnitude more resources than Microsoft can put to Windows.
Given how much revenue Microsoft is supposedly earning from Windows, don't
you think it should be putting a proportionate level of investment back
into it?
A amateurish attempt to change the subject, but regardless,
that's a business, not a technical, decision at Microsoft. It
could be that they see the writing on the wall and don't feel
that it's a good investment.
That "niche" is the reason why they have had to resort to WSL2, to bring
Linux-type APIs to Windows. And why do they need Linux-type APIs on
Windows, anyway? Because that's what the developers are increasingly
relying on. Why didn't WSL1 work? Because the Windows kernel wasn't up
to it.
That seems like speculation on your part.
Microsoft's own actions are all the evidence we need. Why abandon
something, after putting so much effort into it, if you could have got it
to work?
Your logical fallacy is assuming that because they _dont't_ do
something that that implies that they _can't_ do that thing.
There are many reasons that they may choose not to do something
that are totally independent from their ability to do that
thing.
They surely moved to WSL2 because the best, cheapest way to be "bug
compatible" with Linux is to just run Linux.
After already putting all that investment into WSL1? That good old NT
kernel not versatile enough to emulate the little quirks as well as the
salient features?
Strawman. We've already discussed why they decided to move to
WSL2. Here, their inability to keep up with Linux is not about
technical ability, it's about resources, which (again) they have
fewer of than the rest of the world combined applies to Linux.
As further evidence, consider how WINE is able to be bug-compatible with
Windows, on top of the Linux kernel. Why can't Microsoft, with more
resources at its disposal than both the Linux kernel and WINE projects
*combined*, return the favour?
Again, you are assuming that Microsoft has "more resources at
its disposal" than Linux, but I see no evidence of that; in fact
I see significant evidence to the contrary.
Go ahead and browse the commit lots in the Linux kernel git
repo: how many author addresses end with meta.com, amazon.com,
google.com, ibm.com, intel.com, amd.com, redhat.com, nvidia.com,
adobe.come, etc? Or, for that matter, microsoft.com? And we're
not even talking about the smaller companies (altera, et al).
Even for those that don't, how many of the remaining offers work
for one of the FAANG companies? Do you really think that
Microsoft has more resources _combined_ working on Windows than
the rest of those companies are devoting to Linux?
As for WINE, it's compatibilty is not great.
Python is important; this has does not imply that
Unix-style select/poll on a pipe under Windows in Python is important.
So how do you run that large installed base of Python code on Windows
without that compatibility?
Since the vast bulk of Python code out there probably doesn't
try to mix pipes with select or poll, I'd imagine you just run
it.
For more general types of asynchronous IO (storage, networking) it says
nothing at all, and these are certainly more important than pipes which
are just one kind of IPC mechanism (and not super relevant to Python
specifically).
They're a core feature of POSIX. They exist because they make for a very
convenient model for certain common kinds of IPC, as the original Unix
creators discovered in their experiments.
"...in their experiments." Um, sure. Doug proposed it and Ken
implemented it in a weekend. It was relevatory in the context
of Unix, but not necessarily in other systems.
But so what? We're talking about Python code here, which mostly
insulates the programmer from something as low-level as POSIX.
Again, it seems like the thing that the vast, vast majority of
the tiny fraction of Python programmers who deal with such
things are going to care about is asynchronous IO for networking
and storage, not pipes. Honing in on that one aspect of
incompatibility doesn't really go very far to prove a general
point.
Remember why Microsoft needs WSL, clunky as it is: it's not something it
bestowed as a special favour on the Linux or open-source world or
anything like that: it created it because it had to, for sheer business
survival.
I actually agree with this, but I think your argument here is poor.
MSFT needs Linux compatability because the world is trending towards
Linux and they can't keep up, yes. It does not follow that their
engineers are bad, or even that their kernel is bad.
WSL1 would be evidence to the contrary.
Not really; see above.
And yes, engineers can be individually smart, yet due to a dysfunctional
and risk-averse corporate culture, they end up producing a mediocre net
product.
Maybe, but that's a different matter. I think the probability
that you know someone who's worked on both Linux and Windows at
the kernel level is approximately 0, as evidenced by your lack
of understanding of the technical and business issues involved.
- Dan C.