Products > Programming

Client X-Window Desktop Manager

<< < (5/6) > >>

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:

--- Quote from: newbrain on October 29, 2021, 06:22:27 am ---But I hope you agree that the wine analogy was quite misleading, and easy to understand as a WSL1 reference.
--- End quote ---
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.)


--- Quote from: newbrain on October 29, 2021, 06:22:27 am ---I was honestly surprised you could have missed WSL2!
--- End quote ---
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.)

dunkemhigh:

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

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:

--- Quote from: dunkemhigh on October 29, 2021, 10:16:34 pm ---
--- Quote ---If I wanted to run Windows stuff, I would definitely use a VM, instead of relying on Wine.
--- End quote ---
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.
--- End quote ---
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.


--- Quote from: dunkemhigh on October 29, 2021, 10:16:34 pm ---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.
--- End quote ---
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.

dunkemhigh:

--- Quote ---When I start a VM, I start from a snapshot
--- End quote ---

Conversely, I don't :)


--- Quote --- My VMs never boot/shutdown/reboot
--- End quote ---

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.


--- Quote ---The cost is disk space.
--- End quote ---

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.


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

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

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