[Info-vax] RMS intro

[Dan Cross]

In article <un2icp$2vhkg$4 at dont-email.me>,
Lawrence D'Oliveiro  <ldo at nz.invalid> wrote:
>On Wed, 3 Jan 2024 00:03:36 -0000 (UTC), Dan Cross wrote:
>
>> 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.

>> In article <un26bd$2sllq$2 at dont-email.me>,
>> Lawrence D'Oliveiro  <ldo at nz.invalid> wrote:
>>
>>>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.