[Info-vax] RMS intro

[Dan Cross]

In article <umvlnj$2cmas$1 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>On 1/1/2024 3:15 PM, Dan Cross wrote:
>> In article <umv3ll$2adef$1 at dont-email.me>,
>> Arne Vajhøj  <arne at vajhoej.dk> wrote:
>>> On 1/1/2024 11:52 AM, Dan Cross wrote:
>>>> [snip]
>>>> ...right now.
>>>>
>>>> The windows market share is, as you yourself mentioned earlier
>>>> in this thread, continuing to shrink.
>>>>
>>>> People at Microsoft aren't stupid.  They can see the long-term
>>>> direction themselves.
>>>
>>> Windows desktop market share is not shrinking much. The
>>> problem for MS is that the desktop market itself is shrinking - a
>>> lot of casual users are switching to phones and tablets. Most
>>> still have a PC, but because it is not used so much then they
>>> are kept way longer than they used to. So PC sales is dropping
>>> and Windows sales is dropping.
>>>
>>> If MS want to continue the big presence in the consumer segment,
>>> then they need to address it. Somehow they need to get into
>>> the phone and tablet market. This is why the MS CEO recently
>>> said that he regretted killing Windows Phone.
>>>
>>> Creating a Linux desktop distro is not going to help with this
>>> problem, because it is not what the customers are looking for.
>> 
>> You seem to conflate, "using the Linux kernel" with "creating
>> a Linux desktop distro."
>
>(if they want to reduce cost significantly, then that would
>be what they would need to do)

Nope.  Again, you're conflating replacing the Windows
kernel with a producing "desktop Linux distro."

>But no matter what they do to their desktop OS, then it does not
>solve the problem of people moving from desktop OS
>to phones and tablets.

Indeed.  So as their market share continues to shrink,
support costs will continue to be significant.  Moreover,
Windows revenue is not growing as fast as other parts of
their business, and as applications move to the cloud,
there is less incentive for users to run Windows.

>>>>>>> For desktop/laptop the vast majorities of users has no interest
>>>>>>> in Linux at all. Windows are facing serious challenges, but not
>>>>>>> from (traditional) Linux. Windows usage is dropping because
>>>>>>> people are switching to Android/iOS phones/tablets.
>>>>>>>
>>>>>>> People are switching from a GUI centric OS (Windows) to
>>>>>>> GUI only OS (Android & iOS) for casual use. Expecting them
>>>>>>> to use WSL command line utilities is a non-starter.
>>>>>>
>>>>>> This conflates two things: WSL as a path for moving to Linux
>>>>>> as the kernel substrate for Microsoft's OS offerings, and using
>>>>>> WSL as an end user.
>>>>>>
>>>>>> The latter is likely never going to happen outside of developer
>>>>>> communities.  The former could well happen; WSL gives MSFT a
>>>>>> low-cost way to dip their toe into the waters and explore
>>>>>> interoperability between the traditional Windows API and Linux.
>>>>>
>>>>> If MS wanted to switch to Linux kernel then Win32 API for Linux
>>>>> would be very interesting.
>>>>>
>>>>> But WSL does not provide anything for that.
>>>>>
>>>>> WSL 1 provided the opposite direction - Linux API on Windows kernel.
>>>>
>>>> ...and integration at the file level.
>>>>
>>>>> WSL 2 is just a VM with a very smart/transparent integration.
>>>>
>>>> As I said, it's a way for them to dip their toe in the water and
>>>> explore compatibility.  It's obviously not the end state.
>>>
>>> "dip their toe in the water" and "explore compatibility" ????
>>>
>>> It does not do anything for running Windows applications on a Linux
>>> system.
>> 
>> Bluntly, you're long on opinion, but based on this and many
>> other answers in this newsgroup and others, I really don't think
>> you have a good handle on how any of the underlying technologies
>> actually work.  If you did, perhaps you wouldn't be so quick to
>> dismiss how a kernel compatibility layer that implements a
>> kernel ABI (e.g., WSL1) could be leveraged to gain insight into
>> how two kernel interfaces could be made to work simultaneously,
>> or how virtualization across a kernel boundary with shared
>> services (e.g., WSL2) could be similarly leveraged.
>
>I do find it difficult to see why running Linux apps
>on Windows help with running Windows apps on Linux.

Yes, you do, but it's not that complex.  If you have to provide
compatibility for one system interface in terms of another, you
must necessarily understand what can be shared and how to share
it.  Implementing the Linux system interface inside of the
Windows kernel (as one does with WSL1) gives MSFT engineers
insight into how to bridge between the two; if you do so in one
direction, you've necessarily learned a lot about how to do it
in the other direction.  I'm sure in doing so, Microsoft also
took lessons from e.g. gVisor etc.

Of course, the issue of system interface fidelity is a big one,
which is why WSL2 simply boots the Linux kernel in a VM.  But
if you do that, then conceptually you have two kernels running
in an orchestrated way on a single machine, and now you can
start to vary the interface between them and which takes
primacy.  This allows you to transition from one to the other
in a principled way, while maintaining compatibility.

Note that the Windows API is, by design, opaque to application
programs: programs like with a DLL that interfaces with the
kernel as opposed to publishing how to do this directly (as
under Linux).  This gives MSFT a lot of room in how they
implement their system while maintaining backwards compatibility
with application programs.  There's nothing magical about the
Windows kernel that would preclude them providing the same
interface on a different kernel entirely, and there's lots of
prior art (e.g., plan 9 ports, Rosetta and the Mac and A/UX
on the Mac, even within Windows, etc).

I do not expect you to understand this.

>And they have known about both concepts for a long
>time. WSL1 concept goes back to 90's - Win32 API on
>top of NT kernel and Win9x kernel.

Not really, but the basic concept of emulating a system
interface on another system goes much further back than
that; e.g., PA1050 on TOPS-20, or the DTSS environment on
Multics.

	- Dan C.