Clarifying my earlier comment, I agree 100% with this:
…and with the reasoning.
It can have applications beyond mere printers though - software for use of industrial and laboratory equipment is one case where security can be extremely important, and where Qubes is relevant (i.e. I have seen it being tested or used, to some extent)
I agree with your assessment that W11 will be the system that has the most users in need of Qubes. So the rational consequence is to put the main effort into providing QWT for this system, especially as the available resources for development are limited.
However, I would like to put the attention to the fact that the requirements for running W11 and for getting updates for that system are constantly changing. So the configurations allowed for that system were changed for 24H2 and now again. Installing W11 requires some tricks that changed somewhat in the past and always were documented only outside the official Microsoft texts and possibly were not quite legal. So far, there has always been some way to do it, but there is no guarantee that Microsoft will not close these holes sometime in the future.
For this reason, I think it would be wise to have at least a concept of what to do in such a case. This is a difficult problem, and I am afraid that I have no solution to it as it depends on the unpredictable actions of the manufacturer. Maybe it is like bad weather: It may come, and you cannot do anything against it, but you should be somehow prepared for it. But How?
While I also believe W11 should be top priority (and a very high priority), we have to take into consideration that many of the current systems in HCL might have been sold & shipped with a legitimate Windows 7 license. And as result of that, user will not have to pay additional licensing fee to Microsoft.
The other issue is even if 3rd party contributors want to help and assure QWT compatibility with Windows 7, signing it would require special developer contract which is additional cost burden to them, whereas Qubes project might have already paid for this license.
Could you please describe or explain a scenario, where Windows 7 within a VM(!) without PCI passthrough(!) and without networking(!) wouldn’t suffice? AFAIK it’s all “(universal) binary compatible”. I thought that as long as it’s all 64bit everything is fine and i always expected there is only one reason to run Windows within a qube: the need for a certain win32/win64 application that’s not available otherwise.
And on a side note: I don’t want to fight the arguments so far. I just want to understand.
For network, in my potential use-case of industrial and laboratory equipment I see -in the wild- isolated LANs where networking is essential for data management, but Windows versions even back to XP must be used.
Sometimes these systems are running under quite high security, where (for example) plugging an unapproved usb device causes network shutdown, HDD isolation, and possibly more in even more restrictive environments. I guess this is usually handled by commercial 'endpoint protection ’ systems, but after the Crowdstrike shambles it seems like Qubes+AdminVM could be quite relevant. Other solutions use fully air gapped legacy hardware/OS/software, with EVERYTHING being transferred by approved-only USB, which could equally be done inside the Qubes model.
(However, I doubt any of this is likely to be mainstream for Qubes or for any significant sponsor.
Precious resources should surely be concentrated on the main application areas, not niche stuff like this, especially since PCI passthrough is such a problem, and I’m sure some or many applications in this particular niche would sometimes require special hardware, 32-bit OS, or worse. Even the regularly reported healthcare organisations using ancient equipment and software systems seem an unlikely target market, given the number of existing players in that field.)
The use cases you describe here may no be a big number, but they are high-profile cases from areas where security is really important. So, leaving such users standing in the rain might not ne good for Qubes’ image.
I should clarify: I have only seen one case where Qubes was in use - and I do not know whether it was more than a local test. So these are only potential users.
I’m not in infosec, so I’ve observed a limited number of other sites, mostly using Symantec etc, a few with apparently home-grown solutions, sometimes looking quite insecure to a careless usb insertion.
Resources are limited. QWT is even now in alpha stage only. Priority should be directed towards Windows 11 & future only.
Qubes is just not about Windows, so developments in Qubes per se is much more important than QWT.
I am not saying that it shouldn’t be done but with so sluggish development, better to look for future only than past.
Some additional notes as a 3rd party contributor with some minor contributions to Qubes OS project. The system I have allocated for Qubes OS contribution (HP Elitebook 820 G1, 256GB SSD, 16GB RAM) is neither licensed (as seen in the picture below), nor practically capable to run Windows 11 HVM at a workable speed and conditions. And indeed I had to wipe two Windows 11 Preview qubes I had for testing purposes to make room for other work (each W11 installation requires 64GB of HDD space vs 16GB for W7). If I am left with a choice of running Windows 7 only as HVM without QWT support, then I guess I have no reason to look at QWT code (maybe only brief look for weekly newsletters). While I have never contributed specifically to QWT development, other independent 3rd party previous contributors to QWT might have some opinion about dumping QWT support for Windows 7 (or Windows 8 & Windows 10). I guess consulting them might not be a bad idea.
I am sure I don’t understand what is said here, but I’m using and fully deploying win11 with full qwt v4.1.69 under Qubes 4.2.4. At some point, probably around v4.2.3 my old full qwt VMs restored from v4.1 started to work under 4.2… So it was some Qubes update that made environment for them to work again.
So far, I have checked QWT under W11 only for Qubes R4.2.3. I’ll repeat that once I have enough disk space under R4.2.4.
But my Windows workhorse is still W7 because some crucial software won’t run under W10 or W11. Under Qubes R4.2, W7 still has some problems that make it useless for me: Seamless mode is not available due to the incompatibility of the Qubes graphics driver, and the still unresolved issue #8328 destroys the VM’s menu items, denying access to the applications in W7.
Some more information on the new apha version of QWT under W11 23H2: When I try to start the qubesDB-daemon manually, I get a Windows error message 0x00000428, telling that C:\Windows\SYSTEM32\xencontrol.dll is incompatible with Windows or faulty. This blocks the start of the Qubes services and forces to abort the QWT installation.
Setting testsigning on fixes this error and allows the installation to complete. The resulting systems is comparable to W10: I comes up with a wrong screen resolution, which has to be corrected manually. Setting the VM to seamless mode works, buts results in an unusable menu structure. Removing seamless mode crashes the Qube Manager and lets the VM disappear completely, so that it can only be shut down or even needs to be killed.
On my system, msmperng.exe is not running, and it is still unbearably slow, even with 8 GiB of memory. I guess that’s just one of the wonders of Windows - why I have switched everything possible to Linus.
Maybe I did something wrong, but I simply moved my windows 7 pro SP1 qubes (template and appvm) over to 4.2 from 4.1. They function. They’re not great but I can tether my camera, which is pretty much the only thing I do with Windows any more. (There are a couple of applications I also have no Linux equivalent for, but I’ve not actually used them in a couple of years.)