[Info-vax] RMS intro

[Dan Cross]

In article <un26bd$2sllq$2 at dont-email.me>,
Lawrence D'Oliveiro  <ldo at nz.invalid> wrote:
>On Tue, 2 Jan 2024 23:16:45 -0000 (UTC), Dan Cross wrote:
>
>> In article <un1uj4$2raer$1 at dont-email.me>,
>> Lawrence D'Oliveiro  <ldo at nz.invalid> wrote:
>>
>>>On Tue, 2 Jan 2024 20:56:56 -0000 (UTC), Dan Cross wrote:
>>>
>>>> In article <un1s48$2r0sq$1 at dont-email.me>,
>>>> Lawrence D'Oliveiro  <ldo at nz.invalid> wrote:
>>>>
>>>>>On Tue, 2 Jan 2024 19:41:21 -0000 (UTC), Dan Cross wrote:
>>>>>
>>>>>> Furthermore, the rate of change in Linux is high; following along 
>from
>>>>>> outside is fraught.
>>>>>
>>>>>Strange, isn't it: Microsoft must have access to at least a couple of
>>>>>orders of magnitude greater development resources than that available 
>to
>>>>>the Linux kernel project,
>>>> 
>>>> Almost certainly the inverse is true.
>>>
>>>Yet you yourself have already admitted the opposite.
>> 
>> I don't believe I have.  Perhaps you could tell me where you
>> think I did?
>
>Where you used the word "fraught".

I don't see it.

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.

On the other hand, you said,

|Microsoft must have access to at least a couple
|of orders of magnitude greater development resources than that
|available to the Linux kernel project

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.

The two are unrelated.

>>>else why can’t they figure out how to get 
>>>select(2)/poll(2) working with pipes <https://docs.python.org/3/library/
>>>select.html>?
>> 
>> Probably because they started out with a very different system
>> architecture and din't care about implementing Unix interfaces
>> at the time, and now have to retrofit it onto a very large
>> existing codebase and that's kind of a niche use case.
>
>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.  Do you have any
special expertise in this area?

They surely moved to WSL2 because the best, cheapest way to be
"bug compatible" with Linux is to just run Linux.  That really
doesn't say much about what the Windows kernel is, or is not,
capable of.  It might say something about their development
priorities, though.

>> When you write that about select/poll and pipes and that being
>> an "irritating reason" for a more general issue, that seems
>> specious.
>
>Maybe you don't realize how important Python has become in the computing 
>world lately, with its applications in data science and other areas. 

Non sequitur.  Python is important; this has does not imply that
Unix-style select/poll on a pipe under Windows in Python is
important.  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).

>Microsoft is even planning to offer Python access to Excel users (at least 
>cloud-based ones).

Again, this is conflating "python" (which I understand runs on
Windows just fine; I wouldn't know, as I don't do Windows) with
pipes+select and python.

>And it's not just Python, of course: Windows limitations affect cross-
>platform development across the board. To the point where Microsoft has to 
>do something to stem the tide of developers simply giving up on the 
>Windows platform. Hence WSL. Which is essentially a bag duct-taped on the 
>side of Windows.

This seems like pure speculation.

>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.  It does mean that their kernel was designed with
different goals than Linux (which is a Unix knock-off).

	- Dan C.