QubesOS usability

Hi! I’ve been wondering about how usable is QubesOS. Basically, 1) the level of technical expertise needed to run it as a daily driver and 2) its reliability in professional use (how many bugs should I expect). I see a lot of different opinions about this online, so I would appreciate unbiased (as much as possible) input from someone that has previously used it or is at least somewhat familiar with it

I have the experience of writing organization-specific documentation for Qubes OS before.

Usability will be difficult, but I think the tradeoffs are worth it. The main issues I encountered are implementing and updating proprietary apps like Zoom and Slack in professional workflows. You’re going to need to install these apps in a template dedicated for work-purposes and then open them in a disposable qube. The easiest method for newbies would be something like flatpacks, but security implications behind community-maintained flatpacks do exist.

Copying + pasting is something to get used to. I usually create customized shortcuts to do so across different VMs which are much easier than the default shortcuts.

There might be occasional issues with screensharing but I haven’t really tested this out on my end.

For most professionals, MS Teams and Google Meets can be done over the browser. Signal also works as well. You just need to become familiar with how Qubes treats installation on templates.

What are the “professional” usage cases for you? Are there any apps you need to install?

1 Like

Thanks for your input. I’m thinking about using it in my own clinic. The only apps I need are a browser for keeping up to date with my discipline, and an office suite (like going to use libreoffice). It might be nice to have Whatsapp and Telegram (what most people use) + Zoom, but it’s not necessary as I’m fine using them on my phone.

What I was wondering about is reliability. Should I expect to find my setup broken on some days? Would an update need me to spend time troubleshooting my system? This kind of thing

I was thinking, what about using secureblue? Unless you wanna stick to qubes which is fine.
But for my future business I’m honestly more thinking about secureblue so.

2 Likes

Unless you modify dom0 , which handles the core functionality of Qubes, there shouldn’t be much issues with reliability. Of course, I can’t really attest to this as I’m not a regular qubes user anymore.

I always wondered if Secureblue could work as a template…it would be fun to test it out!

@anonfox You may want to test both Qubes or Secureblue out to see if one works better for your workflow over the other. Secureblue is a new project with limited resources, so keep that in mind if you’re worried about bugs. To give them credit, most of the underlying work is already done through Silverblue so it is not a significant drawback (and its even more stable because of immutability regardless).

On the other hand, Qubes has a large team and significant funding. The usability gap is huge though.

2 Likes

I’ve put Fedora in my spouse’s laptop for work purely for typing. It works and quickly gets out of the way.

I imagine dealing with VMs has to take some productivity hit with it being a bit finicky each runtime. You will always be fiddling with it everyday costing a few minutes to let it fully boot up to your actual workflow. There is also a hit in productivity each time you do task switching because typically a browsing profile should not be the same profile as your actual work profile and there is a delay when you switch VMs.

You need to weigh these delays that will cause productivity problems. See if it is worth it against your actual threat model - and think that Qubes is meant to fully trust the user and distrust the hardware - the complete opposite of what computing traditionally is. If this is a good fit, then go.

In my mind, a typical issue for offices/clinics is data loss via catastrophic hardware failure - you should have that 3-2-1 backup really up as a priority before tackling the issue of whether to use Qubes or not. Next comes theft - solved by full disk encryption. Finally malware and ransomware is the dreaded problem. With the more recent news cycle regarding ransomware, social engineering become the target for these and with the Qubes model, a compromised user, through social engineering, can fully bypass Qubes’ protection - remember that Qubes protects you from a malicious machine, not a user made unintentionally malicious via social engineering. These are solved by employee phishing training.

TLDR: Qubes may be overkill for you. Better do fundamentals: backup, full disk encryption and phishing avoidance training.

2 Likes

It’s being considered.

Thanks a lot everyone for the input. I’m honestly aware than QubesOS is likely an overkill for me, but I like security, just as a personal preference. My threat model is that as long as something increases security against remote exploitation (physical security is not a huge deal for me beyond basics) and privacy (not anonymity though), I’ll try to use it as long as the usability hit is not too great. I’ll keep thinking about whether QubesOS is compatible with this model. Thanks again everyone.

until then. What about trying secureblue itself anyways.

Secureblue is nice. I’m using it on my current laptop. Thanks for the suggestion.

I’ve installed it on my test PC recently and was able to install Mullvad by following their instructions.

I would love to use it more often, but YouTube videos are very laggy. I don’t know if I have to create a new Qube with GPU passthrough or if it’s because of my hardware or if that’s just how it is.

I’ve also ran into audio issues where it would work on one Qube, but when I use a different Qube and tried to switch the audio output to that Qube, it doesn’t work.

I would say there’s a lot of configurations you would have to do before starting to use Qubes as a daily driver. Other Linux distros that I’ve tried Ubuntu, Fedora, Kicksecure pretty much works ootb.

Before I start, I just want to clarify that the following comment is absolutely not meant as an attack on anyone who experiences issues with Qubes. In my experience, however, problems often arise from misunderstandings about how Qubes works and sometimes from not carefully consulting the documentation.

It sounds as though you were forced by Qubes to run these applications in a disposable qube rather than by doing it by choice. If I understood you correctly, this step should not have been necessary.

GPU passthrough should definitely not be necessary for this, it should work fine out of the box. Feel free to seek help in the Qubes Forum.

Switching your audio output manually should also not be necessary, as dom0 is configured as your audiovm by default.

I re-installed Qubes on my main PC over the weekend. Previously, I installed it on my test PC to test if it’s a viable OS for me, but the CPU was crap, so that’s what caused the video lag. On my main PC, playback is not as smooth compare to Ubuntu (and it is noticeable) and YouTube videos look more pixelated, but for casual viewing, it’s now watchable and much better than before.

As for audio, the issue is with configuring my USB amp/dac. After re-installation, it showed up in dom0, but after restarting, it’s no longer in dom0 and shows up in my USB devices, where I tried to mount it on a Qube I created, but it doesn’t work. But when I mount it on a stock whonix Qube, it works (though I can’t adjust the volume). No idea what to do, but I can use my speakers and connect my KSC75 to my headphone port to get audio. So audio is technically fine, I’ll just use my amp/dac on my Ubuntu desktop.

Personally, I feel that in many lines of business it will be difficult to adopt QubeOS.

You can assess by yourself reading their FAQ: Frequently asked questions (FAQ) | Qubes OS

### Can I watch YouTube videos in qubes?

Absolutely.

### Can I run applications, like games, which require hardware acceleration?

Those won’t fly. We do not provide GPU virtualization for Qubes. This is mostly a security decision, as implementing such a feature would most likely introduce a great deal of complexity into the GUI virtualization infrastructure. However, Qubes does allow for the use of accelerated graphics (e.g. OpenGL) in dom0’s Window Manager, so all the fancy desktop effects should still work. App qubes use a software-only (CPU-based) implementation of OpenGL, which may be good enough for basic games and applications.

For further discussion about the potential for GPU passthrough on Xen/Qubes, please see the following threads:

** GPU passing to HVM*
** Clarifications on GPU security*

### Is Qubes a multi-user system?

No. Qubes does not pretend to be a multi-user system. Qubes assumes that the user who controls Dom0 controls the whole system. It is very difficult to securely implement multi-user support. See here for details.

However, in Qubes 4.x we will be implementing management functionality. See Admin API and Core Stack for more details.

etc…