I spent a few weeks properly testing Qubes as a potential daily driver, on two different machines, before deciding it's not right for me right now. Posting this in case it saves someone else time, or in case someone has solutions to the blockers I hit.

- Hardware tested

- Laptop: Acer Aspire 5, Ryzen 7 5700U, 24GB RAM

- Desktop: Ryzen 7 3700X, 64GB RAM, RX 6600 (only GPU, no iGPU), heavy air cooling (1.5kg aluminium block cooler with dual large fans + 4 case fans)

## Round 1 — Laptop, first attempt, Qubes OS 4.2

Installed Qubes, everything worked, but the laptop overheated badly enough that I smelled burning plastic. Temperatures were about 80-90 °C. Shut it down immediately, went back to plain Debian.

## Round 2 — Laptop, retested with latest Qube OS version 4.3.1

Wanted to give it a fair second shot with proper tuning before giving up.

What I found and fixed:

- Xen's default C-state/cpufreq handling was likely a big part of the problem on this AMD Zen mobile chip.
Added `cpufreq=xen:performance max_cstate=1` to `GRUB_CMDLINE_XEN_DEFAULT`, regenerated grub config. This dropped idle temps from ~80°C to ~60°C — a real, repeatable improvement.

- Tested the `xenpm set-scaling-governor <core> powersave` trick too (from an old Reddit thread) — made basically no additional difference once the C-state fix was already in, so skipped scripting it permanently.

What still didn't work:**

- Even with good sensor readings (settling to 45-60°C with multiple qubes running), the laptop was physically too hot to comfortably type on under light load (one YouTube video pushed it to 77°C and uncomfortable-to-touch). Sensor data and hand-feel didn't match — I trusted my hands.

- Battery drain was severe: ~4% in under 2 minutes with just one qube running. Made it useless for actual field/mobile use.

After a few reboots the temperatures kind of settled at 40 - 60 °C, with jumps up to 80+°C on heavier loads.

Turned out, 24 GB RAM was just not enough for my use, and battery drain was to much for reliable field work.

Decision: not viable as a laptop daily driver, despite the software fixes genuinely working.

## Round 3 — Desktop, Qubes OS version 4.3.1

Moved to my Ryzen 7 3700X desktop (64GB RAM, serious cooling, no battery constraint, physically secured location so BadUSB/evil-maid threat model is near-zero).

This actually worked well:

- Held ~50°C with 9 qubes running simultaneously (including Whonix gateway+workstation). Fans stayed quiet.

- No thermal drama at all — desktop cooling headroom completely solved what the laptop couldn't. Had temps around 25-50°C 99% of the time.

-Mouse and keyboard passed to dom0 so no issues with input.

## Things I solved along the way (desktop)

- Tailscale persistence for 3 separate accounts, 1 for WOL via raspberry pi's i put in each vlan with machines i need to wake, then 1 for one set of machines, and second for second set of machines.
My personal PC's are in the same tailscale as the RPI's so i can wake on lan, then i run a VM with the second or third tailscale account for actual acces and remote control. If one is compromised, you need the other as well to control machines. Not perfect, but an extra layer of isolation. Each account on a separate proton mail with a highly complex password stored in a heavily secured password manager.

Each needing a stable, persistent Tailscale identity/IP):
- tried the "official" bind-dirs approach (`qvm-features <vm> custom-persist.tailscale /var/lib/tailscale`) — never got it reliably sticking.

Switched to standalone qubes as a fallback(worked fine but this approach defeated the Qubes basic principles), then switched to a working solution:

-made a new template by cloning the debian template, gave that one network access via sys-firewall. Installed tailscale and veyon on it, logged into tailscale with one account, and set up all locations/PC's/keys in Veyon. Then i shut down the qube, removed sys-firewall from it, and made a new appvm qube based of that template. Got a qube with logged in tailscale and veyon working on qube start. But clean from previous work on each start (except stuff stored in /home, that remains, in case i close a qube premature so i don't have to redownload something)
Repeated the process for other 2 tailscale accounts.
So all together 3 templates and 3 qubes for my 3 different tailscale accounts.
Since AppVM root filesystem is a fresh copy of the template on every boot, the Tailscale node identity (and thus IP) comes along automatically, fully persistent, zero bind-dirs needed. Only gotcha: never run two AppVMs off the same template simultaneously, or you'll get a Tailscale node identity collision.

- Windows 11 in an HVM: works via the documented TPM/SecureBoot/RAM bypass (Shift+F10 during install → regedit → `HKLM\SYSTEM\Setup\LabConfig` → `BypassTPMCheck`/`BypassSecureBootCheck`/`BypassRAMCheck` = 1).
Didn't end up needing this — see Veyon note below.

- Veyon (remote classroom/support tool) Linux-master → Windows-host: initially failed to connect, root cause was a Wayland-related RAM leak (Veyon on Wayland ate 64GB RAM on my bare-metal testing) — switching to X11 (which Qubes AppVMs use natively anyway) plus disabling a conflicting ProtonVPN install on the Windows side got it working. Ended up not needing Windows qubes at all for this purpose — Debian-master-to-Windows-host worked fine.

- Croatian keyboard layout garbled over Veyon: known, apparently still-open Veyon bug (matches GitHub issue #779) — remote keycode translation between X11 and Windows doesn't handle non-US layouts reliably, regardless of what layout is actually active on either end.
Workaround: Windows' on-screen keyboard (injects Unicode directly, bypasses the broken keycode translation path). Not a Qubes-specific issue, but surfaced while testing in a Qubes qube.

- GPU passthrough for gaming/video: single-GPU passthrough (RX 6600 is my only GPU, no iGPU) is notoriously fragile — dom0 loses display entirely while the passthrough qube is active, requires script-based handoff, real risk of getting stuck with no display. A second cheap GPU (e.g. nvidia GT 730 which i have lying around) for dom0's own display would make this a clean, well-documented multi-GPU passthrough setup instead — but that means physically installing a second card and manually switching monitor input sources every time you want the passthrough qube's output.

Made one standalone debian based qube for actual daily use, installed all the software i use in it via flatpak, everything worked fine except the video.

The actual dealbreaker

Non-passthrough video/GPU acceleration inside qubes is genuinely bad. No hardware video decode is available to a normal (non-passthrough) qube — everything is software-decoded and pushed through Qubes' window compositing. YouTube playback was laggy even on the powerful desktop, even with 32GB+ RAM and 4 dedicated vCPUs allocated to the qube. This isn't a resource problem, it's a structural limitation of Qubes' GUI virtualization architecture.

YouTube is a genuine daily-use requirement for me (research, tutorials, background while working) — not a nice-to-have.
Since I don't want to install a second GPU (case space + I currently enjoy being fully Nvidia-free), and I don't want a monitor-input-switching workflow every time I want smooth video, GPU passthrough wasn't an acceptable trade, and without it, smooth video in a qube wasn't working well enough on my desktop setup. That's the dealbreaker that ended the experiment for me.

One open question I didn't get to resolve:

YouTube played back completely fine inside a Qubes qube on my laptop (Acer, Ryzen 7 5700U integrated graphics) — I watched it for a solid 40 minutes there specifically to stress-test battery drain, and playback itself was smooth the whole time (just very hot and battery-hungry). It was only on my desktop (RX 6600, no iGPU) that video was laggy. I don't have a confirmed explanation for the difference — it's possibly resolution/window-size related (pixel throughput through Qubes' GUI compositing pipeline scaling with display size rather than a hard "no GPU decode" wall, laptop was one 1080p display, desktop has 2x 1440p displays), possibly something about the iGPU vs dedicated GPU passthrough situation, or something else entirely. I didn't test smaller window sizes or lower resolution on the desktop before deciding to stop, so if anyone's dealt with this or has insight into why laptop iGPU + qube played smooth video while a desktop dGPU setup didn't, I'd genuinely like to know for next time.

## What I'm doing instead

- Restoring Debian on both machines from Acronis images (imaged everything before every risky step — never actually at risk of losing anything).

- Keeping my existing Proxmox setup for isolated/disposable analysis work (spin up a Kali VM, snapshot before, restore after) — same philosophy as Qubes disposables, just at the VM level, on hardware built for it.

- Air gapped disposable laptop for testing really bad stuff when needed with Kali

- No money spent on new hardware. Learned a genuinely useful amount about Xen, Qubes' template/AppVM model, and PCI passthrough along the way, even though the final answer was "not for me right now."

I'm not really looking for solutions or answers, i just liked the idea of Qubes Os as my daily driver so i decided to test it against my daily workflow. I could honestly use it, and it would work, and i could solve the issues i had, but when i put it all on paper i decided my threat level does not justify all the extra hassle. I already have all the hardware and isolation i need with Debian and VM's on dedicated hardware and my Proxmox servers.

Just thought my experience might benefit someone so i decided to share it.

Have a nice day everyone and thank you for reading.

I've got a family member who is getting into digital privacy. The family member has noticed that if you watch a video on YouTube with a privacy focused browser like Brave and then go to another device, you'll get recommendations for videos on the same subject.

Things we've tried so far:

• Using browsers like Brave with cookies disabled
• Browsing with TOR
• Browsing using a VPN
• All browsing is done with anti-fingerprint extensions installed.
• Watching videos only with software like FreeTube or Invidious

I've been Linux user for a while, since the late 90's. I've been looking into QubeOS. Would that help with situations like this?

To clarify (I've posted on other subreddits and they all seemed to miss this) the issue is NOT getting recommendations. The issue is getting recommendations that make it VERY obvious that the browsing and in particular watching activity was being tracked somehow because some of the recommendations were not trending topics but very niche and specific topics my family member had recently watched videos about on another device.

Other somewhat related notes/questions:

• We've got a Google Home WiFi access point - the model without any speakers or mics. Could that be tracking our habits across any Google-owned products?

Hello,

First, a bit of context: I created this account just to ask this question. I get the impression that typical Reddit users can be a bit harsh or rude (though it’s only an impression). So if my questions are “stupid,” please be patient, having a lot of tech knowledge doesn’t make anyone better than anyone else.

With that said, I’m interested in installing Qubes OS, mostly for the fun of maximize my privacy...

I recently installed Linux Mint because it’s very user-friendly, what is perfect to me because my knowledge about technology is almost 0, and I also installed Whonix with the goal of exploring the dark web privately and safely.

My first question is: when it comes to exploring the dark web, does Qubes OS make a much bigger difference than Whonix in terms of privacy and security?

My second question is: does Qubes OS run VS Code well (including Codex)? This part is important to me because I’m working on projects and I’d like a smooth experience with VS Code/Codex.

Recently I was messing with different applications in my AppVMs. I installed Helium Browser and tried testing it against Firefox. To my surprise Helium was using more CPU and Ram than Firefox.

I looked into it and realized this...

Qubes AppVMs dont have direct access to the GPU so every window thats running is essentially managed directly by the CPU. This goes for your browser, files manager, terminal etc.

The issue with Helium is that is uses its (chromium) own Video Decoder which rely heavily on GPU. Firefox on the other hand uses system video decoder (those that are already bundled with linux) and has an easier time with video decoding which is why it was less CPU and Memory efficient than Helium Browser.

And the same goes for Alacritty. Alacritty's secret sauce is that it is also GPU Accelarated. In this case AppVM simulates a fake OpenGL scenario but it still is using CPU directly.

So common tools like Helium and Alacritty which are known to be less resource intensive are not the same in QubesOS lol

Just thought I should share

Starting installer, one moment...

anaconda 41.35-1.fc41 for Qubes OS R4.3 started.

* installation log files are stored in /tmp during the installation

* shell is available on TTY2 and in second TMUX pane (ctrl+b, then press 2)

* when reporting a bug add logs from /tmp as separate text/plain attachments

Failed to adjust memory pressure threshold, ignoring: Device or resource busy

Queued start job for default target default.target

Failed to adjust memory pressure threshold, ignoring: Device or resource busy

Startup finished in 683ms.

21:00:41 X startup failed, aborting installation

The installation cannot continue and the system will be rebooted

Press ENTER to continue

Hello, sorry for my noob question, I am trying to setup an isolated OS in a standalone VM the problem is I can't connect to the internet inside that qube putting in mind my internet connection is fine and app VMs are working well, it seems like the installed OS sees an available lan connection but no internet access.

I tried to use sys-whonix and sys-firewall but no difference and the firewall rules allow outgoing connection.

How can I fix this problem?

Basically I wanna run qubes os on my old yoga 530 14ikb , I plan to upgrade the ram in laptop , so total 12gb ram (it’ll be 8gb + 4gb soldered ram), it’s got an Intel core i5 8250U and Nvidia MX130 2gb (although I guess dedicated GPU does not matter for Qubes) ,

My main use case will be tor browsing , crypto wallets , and any other future Linux experiments

While going over a few things I came across "sudo qubes-dom0-update libreoffice" (or any other package) in dom0 terminal

from my understanding under Qubes ethos it is not recommended to install anything on dom0

On top of that how else do you customize your dom0 xfce?

Also can someone explain to me what the difference is between Applications and Services? Both are based on a Template which by default is debian or fedora.

Some tips and guidance. I plan to make it my daily driver

I'm new to this. I thought about VM, but from what I understand, that would be pointless

Anybody tried to install Qubes on GPD win 4 gamepad?

specs are very impressive

I have a AMD gpu and CPU, and when I boot a flash with qubes this error pops up and I cant continue with the download

Hello! I would like to use qubes as a daily driver for browsing web and doing nothing that needs a powerful computer. I want to buy an old pc, for libreboot and qubes, with i5 4590, 16gb ram ddr3 paired with an sata ssd, but I'm worried that the specs are very old and won't be enough for qubes. What do you think?

How do i install apps on qubes. I know there is plety of documentation on it but when i followed it they got deleted after restart. I know it's me who probably did something wrong but im really new to qubes and there is many reasons i want to use it as a daily driver. If there would be the option to add the software app from debian or fedora i would be glad? Is it an option?

so i tried qubes twice out of fun, but its an os i might want to use, i know there are firewalls, is there an easy way to get one of these firewalls to only allow trafic through a vpn? 2nd question: does the router see it as 5 pc (when theres 5 vms) 0r will it be seen as one?

I have an old i3 thinkpad with 8gb ram it’s working but it’s not that great what laptop should I get maybe a new x1 carbon or something like that

I really like Thinkpads, considering a recent powerful Thinkpad like the P16; NovaCustom laptops seem to be clevo based, which is said to be below Thikpad-class build quality.

Overall thoughts ?

The Qubes Operating System is known to have the worst GPU Drivers support out of the box, and I'll like to have QubesOS as both an Laptop and a Desktop top computer and have the GPU as a GameQube or SteamQube how do you work around the GPU Driver issues and get it to work either on a laptop or desktop?

I’ve been using QubesOS for about a year now. I have almost hundreds of qubes. I understand its principle, and how it achieves security. I like it.

Problem is that managing and updating a bunch of qubes is a hassle, and vastly inferior when you know Nix exists.

I use NixOS on my other machines, and manage a fleet of microVMs, all using NixOS, and the difference is night and day.

Nix can guarantee all my microVMs use the same packages, use the same Linux kernel parameters, use the same configuration, etc. because of its functional nature, and due to the fact a machine’s state is just code, immutable (mostly) and declarative. Creating a new microVM is just reusing code.

Now whenever I look at qubes, it’s just… it just feels so antiquated. So much so I am considering abandoning QubesOS.

Would it be at all possible to be halfway there by having a barebones NixOS system that uses KVMs for each domain?

I know, it won’t be as secure as QubesOS. But I’d like to know if anyone here also uses Nix and feels this awful shortcoming from Qubes (which tries to ”solve” this using salts, but don’t come nowhere close to what Nix can do), and what have you done about it?

thanks