> 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 firstname.lastname@example.org. 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.