EEVblog Electronics Community Forum

Products => Computers => Programming => Topic started by: blacksheeplogic on October 23, 2021, 10:57:08 pm

Title: Client X-Window Desktop Manager
Post by: blacksheeplogic on October 23, 2021, 10:57:08 pm
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.

Title: Re: Client X-Window Desktop Manager
Post by: langwadt on October 23, 2021, 11:05:47 pm
on win10 I use X410 and run an ubuntu in WSL
Title: Re: Client X-Window Desktop Manager
Post by: newbrain on October 24, 2021, 08:49:44 am
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 (https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-apps), 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.
Title: Re: Client X-Window Desktop Manager
Post by: udok on October 24, 2021, 12:09:42 pm
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/
Title: Re: Client X-Window Desktop Manager
Post by: tunk on October 24, 2021, 12:28:46 pm
You mention Cygwin, does that include Cygwin/X: https://x.cygwin.com/
Title: Re: Client X-Window Desktop Manager
Post by: nightfire on October 24, 2021, 02:07:54 pm
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.
Title: Re: Client X-Window Desktop Manager
Post by: tunk on October 24, 2021, 03:40:21 pm
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"
Title: Re: Client X-Window Desktop Manager
Post by: newbrain on October 24, 2021, 04:18:27 pm
[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.
Title: Re: Client X-Window Desktop Manager
Post by: PlainName on October 24, 2021, 06:01:02 pm
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.
Title: Re: Client X-Window Desktop Manager
Post by: blacksheeplogic on October 24, 2021, 11:46:42 pm
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.
Title: Re: Client X-Window Desktop Manager
Post by: blacksheeplogic on October 24, 2021, 11:55:27 pm
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.
Title: Re: Client X-Window Desktop Manager
Post by: newbrain on October 25, 2021, 07:52:48 am
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 (https://docs.microsoft.com/en-us/windows/wsl/build-custom-distro).

Using VS Code running in Windows, it's possible to develop, compile and debug directly in WSL (https://code.visualstudio.com/docs/remote/wsl).
The new terminal app (https://www.microsoft.com/en-us/p/windows-terminal/9n0dx20hk701#activetab=pivot:overviewtab) 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.
Title: Re: Client X-Window Desktop Manager
Post by: blacksheeplogic on October 26, 2021, 04:35:57 am
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 (https://docs.microsoft.com/en-us/windows/wsl/build-custom-distro).

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.
Title: Re: Client X-Window Desktop Manager
Post by: PKTKS on October 26, 2021, 08:14:19 am
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
Title: Re: Client X-Window Desktop Manager
Post by: Nominal Animal on October 27, 2021, 07:41:56 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.
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.)
Title: Re: Client X-Window Desktop Manager
Post by: blacksheeplogic on October 28, 2021, 03:46:14 am
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.

Title: Re: Client X-Window Desktop Manager
Post by: Nominal Animal on October 28, 2021, 04:20:53 am
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.)
Title: Re: Client X-Window Desktop Manager
Post by: newbrain on October 28, 2021, 01:48:40 pm
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 (https://docs.microsoft.com/en-us/windows/wsl/compare-versions) 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
Title: Re: Client X-Window Desktop Manager
Post by: Nominal Animal on October 28, 2021, 03:49:34 pm
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 (https://docs.microsoft.com/en-us/windows/wsl/compare-versions) 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) (https://www.man7.org/linux/man-pages/man3/getaddrinfo.3.html) 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 (https://github.com/microsoft/WSL/issues/6051) is an exact match (and underlying cause is #5806 (https://github.com/microsoft/WSL/issues/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 (https://www.man7.org/linux/man-pages/man3/getaddrinfo.3.html)) 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 (https://github.com/microsoft/WSL/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 (https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish), 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.
Title: Re: Client X-Window Desktop Manager
Post by: newbrain on October 29, 2021, 06:22:27 am
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!
Title: Re: Client X-Window Desktop Manager
Post by: blacksheeplogic on October 29, 2021, 08:23:30 am
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.

Title: Re: Client X-Window Desktop Manager
Post by: Nominal Animal on October 29, 2021, 07:02:28 pm
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.)
Title: Re: Client X-Window Desktop Manager
Post by: PlainName 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.

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 :)
Title: Re: Client X-Window Desktop Manager
Post by: Nominal Animal on October 29, 2021, 10:42:48 pm
Quote
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.
Title: Re: Client X-Window Desktop Manager
Post by: PlainName on October 29, 2021, 11:24:34 pm
Quote
When I start a VM, I start from a snapshot

Conversely, I don't :)

Quote
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.

Quote
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.

Quote
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.
Title: Re: Client X-Window Desktop Manager
Post by: blacksheeplogic on October 30, 2021, 12:28:47 am
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.

And that makes sense, if you need the other OS and don't have the HW allocated a VM is perfectly reasonable.

But what I find interesting are WSL applications mascaraing as Windows applications. Why is it better to have the overhead of a VM than a native Windows app? I get the reverse where the majority market is Windows so using a VM layer is a quick and dirty 'we are Linux as well'. It's mind blowing to think about the cavalier attitude to system resources when I think back to the systems I started out on.
Title: Re: Client X-Window Desktop Manager
Post by: Nominal Animal on October 30, 2021, 07:00:54 pm
It's mind blowing to think about the cavalier attitude to system resources when I think back to the systems I started out on.
I agree, and that's one reason why I like using virtual machines.

Quote
When I start a VM, I start from a snapshot
Conversely, I don't :)
Quote
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.
I usually hibernate mine (suspend to disk, with power off).  But that has no impact on what you do with your VMs!

Checkpointing is not a feature the OS provides; it is a feature that naturally arises from virtualization.  The virtualized system is just not executed anymore, and its exact, complete state is stored on disk. When started from such a stored state, all the virtualized system notices is that clock skipped forwards a bit, and some of the open network connections may have timed out.

It also means that you really gain nothing by letting your virtual machines boot and shut down every time you use them, you are just wasting time and resources.  It is not any more reliable or robust or 'clean' than starting from a checkpoint.

(Fun fact: Linux does have a similar facility, checkpoint/restart (https://criu.org/Main_Page), that can freeze an application and store it on disk, and later restart it from the disk image; from the point of view of the application, all that happens is time skips forwards.)

If you consider such checkpointed virtualized systems, they provide the perfect mix of resource use and compatibility: the virtualized machine only runs when it is needed, but is exactly the real system –– well, except from virtualized hardware devices, like display drivers.

Quote
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.
Well, I don't use VMs to isolate a process, actually.  I rarely have more than one VM running at the time.

The reason I like WSL2 using a Linux kernel in a VM, is that I seriously doubt MS's technical capability and resources of maintaining a robust and complete emulation layer otherwise.  It is drudge work, not very interesting, and you'd have helluva time of actually retaining the developers capable of maintaining it.  At least with a VM'd kernel, that interface won't have the bugs that a plain library-like emulation layer would.  It is in many ways yes, it wastes resources, but that does not affect my opinion because I don't run Windows.

If you ask me, running an entire Linux distribution, checkpointed and not booted/shutdown every time it is used, would be better, because that way you have a real native environment without all that emulation, and the compatibility issues it inevitably causes.  Of course, that does not work for Microsoft due to business reasons: heck, many of their users might discover that they don't actually need Windows for anything.

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?
No, only storage space.  Typical serious VM images I use have 8 GiB to 16 GiB images, but those are sparse (i.e., only used chunks take actual storage space).  To do the stuff I want to do, I typically have about 256 GiB of unused disk space –– some things I play with take a lot of space, temporarily.

In essence, I need that storage space anyway.  When I use a VM –– that is, when a VM is running –– I use whatever that is that is in that VM, so the hardware resources (CPU, memory) is mostly used by that VM.  When the VM is not in use, it is stored in checkpoint state on disk, and only uses storage space, not CPU or RAM resources.
Title: Re: Client X-Window Desktop Manager
Post by: PlainName on October 30, 2021, 07:41:43 pm
Quote
Quote
Quote from: dunkemhigh on Today at 00:24:34

    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?

No, only storage space.

Er, that's what I was talking about there, storage space.

Quote
but those are sparse

VirtualBox supports sparse images (otherwise known as dynamic) but they only increase in size (up to the max you've set) unless you go around zeroing out sectors and then running arcane CLI commands. So if your VM is, say, 20GB allocated (reasonable for a no-frills basic W7 machine) and your process temporarily allocates 200GB, that's the new size of your VM.
Title: Re: Client X-Window Desktop Manager
Post by: Nominal Animal on October 30, 2021, 08:27:11 pm
Quote
No, only storage space.
Er, that's what I was talking about there, storage space.
Ah, okay.  To me, storage is not an expensive resource, given that I use so much of it anyway, at least temporarily.

VirtualBox supports sparse images (otherwise known as dynamic) but they only increase in size (up to the max you've set) unless you go around zeroing out sectors and then running arcane CLI commands.
Yeah, that is an user interface problem that should be fixed for sure.

I didn't think of that, because I don't mind the arcane CLI interfaces, as I do all sorts of similar CLI stuff every day anyway.