Hacker News Reader

Comment by tonymet | Hacker News Reader

develop in a VM.

Is there a good solution for getting good graphics performance with VMs, aside from using QubesOS and its special shared-memory thing[1]?

Plain X11 is obviously out of the running, as that gives clients far too much access. Apparently[2] Xpra or xephyr can help here, but to what extent and how does it affect performance?

Wayland seems to use both sockets and shared memory somehow. Can that work with a VM or container? How? Is there another solution? (Pipewire?)

VNC works but doesn't perform well. SPICE might be slightly better?

[1] https://www.qubes-os.org/faq/#whats-so-special-about-qubes-g...

[2] https://firejail.wordpress.com/documentation-2/x11-guide/

x2go is fast, not sure how secure

I'm currently looking into NICE DCV[1] from AWS after learning about it in a podcast with Michelle Brenner from Netflix.[2]

My use case is on-prem, but it seems like this solution can run cloud agnostic.

[1] https://www.nice-dcv.com/

[2] https://www.infoq.com/podcasts/netflix-builds-workstations/

what's considered good graphics performance? I've never had an issue with plain old hardware accel/software rendering when just doing standard desktop tasks. It's generally fast enough.

If you're serious, then you want to search for GPU passthrough. This allows a VM to take control of an entire GPU. But you'll need a 2nd GPU for your main, bare metal OS.

Unless you use a different VM for everything, you've just moved the problem from 'secure your workstation' to 'secure your VM'.

As long as the container isn't leaky, the benefit there is that it makes recovery, back-ups, and isolation easier. For example, dev VM isn't where you would have your creds for bank, SSH keys, etc. So isolation of (more) sensitive, daily-use data is easier. Snapshots of VM are cleaner and fast to rollback, etc. The OP was looking for reasonable mitigations that don't make daily usage a complete drag. I think VMs or other containers fit some of that bill.

But then you still have to draw a line somewhere for what's trusted outside of it - browser & password manager for your bank example, and for SSH keys probably at least some project related tooling that you have to decide to trust or audit or whatever.

If you use both host & VM I think my point stands, the host may as well be another VM (or the VM another physical machine) it's not that it's virtual that's adding anything, it's the separation, which was my point.

> Unless you use a different VM for everything

Why yes, that's exactly the idea.

It's an idea, I didn't think it sounded like the commenter I replied to's idea.

Even one vm with your dev env will isolate your personal and production credentials from the dev environment.

if the thread was npm malware, having your dev instance inside the VM would reduce the fall out. Your personal & prod creds would be outside the VM.

It still goes a long way to reduce fallout with minimal effort & discipline.

You’re right it’s not perfect security, VM still needs securing – but it’s a good ROI

Reply on news.ycombinator.com