Well, I managed to get 32-bit Gentoo running on a Raspberry Pi Zero W, so I guess anything is possible… (with only 500MHz to play with, emerges take DAYS, not hours…thank goodness for distcc 
)
If you want a challenge, then the ASUS ZenFone 2 is a potential candidate (it has an x86 CPU). Been trying to track one down to try it
Other than that, the Latte Panda SBCs would come close (mind you, without any RAM, you’d be stuck with only 1 AppVM open at a time…)
I split this because I realized it would be an interesting topic on its own.
The list of “obscure” hardware I’ve managed to get Qubes OS running on, in some form:
libxenlight didn’t play nice)
)Planned hardware (pending budgets)
The biggest headaches are:
RAM (or lack thereof)
Having 4GB of RAM means you can basically only run sys-net, sys-firewall, sys-whonix, and ONE AppVM at a time. It’s fun trying to do Template upgrades when you haven’t got enough RAM to start them! 
CPU vulnerabilities
I have spent weeks getting Qubes OS to boot to an XFCE desktop on certain machines, only to realise that the CPUs are vulnerable to Spectre and Meltdown (mostly because Intel just never released microcode that fixed the vulnerabilities). So, does it work? Why yes, indeed it does. Would I use it in any production environment? Probably not… 
Apple’s BIOS/EFI
(the thing that makes the hardware go “DUUUUUNNNNGGGG!!!” when you press the power button, whatever you want to call it)
Anyone who’s interacted with Apple devices knows that their bootloader is very picky. Getting Linux to boot on Apple hardware will usually involve “tricking” the Apple bootloader into thinking that it’s booting MacOS. The problem is, it will also grab some PCI devices (especially the wifi card), and refuse to let go, even after booting. This causes a massive kernel panic and system freeze (the cursor stops moving) if you try and pass it through to sys-net. It took me six months to find a workaround… Six months of a MacBook Air with no wifi… 
Hardware Circuitboard Design
(How the ports are connected and grouped together on the motherboard)
Apple hardware is particularly frustrating when trying to get Qubes OS to work. Because you have to pass through the entire PCI device, you have to give a VM everything that is on that PCI device. For most Apple hardware, the internal keyboard, trackpad, camera, and SD card reader will be hardwired on the same USB bus as one of the USB ports (or both of them). This means that if you try and pass a USB port to an AppVM (USB game controller, webcam, network adapter, or anything that isn’t a block device), you lose the internal keyboard and mouse as well . 
I’m sure there are other manufacturers that do this, too, though…
Qubes OS (currently) only runs on x86_64
I have no doubt that one day Qubes OS will run on other architectures (ARM 
, and I wish I could help out with that), but for now, you’re stuck on good ol’ x86.
On another note, this would be an interesting video series.
"Can it run Qubes OS? could become the new “Can it run Crysis?” 
I didn’t know what this was. Amazing looking system. How was rc1? Is this device susceptible to the Intel vulnerabilities you mentioned?
Ah, Apple and their extended dung. I remember it as a long dong. Apple lost their dong around the time Steve Jobs died, btw.
I remember there was talk somewhere about getting a bunch RPis to run a distributed version of Qubes.
Qubes running on Apple ARM hardware would be amazing.
This reminds me: with Intel introducing performance and efficiency cores into their x86 CPUs, and with this looking to be the norm from here on out, are there plans for Qubes to take advantage of this feature?
ALL x86 chips are vulnerable to SPECTRE and MELTDOWN on some level, unfortunately.
They don’t know all the vulnerabilities yet, because they’re still finding them (and fixing them as they find them, so no need to panic).
They don’t appear to be vulnerable to any of the CVEs logged so far, which is good.
Honestly, the only gripe I have with it is the fact that it’s got soldered RAM 
16GB is enough for laptop use, but I wish it was upgradeable. I wanted 64GB+ 
The BIOS can also be reflashed if you like (I’m still working out the specifics of this, but I’m sure someone out there in the world has already figured this out).
Other than that, Qubes OS does need a little tweaking to get some things to work (dom0 didn’t have alsa-sof-firmware installed, the display has a weird resolution you have to configure, etc.) but nothing too difficult if you’ve been in the Linux world for a while.
The main reasons for getting them were:
All models needed tweaking to get the display to work:
https://www.reddit.com/r/gpdwin/comments/ik3dje/gpd_win_max_display_fix_in_linux/
The AMD Ryzen 7 4800U model runs Qubes OS 4.1-rc1 great out of the box….so far….
The Intel i5-1035G7 model needed a few kernelopts passed to sys-net to get the wifi card to work, but everything else works great.
The Intel i7-1195G7 model needed the display rotated, as well as alsa-sof-firmware to be installed in dom0, and I’m also trying to fine-tune the display (and learning how to navigate xrandr as I go)…
There is a version of Xen that has been written for the Raspberry Pi 4, so there’s definitely progress being made.
That’s a really cool idea. OS developers having links to ISOs, VirtualBox images, and Qubes OS Templates in the Downloads section of their websites. Maybe one day…
I definitely know that a specialised version of Qubes OS that was basically like a server, and Qubes OS workstations would be able to host their qubes on that server, and they’d show up on their local Qubes OS machine like regular qubes; would get a lot of interest from the enterprise world.
I’d happily host one of those 
Xen might not even be necessary, since distributed Qubes wouldn’t need virtualization as intra-qubes communication would be handled via SSH (if I remember correctly). If RPi supports Xen, it wouldn’t hurt too much to add a layer of virtualization, I guess.
This gives me a half-baked idea though. What about Fractal Qubes? The basic idea is as follows: An internal, cloud-based Qubes, where the company’s entire infrastructure is hosted on one massive Qubes OS, which is then split into multiple smaller Xen instances, each its own Qubes OS. The admin Qubes of course has its own sys-net, sys-firewall, etc. to protect against compromised ‘branches’. Sysadmin becomes a breeze with Salt. Might be a boon for the project’s revenue generation.
Biggest weakness: Single point of failure (Xen), but that single point of failure isn’t too different from most (monoculture) networks?
Not technically-trained; consume with salt.
cloud-based Qubes
cloud = controlled by someone else – why would anyone want this?
cloud = infrastructure goes down, you go down
cloud = you own/control NOTHING!!!
… I don’t care how much snake oil one puts on this, it will NEVER be trustworthy.
Yeah, still. If you’re dealing with critical information, you probably don’t want any IT/IS guy in your org to have admin.
25+ years ago I was an intern at a large global company you would recognize. I was barely allowed to drive a car, but I had the admin password for the entire domain and every computer on it, the keys and combination to the safe room (backup tapes) and the access to the “shutdown the whole plant” button.
That was cool but even back then I also realized how absurd this was.
Here is it: Qubes Air: Generalizing the Qubes Architecture | Qubes OS.
It’s called Qubes Air (see above).
Unless it’s your own cloud of course. Let me quote Joanna:
Readers who are allergic to the notion of having their private computations running in the (untrusted) cloud should not give up reading just yet.
This, exactly. For everyday use, Qubes really needs 32GB of RAM or more. If GPD were to release a 32GB or RAM-socketed version, I’d be in.
B
I can’t speak for everyone, but for standard uses (multimedia + browsing + other non-compute activities), 16GB has served me well. I should note that I use minimal templates exclusively.
More ammo for the Debian crowd
Unless it’syour own cloud of course. Let me quote Joanna:
Readers who are allergic to the notion of having their private computations running in the (untrusted) cloud should not give up reading just yet.
…pretty sure I expressed my interest when the announcement was made. Having my own Pi’s or corebooted desktops hosting qubes … locked down, locked away and with temper detection.
When hearing “cloud” or “corporate install” I think of having someone else’s fingers in my stuff, which I solved by locking THEM into a qube. There THEY can administer/scan/monitor until the cow’s come home – I don’t care.
I have bad news to report. I have opened up the laptops and looked at the board, and discovered that GPD appears to have done the ol’ switcheroo on us. The original model (i5-1035G7) does have an Intel AX200 module soldered to its board, capable of Wi-Fi 6 (802.11ax).
However, despite every single piece of advertising I can find on GPD’s website, the 2021 models (i7-1195G7 and Ryzen 7 4800U) have an Intel 7265 module soldered on, only capable of 802.11ac.
They are still very good machines, however I am a little frustrated (actually, VERY frustrated) about this. It was one of the main reasons I went with them.
I cannot figure out why they would do this. Either they compromised due to pandemic manufacturing shortages, or they were dishonest. Either way, it kind of sucks… 
i’m perfectly comfortable with Wi-Fi 4 (802.11n) or lower (802.11b/n/g)
i never tried 5ghz Wi-Fi before and i rarely see anything with Wi-Fi 6 (802.11ax)
if this is my first time look at GPD, i’ll call it a scam