Hacker Newsnew | past | comments | ask | show | jobs | submit | sterlind's commentslogin

What's it like using Qubes? How much friction? I wish I could use some Nix-flavored variant of the sandboxing.

I dumped it after realizing Xen does its damndest in preventing you from hiding VM attributes from Guest OSes.

Proxmox uses KVM, and is easy to configure a VM to make the guest think it's on bare metal.

In the proprietary software space, a LOT of things run badly or refuse to run, or license stupidity with a guest OS. So for me, spoofing bare metal is an essential part of running ilk like Windows and proprietary apps. And also, school remote testing garbage.


Doesn't that preclude paravirtualization drivers? Seems like a major tradeoff for daily driver desktop stuff.

Xen prevents modifying ACPI data.

It also passes obvious "Xen emulated drive", and similar for all hardware interfaces.

Passes CPUID.

Can't stop any of this with Qubes/Xen. But is trivial with Proxmox/KVM.

Honestly, I wish there was a Qubes/KVM variant. It would fix every complaint, and enable running potentially malicious software (MS windows) and lie to it regarding hardware interfaces.


> Honestly, I wish there was a Qubes/KVM variant.

Relayed Issue: https://github.com/QubesOS/qubes-issues/issues/7051



Depends on how you use your computer. If you're mostly a developer/analysis terminal jockey with some browsing-- Qubes is a tremendous upgrade even if you don't care at all about the security properties:

The normal qube model of template OS vms + ephemeral app overlays makes it a cinch to troubleshoot complex issues because you can scribble all over the VM (e.g. go ahead, monkey patch your system LIBC if you want!) and all those changes will be gone when you restart the VM. Once you do find a solution you like, you can apply it cleanly and intentionally to the template. If all you were doing was a one-off, then no need to go make it permanent. Not sure if the latest Fedora upgrade is going to break stuff you care about? Install and switch to it one appvm at a time. Something breaks, file a bug and switch that one back until its fixed.

I've had friends screwing around with AI agents get their systems really screwed up because running the agent in a VM was work and requires maintenance. .. in qubes its just the natural way to run it, a few clicks and you're good to go. And the maintenance overhead of running in a VM is mostly non-existent.

If you ever use VPNs for privacy or to access protected networks-- Qubes is a big upgrade: You can run multiple VPN network VMs and then pick on an AppQube by AppQube basis which network they use. Then you don't have to worry about malware from your reddit browsing VM (or your Erotic MLP fanfic) going out over your employer's network or your banking going out via some Norwegian anonmization proxy that might spy on your traffic or cause your bank to instantly block your account. You can accomplish this without qubes but in qubes its particularly easy (and easy to get right): Every VM that has network access has it provided by another VM. Configure the networking how you like in that service VM and then pick what uses it.

When I say 'developer' above I don't mean to suggest that Qubes is particularly hard to use-- as I know significantly less technical people who use it without issue. But its non-security/privacy advantages are most significant if you're doing experimentation with the computer's configuration.

However if you're doing stuff that is Video heavy-- particularly gaming, and to a lesser extent CAD, video editing, etc. Qubes really brutally hurts video performance. It can be somewhat offset by running on higher end hardware (and then getting performance of a few year older system). Even just watching youtube videos is obvious impacted.

Similarly, it dents battery life. This is addressable via additional batteries given that now laptops are usbc powered and 100wh external batteries are readily available. But this is something of a lifestyle question.

Even before the AI-apocalypse I considered qubes to be non-negotiable on laptops-- there are just far far far too many browser RCE vulnerabilities to consider anything less for any computer that isn't a total security write-off.

Previously if I followed a link to a sus site and had my browser crash (maybe even the day before a RCE-in-the-wild was announced). I'd have some rationally justified paranoia that my whole computer might be compromised. Now, I can close the app VM (or-- better-- toss the disposable, which I try to use for most browsing) and know that even if they exploited the browser they'd have to have a VM escape of some kind too to do me any lasting damage.

The highest security stuff still ought to be on isolated hardware, of course. But using a multipurpose computer without qubes is unsafe at any speed, worse than driving without a seatbelt.


You make a very compelling argument. I've been thinking of at least trying it out before, but have been leaning towards it more and more over the years. A couple of questions though, if I could bother you with them?

How is remoting performance e.g. via VNC/RDP or particularly via Moonlight+Sunshine (intended for gaming and such)?

And how programmable is the configuration of Qubes? I like the idea of NixOS for example, but given how comparatively little activity there is in the actual nix rather than the packages, and across so few developers, I worry what would happen if someone got hit by a bus or something. But I still like programmatically configuring computers over manual monkey patches, because I have the memory of a gold fish. :p


> How is remoting performance e.g. via VNC/RDP or particularly via Moonlight+Sunshine (intended for gaming and such)?

I've used RDP w/ remmina and found the performance somewhat poor but usable-- I think it does too much video writes, so it's more like playing a video I expect Moonlight+Sunshine would be equal or worse. Xpra seems to work better than RDP for me. I didn't try to optimize the RDP since I tried xpra and it was better. (I use it to control remote GUI amateur radio software like WSJTX)

There are workarounds I didn't mention for video performance, e.g. handing direct hardware access to a GPU to a specific VM. But this obviously has security consequences and I don't have much experience with it.

Qubes itself is very thin. The most popular template vms (that you actually run apps in) are Fedora and Debian. The qubes system vms run on Fedora. So I think on the VM OSes themselves there is no maintenance concern-- so for example, you're not dependent on the qubes project for packaging software generally. (Though you do use qubes produced templates of the OS installs-- as they have some configuration to handle the overlay filesystems, clipboard, file transfer, networking, etc).

There is also work that people are doing to make NixOS a first class app vm image and even people working on being able to use it for dom0.

The qubes maintained stuff is dom0 and the glue that handles stuff like copying between VMs, wiring up networking to VMs, etc. Most of it is python. I've found relatively little need to mess with that stuff. Its configured via text files that are processed via (mostly) python scripts. Beyond the active developers there is a user community that has a lot of experience doing fancy stuff with the infrastructure, like adding support for ephemeral VMs that exist only in ram (for anti-forensics). I think that speaks positively to the maintainability of the system.

Ultimately because qubes is a system of VMs based on commodity OS migrating OUT shouldn't be fundamentally hard.

FWIW, I migrated in to qubes (from Fedora) by making an app VM for my existing laptop, copying the home into it. Then initially running everything in that one VM. It's not a good way to use Qubes, but it had me full on it in a couple hours with no loss of capability. From there it was easy to start moving things into other VMs until I no longer used the original.


> But using a multipurpose computer without qubes is unsafe at any speed, worse than driving without a seatbelt.

Could you elaborate on the odds of death and permanent disability occurring through use of unsecured general purpose computers? Because if not using qubes has the same risk profile as not wearing seatbelts I might feel like taking some measures


hah. There are computing death and dismemberment risks-- but I wouldn't expect qubes to solve one. (I'm thinking of my friends CNC router with the windows controller where windows decided mandatory upgrade time is NOW during an operation and it left an axis unsafely in motion necessitating a dive for the e-stop).

The serious point in my quip is that I've been a driver for over 30 years and yet to have a seatbelt protect me. I've been hit with computer attacks that qubes has limited. Might be kinda tricky to kill me from compromising my computer, at least today. Who knows about the computer.


What's so difficult about implementing RCS from a technical perspective?


Thanks! I noticed on one of my phones that RCS breaks once the Messages app is out of date by a certain amount of revisions. I hope this is an arbitrary decision by Google to invalidate older versions, given that the RCS protocol hasn't changed. I wouldn't want the Graphene team to have to keep up with each change Google makes with their Messages app, and instead is a security oversight Google has found in their own app.

We definitely will have to keep up with the changes. We already do in order to provide support for using RCS via Google Messages on GrapheneOS. Recently, they made a change which broke it on GrapheneOS and we had to quickly fix that in under a day.

The US/China divide is one thing, but if I'm asked whether I trust OpenAI or Deepseek, as companies, more, I'm not sure how I'd answer. I suppose my default is to distrust whoever is in the lead, since the lead is power, and power corrupts.

Yeah Sam Altman doesn't inspire trust. Dario and Musk are a bit better in this regard. I think they both say what they really think. Altman... no way.

The code generated by AI is often not maintainable by AI. It's mostly trained on one-shot tasks still, not on growing a small system into a large one. AI is not immune to tech debt.

Do first responders read these guides on the scene? Or do fire departments study them when a new one is released? Seems like a lot to study ahead of time, seems like a lot to read when lives are on the line.

A motor vehicle extrication is a very technical exercise — firefighters don’t just jump out of the truck and start hacking into a car.

They followed a structured arrival and size-up process that (among many other things) involves identifying and neutralising hazards, such as airbags. To do that, they’ll flick through the rescue guide to find out the locations of things like batteries, and other specific details relevant to the task at hand.


Tesla and other manufactures also sponsor training events with first responders...

https://abc7.com/post/tesla-hosts-event-aimed-training-socal...


I'm surprised they can post-train a closed model off of K3. Is that the norm for open-weight licenses?

Yes. If they are really open, you can use them as you wish. Some licenses are less open though.

I would be somewhat surprised if any license restriction actually holds up in court.

There's plenty of legal gray-hat companies that will buy a bug. Zerodium is a good example though it no longer exists. These companies in turn sell to NSA, etc. maybe even foreign governments for all I know. There's very little regulation of the space iirc.

I had a friend that worked in the space. He lived an exciting life; I hope he's still alive..


It's like a form of magical realism. AI feels like straight up magic, like discovering a genie that grants wishes, but we all have bills to pay and projects to do so weeks later there's a magic lantern on every desk and the genie's doing grandma's taxes and wishing he'd stayed in the bottle.


DMCA seems like an ideal place to have the winner pay all parties' attorney's fees, plus damages. It's usually pretty objective and easy to see whether something infringes.


This is the reason anti-SLAPP statutes exist in many jurisdictions.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: