Products > Programming

Client X-Window Desktop Manager

<< < (4/6) > >>

blacksheeplogic:

--- Quote from: Nominal Animal on October 27, 2021, 07:41:56 pm ---
--- Quote from: blacksheeplogic on October 23, 2021, 10:57:08 pm ---I want to run the client on my windows 10 workstation without running a Linux client in a VM, and I want to start the session by clicking a icon on the windows taskbar.
--- End quote ---
May I ask why not a VM?

--- End quote ---

I've had issues with using a VM especially after updates. It's is also not as convenient. Working on a PCIe driver generally I just need ssh. I just purchased a license for X-WIN32 and set up lightdm + xfce using XDMCP so I can get a remote desktop. In the past I've tried setting up a build environment with initvm but that was hours of pain going though examples and I never got a fully stable kernel.

I think it really depends on what you mainly work on and and know. Likewise, I keep hearing about WSL but I don't see the advantage of using WSL over GIT Bash, at least not for me. All I need are remote connections back to my Windows workstation so I can use what I already have on my desk.

Nominal Animal:

--- Quote from: blacksheeplogic on October 28, 2021, 03:46:14 am ---It's is also not as convenient. Working on a PCIe driver generally I just need ssh.
--- End quote ---
Yep, no argument from me.  I've often worked the same way, especially when developing web service backends.  (Some hate nano, but I used pine and then alpine for well over a decade, so the interface is comfy for me... and it performs OK when editing syntax-highlighted code over an SSH connection.)

newbrain:

--- Quote from: Nominal Animal on October 27, 2021, 07:41:56 pm ---WSL is an imperfect emulation layer.  (Just like Wine in Linux is an imperfect emulation layer for Windows.)

--- End quote ---
Not since WSL2 (available in W10 1903, and later) where it's a real VM running a real kernel that includes Microsoft patches to play nice(r) with the Hyper-V based hosting environment (something more with respect to the "regular" Hyper-V support that has been there since a long time):

--- Code: ---newbrain@MUON:~$ uname -a
Linux MUON 5.10.60.1-microsoft-standard-WSL2 #1 SMP Wed Aug 25 23:20:18 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
--- End code ---

Nominal Animal:

--- Quote from: newbrain on October 28, 2021, 01:48:40 pm ---
--- Quote from: Nominal Animal on October 27, 2021, 07:41:56 pm ---WSL is an imperfect emulation layer.  (Just like Wine in Linux is an imperfect emulation layer for Windows.)

--- End quote ---
Not since WSL2 (available in W10 1903, and later) where it's a real VM running a real kernel that includes Microsoft patches to play nice(r) with the Hyper-V based hosting environment (something more with respect to the "regular" Hyper-V support that has been there since a long time):

--- Code: ---newbrain@MUON:~$ uname -a
Linux MUON 5.10.60.1-microsoft-standard-WSL2 #1 SMP Wed Aug 25 23:20:18 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
--- End code ---

--- End quote ---
That is only the kernel, not the whole OS.  It still suffers from Microsoft bugs in the OS services that do not occur in "real" Linux distributions.
So, the "emulation layer" has shrunk significantly, and no longer refers to the kernel (which runs in a VM); the OS services like name resolution, are still emulated in WSL2.

One serious bug I was told about was that if you do getaddrinfo("server", "service", &hints, &results) in WSL, the resulting socket list contains not only the server and its aliases, but also the nameserver/authority records.  The example shown was baidu.com, for http, IIRC.

Since I cannot verify this for myself (as I don't have any MS Windows myself), I looked at the WSL github issues, and #6051 is an exact match (and underlying cause is #5806), both still open after a year.

I consider it a serious flaw, because it means the standard, recommended POSIX method of opening a connection to a given network host (as shown in the echo client-server example pair at end of man 3 getaddrinfo) will in some situations (when the actual server is unreachable/unconnectable and therefore the correct sockets skipped) try to connect to a completely wrong host!

Do not get me wrong: I do consider WSL and especially WSL2 a good idea, definitely.  It's just that there are still issues that do make it distinctively different, in some cases that may not affect all users or developers, than any other Linux distribution, so that applications and services still need WSL-specific workarounds to work correctly.  (This can raise the heckles of old-timers that still remember E-E-E, but I honestly don't believe it is the case at all here: to me, these are obviously "natural" bugs due to the "emulation" necessary.  But it's useful to know if someone experienced is very much against WSL, since once burned/fooled badly will avoid the cause even if the cause changes for the better.)

Testing stuff on an actual Linux distribution –– I'd suggest more than one! –– on a hardware or virtual machine is still required.  Maybe not for trivial programs, but for anything one intends to distribute to Linux users, I'd say.

newbrain:
In that light, you are of course correct.
There is a number of issues still to be solved.

But I hope you agree that the wine analogy was quite misleading, and easy to understand as a WSL1 reference.
I was honestly surprised you could have missed WSL2!

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version