> On Wednesday, 28 September 2016 03:54:10 UTC+10, raah...@gmail.com  wrote:
>> Is your issue after a wake from suspend? Desktop freezes on me on one
>> machine if it is left asleep for too long.  I figure its related to bios
>> or what vms were running when it went to sleep.  I also find its less of
>> a problem on kde then on xfce.  In my case it also seems to happen more
>> often if i wake machine up from power button rather then a keyboard
>> press.
>
> Well, it just happened again.
> While I was using it.
>  I'll attach the log fine. But as far as I can tell, it's because Qubes
> uses ystemD. And when that runs out of RAM to use, it locks up. and since
> everything runs as SystemD, just like Windows, everything locks up,
> instead of 1 process.

A bit late to the party (as they say) in this discussion, but why is it so
important to suspend/restore in the first place?

I'm generally not one to rationalize a bug by saying "well, just don't do
that," or "don't use that feature"; but the whole suspend/restore thing
does seem to add a layer of complexity to the whole security mess, with a
lot of CPU/BIOS/motherboard dependencies and such.

It's never worked well for me, from the days of the first laptop that
promised to suspend/restore, up until my last Macbook.  :)  Maybe I've
just lost one too many sessions from a failed suspend/restore, that I've
been turned off of the feature.  Or maybe I just don't leave the house
enough.

I like to leverage all the hardware/software features I can, but
suspend/restore never seemed worth the trouble in most cases.

Suspend/restore doesn't quite reach the 26x increase in complexity I
perceived in the Wifi vs. Ethernet comparison, but it's probably at least
2x or 3x the complexity and dependency upon a variety of processor/mobo
features.

For a laptop on the go, okay, I can see the argument.  But I don't think
most Qubes users are on laptops, given the hardware requirements.  (Very
much moreso with 4.0. :P)  Correct me if I'm wrong.

Why do you need to suspend?

A good, strong, password for your user account, making sure you have
physical security (or at least awareness if it's been breached), and/or
shutting down when you need to, works fine for me.  (At last I hope, lol.)

It would be nice to see "xl save" and "xl restore" (which basically
hibernate a VM) smoothly integrated into Qubes, so the VM Manager
supported it, or at least was aware of it.  Which would reduce the need
for a true hardware suspend/restore (if you can restore a VM fully after a
full reboot).

But if you need to keep your current state, why not just keep the machine
on?  (And securely locked/monitored?)  I'm hardly flush with cash, but the
electricity cost of keeping a PC on 24/7 isn't exactly breaking the bank.

And the alternative of shutting it down (and taking the disks with me)
when I leave, isn't terribly inconvenient, w.r.t. the risks, either.

Apologies if I completely missed the point, as I so often do.  And maybe
I'm wrong and most Qubes users are running around with high powered,
compatible laptops.

I'm just looking to find out the motivations for such a feature that
brings additional complexity.

Cheers

JJ

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/674a707e5014ac6d0121137f1d9616bb.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Reply via email to