Hacker News Reader

Comment by irundebian | Hacker News Reader

Have used it for several months as my daily OS and dropped it because of bad graphics performance (only software rendering supported, many frame drops when watching HD videos on YT) and bad battery management. Due to software rendering the overall systems perfmance also dropped. So I cannot recommend it for people with high requirements on graphics and battery duration. Besides that it was an interesting and good experience.

I think it would be good to make it possible to deactivate certain security features such as strict graphics isolation so that users can adjust their settings to their risk acceptance level. It would also be interesting to be able to optionally replace Xen with lighter isolation mechanisms, even if the user would compromise on security here too.

View on HN

> dropped it because of bad graphics performance (only software rendering supported, many frame drops when watching HD videos on YT)

Around Firefox 92 or 93 the new GPU-based renderer ported from Servo was made default and performance under Qubes became much worse. Unfortunately, it seems applications increasingly assume the presence of video acceleration and don't prioritize software rendering.

Isn't it reasonable for applications to assume that, now that virtually all hardware has it, even super-cheap computers like the Raspberry Pi?

The hardware may be there, but not necessarily the drivers.

The drivers are fine for GPU accelerated rendering of the app surfaces, even on the Pi. Hell, the drivers are even there >98% of the time for accelerated decode of the video format itself to boot.

Qube's unique choice in software only rendering for user applications is one born out of the isolation goals for security, not what the software/drivers/hardware could do.

> even on the Pi

Only proprietary ones, so not for everyone...

Pi 1-3 https://docs.mesa3d.org/drivers/vc4.html

Pi 4-5 https://docs.mesa3d.org/drivers/v3d.html

> Broadcom never released a public specification for the V3D 3.x or 4.x series.

So the support must be worse if you prefer free drivers?

No, as there isn't a non-free driver alternative to compare V3D to. For VC4 (Pi 1-3) there was a proprietary alternative driver... but it was a bit garbage.

It feels you may be conflating the "proprietary firmware blob on the GPU which is used to boot the Pi" story with the GPU driver itself.

Yes, you are right, "proprietary firmware blob on the GPU which is used to boot the Pi" is what I recall as a big Pi problem. So my original wording is correct that you need proprietary blobs to run Raspberry Pi, isn't it?

"Yes" in that the above statement about needing proprietary blobs to boot the Pis is certainly accurate & true (ongoing science experiments notwithstanding). "No" in that we somehow went from talking about "how apps can safely assume to rely on accelerated rasterization instead of software rasterization" to "how the Raspberry Pi family needs proprietary boot firmware to do anything with app output at all" and I've missed the connection between the two points.

> support must be worse if you prefer free drivers

Yes. Besides Qubes users, a big population of software rendering users is people who have old and/or buggy drivers that are blacklisted by Firefox.

I understand GPUs are a security nightmare. If you want to have some understanding of your security, don't use a GPU.

Yeah, if you really care about security, only use computer which use line printers as output mechanisms.

The issue for Qubes is security. GPUs can be used to subvert basically all the otherwise hardware-enforced security protections.

In a desktop, couldn't you assign a GPU to one video machine and in that scenario would there still be a security problem when there is only one VM using it?

It’s not about virtual machines. GPUs typically have direct memory access to pretty much all system RAM. There exist PCIe mitigations, but the review does not meet up to Qubes security standards.

Yes, this is what qubes would probably suggest as the solution.

It's totally reasonable, just unfortunate for this use-case.

Given the tendency for people to lower their unknowingly compromise their security for the sake of convenience, I can understand why a project wouldn't do that. Knowingly is different and is what you're requesting -- it's when someone is following some Stack Overflow post or some such and doesn't have the training (similarly with the SO commenter, potentially) to know the implications.

It kind of feels like a tradeoff between protecting users who are critically in need of something like Qubes or expanding its reach to people who are less at risk and won't use it if it's too inconvenient.

QubesOS is best enjoyed with a hefty CPU, lots of SSD space and a multi-screen set-up (in my opinion). Have you tried using Freetube instead of Youtube? In my experience it works a little better.

The most annoying issue I had was that even using mpv would lead to audio samples being dropped. I think I fixed it eventually by increasing buffer sizes, but I would expect at least audio should work out of the box.

>at least audio

I imagine audio and other realtime loads having problems the most on a heavily virtualized system like this.

Not sure what "mpv" means in this context, but this reminds me the one actual pet peeve I have with Qubes - video/audio calls just don't work for me. It either doesn't work or the audio quality is really poor. I've tried all kinds of stuff, without much success. I'm using phone/tablet as a fallback, but it's not very convenient.

mpv is a free (as in freedom) media player for the command line. It supports a wide variety of media file formats, audio and video codecs, and subtitle types.[0]

https://mpv.io/

Thanks for the clarification.

You could try something like this: https://forum.qubes-os.org/t/improve-video-playback-performa...

I could tolerate no graphic acceleration and battery issues as part of the virtualization overhead, but I had issues with sleep (it would sleep and wake up perfectly only with when plugged in) and other related problems such as Windows VMs crashing when waking up from sleep.

I was using it well at home but could not stand it when I travelled around with my laptop.

I think Xen is mostly at fault for the issues, but I’m sure using something like KVM would be insecure, or they would have migrated already.

Does sleep and wake work for you with a standard Linux distro? If so a newer kernel might help,like the kernel-latest-qubes-vm package, might help:

https://www.qubes-os.org/doc/managing-vm-kernels/#installing...

Yes, it works perfectly. It’s a Thinkpad X260, not exactly new hardware, and even Debian works just fine.

Weird. Multiple people submitted HCL for X260, and not a single one mentions issues with sleep.

https://www.qubes-os.org/hcl/

When I had similar issues in the past, I posted a question either to the mailing list or forum, and people were helpful.

> but I had issues with sleep

If you choose Community-recommended hardware (https://forum.qubes-os.org/t/community-recommended-computers...), sleep will work fine for you.

> dropped it because of bad graphics performance (only software rendering supported

This is by design, to provide high security, which is the point of Qubes. It's planned to allow GPU for chosen, trusted VMs: https://github.com/QubesOS/qubes-issues/issues/8552

Alternatively, you could perform a GPU passthrough, https://www.qubes-os.org/faq/#can-i-run-applications-like-ga...

Your link concerning GPU pass through only links to a google groups discussion with last activity in 2020 and 2015. So.. I guess this is not possible nor recommended?

I've been using vms with passed through gpu for a while and it's great but I would love to switch to qubes. I wish this was prioritized.

It's possible and supported. Here are better links: https://forum.qubes-os.org/t/nvidia-gpu-passthrough-into-lin..., https://forum.qubes-os.org/t/create-a-gaming-hvm/19000

Thank you! That looks more promising.

>bad graphics performance (only software rendering supported, many frame drops when watching HD videos on YT)

It might help if you used a computer with CPU horsepower that actually exists.

And in case this sounded facetious, any reasonable CPU from the past 15 years can handle software decoding of high resolution video just fine.

This all said however, if you do actually need full use of all hardware resources then being constrained to software is certainly a factor worth considering.

You have to do more than just decode the the video stream to display it as smoothly playing video without dropping frames or audio samples or loosing sync. It requires always scheduling the context switches correctly between different virtual machines when using Qubes OS, performing multiple copies across protection domains.

Brute force helps a lot, but do you want a ≥5GHz multi-core CPU burning 150W just to watch a single video stream with maximum paranoia settings?

>do you want a ≥5GHz multi-core CPU burning 150W just to watch a single video stream with maximum paranoia settings?

I mean, yes?

We're not talking about bloat here, you're deliberately imposing significant overhead load for a specific purpose.

You can't really subsequently complain about performance unless you bring sufficiently powerful hardware to compensate for that overhead.

Right, but in a discussion about Qubes, it's germane to explain why you stopped using it

> any reasonable CPU from the past 15 years can handle software decoding of high resolution video just fine.

4k VP9 from youtube takes my 5950x around 20-25% CPU usage to handle with hardware acceleration disabled.

The fastest consumer CPU available 15 years ago could not handle that. Hell, even CPUs from 10 years ago couldn't do that. Add power & thermal limitations of a laptop CPU? Not a chance.

And that's just VP9! HEVC or AV1 would really put the hurt on.

>4k

To be pedantic, OP specified "HD" which is 720p. I gave him benefit of the doubt by saying "high resolution" in my reply, but I think 4K is unreasonable given the provided context. I'd wager 1080p ("Full HD") at most. There's also the question of frame rate, though we can probably safely assume either 29.976 or 59.952 fps since it's Youtube.

As an aside, software decoding performance can vary pretty significantly depending on the codec used for both encoding and decoding. Bit of a history lesson, CoreAVC was infamous for being very easy on the CPU compared to other h.264 decoders like ffmpeg.

Correction: I think I experienced noticeable stutters with Full HD videos not with HD videos.

I occasionally see stutters too, even with Full HD video. Or more precisely, mplayer complained about slowness and having to drop frames.

It often helped to actually give the VM more cores (not just the default 2), but sometimes it was due to some weirdo codec/quality setting, and recoding the video just solved it. Sometimes switching to vlc (from mplayer) helped. Other times it was simply due to the sys-usb vm being overloaded.

https://forum.qubes-os.org/t/hd-video-playback-on-qubes-os-o...

I'm using an Intel i7-8850H with 6 cores so I think it's powerful enough. It's not that I couldn't watch HD videos but I was experiencing stutters and it left me with the feeling that the CPU is insufficiently utilised.

I certainly rescind my insufficient CPU horsepower accusation in that case. I'm not entirely familiar with Qubes's innards, but the overhead it imposes must be substantial.

> only software rendering supported

Isn't this something GPU Virtualization is intended to solve?

I think you do have GPU acceleration in the Dom0 but I do not remember if you can use/install programs on it, it was the "coordinator" dom.

Yeah, I could not do it without other computers to use, but after a year of keeping a system running it, I find myself mostly using my other systems for specific purposes like a windows machine for gaming (no web browsing ever lol), my macbook air for printing, managing photos, doing stuff with my iOS devices, etc.

Reply on news.ycombinator.com