Client X-Window Desktop Manager

[blacksheeplogic]

In the past I have used exceed on Windows to connect to a Unix server and start a CDE session. I don't currently have exceed and I looked at cygwin but after several hours the simple task of connecting to a Linux server and starting a xfce client session, running xterm/xclock seems beyond it's capabilities.

I don't have a issue with purchasing a commercial license I just need something that works and is easy to configure. My basic requirement is to take a windows client app I have and work on the port to Linux. 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.

I'm interested in what people are using and how you configured both the Windows client and Linux server, not a list of 'possible' applications I could spend a week trying out.

[langwadt]

on win10 I use X410 and run an ubuntu in WSL

[newbrain]

Your goal is not 100% clear to me, so pardon me f I'm suggesting something that is not what you're after.

I think you're not after a complete X desktop environment though you mentioned CDE and xfce?
And you need to run the client on the same machine.

The shortest way to do that is using Windows 11 WSLg, it works out of the box and uses a light VM under the hood tunneling X11 request to Windows, without needing an X server on the Windows side. It can also use GPU for compute task (e.g. tensorflow) but not for graphic acceleration.

Install one of the available distributions and you are good to go. A regular Windows shortcut that launches the client can be created, look up the wsl.exe command.

Unfortunately this is not available for Windows 10, yet, possibly just behind the corner with 21H2.

In that case a X server on Windows is needed (I use vcxsrv) together with WSL, along with the usual contortios with DISPLAY and auth settings.

[udok]

In the past I have used exceed on Windows to connect to a Unix server and start a CDE session. I don't currently have exceed and I looked at cygwin but after several hours the simple task of connecting to a Linux server and starting a xfce client session, running xterm/xclock seems beyond it's capabilities.

I think that Cygwin has NO buildin X-Server.   So that will not work.

You must install a X-Server like https://sourceforge.net/projects/vcxsrv/

[tunk]

You mention Cygwin, does that include Cygwin/X: https://x.cygwin.com/

[nightfire]

I use https://mobaxterm.mobatek.net/
Works well with my FreeBSD box and under the same GUI I also have some contact management stuff for other SSH accounts etc.

[tunk]

Played a bit around with MobaXterm and it seems ok.
And looks like you can make a batch file like this to start an xterm:
\full\path\to\MobaXterm_Personal_21.4.exe -newtab "ssh -l usrname dns.or.ip.of.server"

[newbrain]

[blah blah]
It can also use GPU for compute task (e.g. tensorflow) but not for graphic acceleration.

I stand corrected. Just launched Furmark from GpuTest, and I'm impressed.

[PlainName]

If I understand your request correctly, you might like to look at x2go:

https://wiki.x2go.org/doku.php/doc:newtox2go

It uses the previously mentioned vcxsrv and works best for my requirements. Doesn't need installing and allows running of remote apps on the local desktop without the remote desktop.

[blacksheeplogic]

on win10 I use X410 and run an ubuntu in WSL

That's actually quite an interesting solution, had not considered  MS app for WSL.

[blacksheeplogic]

Your goal is not 100% clear to me, so pardon me f I'm suggesting something that is not what you're after.

I think you're not after a complete X desktop environment though you mentioned CDE and xfce?
And you need to run the client on the same machine.

Somewhat frustrated yesterday with cygwin/cygwin-x yesterday for what should have taken only a few minutes to set up. I'm used to using exceed. X410 was mentioned. I might purchase X-Win32 which looks like an alternative to exceed. I'm leaning towards X-Win32 as you can also purchase a support contract with it. I don't want to invest a lot of my time in tools.

[newbrain]

That's actually quite an interesting solution, had not considered  MS app for WSL.

WSL remains the easiest way to run user space Linux binaries on a Windows machine.

The limitations there is that USB devices access is limited (in WSL1, only USB serial) to non existent (in WSL2+ not even that without going though inanely complicated hoops).
Memory devices and disks can be shared/mounted.

The available distros are just a few, but if you are sufficiently determined, you can build your own.

Using VS Code running in Windows, it's possible to develop, compile and debug directly in WSL.
The new terminal app is (at last) a decent console/terminal emulation for working with command line programs (both Windows and WSL).

If graphics is needed, use one of the many X servers pointed at above (or native with W11/W10 insider).

An alternative that has not been proposed is using Docker for Windows, it will seamlessly start a (single) hidden VM to run Linux based images - but I have very little experience with it.

[blacksheeplogic]

That's actually quite an interesting solution, had not considered  MS app for WSL.

WSL remains the easiest way to run user space Linux binaries on a Windows machine.

The available distros are just a few, but if you are sufficiently determined, you can build your own.

Thanks for your help.

No real experience with WSL, I have created a custom Debien kernel for the Cyclone V SOC's I am using, and I also have a UBUNTU Kernel I for building my PCIe Driver against. Getting a kernel is not the problem.

Where I run into issues is with the run of the mill environment set up. There's no clear documentation I found on getting XFCE4 to listen for XDMCP and start a session, There are notes on using SSH forwarding but I should not have to do this. I'm not sold on RDP but I know that is an option but I would prefer XDMCP because I'm old and that's what I have used in the past.

[PKTKS]

Back in 2000s i had to deal with a similar issues...

I usually save my system images just in case of some tragic typical windooze events happen and they do happen a lot

The solution has no problems once you can open a cygwin server.. start a ssh session for your remote host using X11 protocol forwarding

I will see if i can find the legacy image to boot it in a vm.. if all goes well even a legacy crap like that should still do the trick...

Ssh port forward will open a dedicated tunnel for your remote clients...

Give me some time may be i can post a vintage screenshot. 

So this WSL   sick  aberration is not even relevant as it never was

Paul

[Nominal Animal]

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.

May I ask why not a VM?

I'm genuinely interested, because I myself use a lot of VMs to test stuff on various Linux distros, including things like package portability across Debian variants.  The main issue is storage space and speed, for which I do recommend a separate fast NVMe (I'm looking at Samsung 980 Pro now myself), and secondary issue is available RAM (especially if compiling stuff); even a single-core VM seems to run very nicely if the storage and RAM are sufficient.  I often share the source directory if I'm editing the code, but compiling and running it in the VM.  The nice thing in that scenario is VM checkpointing: essentially, before I (install and) run the compiled binaries, I first revert to a fixed VM checkpoint/state.  This way even if the test crashes the VM, I can instantly revert it to the known working state.  Even if it does not crash, after exiting the binaries, I always revert to the known working state: that way I can be absolutely sure the execution environment is pristine every single time.  This applies to kernel module development, too, which is particularly nice in my opinion.

Please do note that even if the binary runs in Windows under WSL, it does not necessarily mean it runs fine in Linux also, because WSL is an imperfect emulation layer.  (Just like Wine in Linux is an imperfect emulation layer for Windows.)  Usually it does work, and for development, it might suffice.  You do need to do at least testing on actual Linux installations, though.  You should absolutely not rely on developing on Windows and assume the result must be fine on Linux too because you used WSL.  (Again, the exact same applies to developing for Windows on Linux.  This is not some kind of ideological purism, just a practical fact regardless of the OSes and emulation layers used.)

[blacksheeplogic]

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.

May I ask why not a VM?

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]

It's is also not as convenient. Working on a PCIe driver generally I just need ssh.

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]

WSL is an imperfect emulation layer.  (Just like Wine in Linux is an imperfect emulation layer for Windows.)

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: [Select]

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

[Nominal Animal]

WSL is an imperfect emulation layer.  (Just like Wine in Linux is an imperfect emulation layer for Windows.)

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: [Select]

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

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!

[blacksheeplogic]

This might seem trivial but the documentation was a little obtuse: /usr/share/doc/lightdm/lightdm.conf

The minimum needed for XDMCP:

Check which dm is current (lightdm for example)
   systemctl status display-manager

lightdm, do the following

/etc/lightdm/lightdm.conf
   [Seat:*]
   xserver-allow-tcp=true
   xserver-share=true
   xdmcp-port=177
   greeter-show-remote-login=true

   [XDMCPServer]
   enabled=true
   port=177

service lightdm restart
cat /var/log/lightdm/lightdm.log

gdm/kdm are the same except their configs are under their respective display managers.

[Nominal Animal]

But I hope you agree that the wine analogy was quite misleading, and easy to understand as a WSL1 reference.

Is it?  I mean, WSL2 does run the Linux kernel in a VM, letting the kernel interact with Windows using various protocols, so technically a large part of WSL is a genuine Linux kernel.  But, the kernel is not the same as the OS.  For example, Android is not Linux, even though both run the Linux kernel.  WSL2 still largely relies on emulation.

I genuinely can't really decide right now whether I agree that the analogy was misleading.  Seeing it as a WSL1 reference, sure.

WSL1 and Wine were much closer, technically, that's for sure.  But does it make the analog fail, if one moves from a library layer that maps syscalls from one to the syscalls of the other, into running the core kernel in a VM, with that VM'd kernel talking to the host kernel via hypervisor services?  Considering that all the userspace support libraries and services are still emulated, provided by custom code designed for exactly this purpose?

(In other words, if you do see it as misleading, I have no counterargument; I just am not certain if the differences are large enough to call the analog misleading.  But, as usual, I am often wrong anyway.)

I was honestly surprised you could have missed WSL2!

Like I said, I don't personally use Windows at all, and although I had heard that a new version of WSL had come out a year or two back (had to check; WSL2 was announced in May 2019), I haven't had any reason to check what the differences were.  The reports of incompatibilities I've heard about (nginx config and getaddrinfo() immediately come to mind) didn't really specify version either (they just say WSL, not WSL1/WSL2), and the same seem to still be an issue a year later.

The move in WSL2 for running a Linux kernel, does eliminate all kernel incompatibilities, so I do wholeheartedly agree that it is a leap forwards, a good thing.  I was positively surprised to find out it was implemented that way!

But, the compatibility problems still exist.  If you run the kernel in a VM, why not the entire OS?  Modifying an accelerated Xorg server to use the Windows graphics subsystem should be less work than all this library and service level stuff, methinks (so that the VM'd applications would appear just like native Windows applications, perhaps with trivial native Windows process handles/placeholders/agents for Windows interprocess comms).  That's what the existing X11 clients for Windows do for remote X11 connections, already.

If I wanted to run Windows stuff, I would definitely use a VM, instead of relying on Wine.  I've done both, and the VM is more powerful, and does not really have any of the compatibility issues Wine has.  (Plus, checkpointing: you can experiment with stuff, even install software you may wish to get completely rid of.  Instead of uninstalling, reverting the VM to a previous checkpoint reverts everything.  I can warmly recommend this, be it with Linux, Windows, or any other OS.)

[PlainName]

If I wanted to run Windows stuff, I would definitely use a VM, instead of relying on Wine.

I wouldn't. With the VM it's like starting your computer up just to run calculator or something, then shutting it down until you want to run that app again and waiting for the cold boot to happen again. And it's taking up huge resources to do that. Plus it's a remote machine so the local resources are meaningless to it.

The only reason I would run a VM normally (as opposed to irregular stuff) would be to run OtherOS instead of whatever this host it. That is, safer and simpler than doing dual-boot.

But that's just my opinion. YMMV, obviously

[Nominal Animal]

If I wanted to run Windows stuff, I would definitely use a VM, instead of relying on Wine.

I wouldn't. With the VM it's like starting your computer up just to run calculator or something, then shutting it down until you want to run that app again and waiting for the cold boot to happen again. And it's taking up huge resources to do that. Plus it's a remote machine so the local resources are meaningless to it.

What?  I genuinely do not understand.  That is definitely not the case when I use VMs.

When I start a VM, I start from a snapshot; it's faster than even waking from hibernation, and takes less than a second.  (On NVMe, it's pretty near instant.)  If I made any changes I want to keep, I do a new snapshot (and delete an old one to save disk space).  If I didn't, I'll revert the VM to a previous state.  My VMs never boot/shutdown/reboot, unless I do updates that need it, and I want to move to a post-update snapshot.

The cost is disk space.  CPU is only used when the VM is running; a snapshot contains the complete state of the VM at the time of the snapshot.  I do not understand your "huge resources" to "cold boot" at all.

The only reason I would run a VM normally (as opposed to irregular stuff) would be to run OtherOS instead of whatever this host it. That is, safer and simpler than doing dual-boot.

Ah, but Windows is OtherOS to me.  In the post you quoted, I did say I don't use Windows at all.  I know, I'm too verbose.

[PlainName]

When I start a VM, I start from a snapshot

Conversely, I don't

My VMs never boot/shutdown/reboot

Mine do, so I know they are starting clean. But I shut down my PC every night (or morning, as the case may be) and I understand that's not common nowadays.

The cost is disk space.

Which is not insignificant. And since one reason for using a VM is to isolate some process, one tends to end up with several to many VMs since there is never one process. Which is not to mention that if it's a serious VM then it would take up the same amount of space as one's working machine. That would double the resources, would it not?

Then we're also into RAM, processor cycles, communications, etc. It is not resource free, and whether or not that means it's significant would depend on the particular circumstances.

Ah, but Windows is OtherOS to me.  In the post you quoted, I did say I don't use Windows at all.

Well, yes, that hadn't escaped me. If nothing else, the possibility of running Wine might have been a clue! However, I used 'OtherOS' the be host and VM agnostic. I use Windows, so 'OtherOS' might be Linux, but it could easily be Windows if I chose to use Linux as a host.