VM's should be allowed

[Alex-Genovese]

I wanted to test how a program that I have written might work with Nitrux.

I got the message that Virtual machines might not work too well. Also the bit about Spice and drivers .

But, the thing is, I was using SDL not Spice, and the VM system that I use allows drivers to be be side loaded ...

So, Nitrux shut me down and I wasn't even allowed to see if I could get the OS to work.

I think there should be a 'continue anyway' option. If there's not, how can anyone even try to check if new programs will work.

[UriHerrera]

The policy exists because of historical precedent.

• VMs without UEFI boot. Instead of correcting the settings, people would blame Nitrux.
• VMs with sub-optimal hardware configurations. Despite our detailed recommendations, instead of correcting the settings, people would blame Nitrux.
• KWin Wayland (back then) and now Hyprland do not play well with VMs, especially if 3D acceleration isn't enabled. Instead of correcting the settings or acknowledging the limitations (e.g., graphical glitches and severely reduced performance), people would blame Nitrux.
• Unnecessary maintenance burden in the case of Hyper-V support for an edge case that Nitrux evidently wasn't targeting.

A "continue anyway" option does not solve the issue, because the problem is not there.

That said, you can continue using it. However, the policy regarding using Nitrux as a guest OS in a VM will not change.

[Alex-Genovese]

@UriHerrera thanks for commenting. Very detailed but I was hoping for a more flexible stance, I have to say.

A "continue anyway" option does not solve the issue, because the problem is not there.

Sorry to disagree but currently, there is a problem, otherwise I wouldn't have raised it for discussion.

That said, you can continue using it.

Well, I made the effort and looked again. Instead of clicking the 'ok' button on the 'Nitrux is going to reboot now' dialog, I sidestepped to workspace two and left the shutdown dialog still open. That kind of worked but that then meant that there weren't any installer options ....

However, the policy regarding using Nitrux as a guest OS in a VM will not change.

Then I suppose that I will have to change instead?

• I will have to add comments on qqX, the Virtual Machine Manager that I maintain, on the Nitrux auto-download page

• I will have to forget about testing any software that I have written on your OS

This is all a bit of a pity as Nitrux seems to be quite an interesting project:

[UriHerrera]

I'll explain it better.

By saying, "A 'continue anyway’ option does not solve the issue, because the problem is not there," I meant that adding such a button would inevitably bring back the blame loop.

People will scan the screen, see the immediate exit option, and may not read the dialog's policy text. They will use the distribution, hit the limits of software virtualization, and instead of understanding those limits, blame Nitrux because it is the system they are using.

This is based on predictable user behavior. I have seen it happen repeatedly over the past ten years, and I would prefer not to take on that mental burden again.

Regarding your question:

Then I suppose that I will have to change instead?

No. You do not need to change anything in qqX's code. The workaround you found lets you keep using it. You can add a footnote in your docs.

However, I want to clarify that the dialog does not hide or block the Nitrux installation.

The Live session has no desktop icons because Hyprpaper does not provide that functionality. Calamares also won't launch automatically, whether it's a VM or bare-metal.

You can install Nitrux by launching Calamares from the Vicinae launcher. Vicinae is accessible from Valenz, at the top, by clicking the magnifying-glass icon or using the shortcut SUPER + R :

• Documentation → Workspace and UX → Workspace Defaults → Valenz
• Documentation → Workspace and UX → Workspace Defaults → Vicinae

Typing "install" brings up the installer entry in the Live session; hit Enter or double-left-click the result.