zlacker

>>RafelM+(OP)
I’m using this as a daily driver.

It’s usable and the security benefits are definitely important when working with multiple security domains (separate clients each with their own confidential data and third-party dependencies, where you don’t want one client’s malicious NPM dependency affecting the other).

However, there are cons. It’s only really usable in a stationary environment; it completely kills battery life and even basic tasks such as (non-HD) video display maxes out a single CPU core so it’s just not worth trying on a laptop. Hibernation doesn’t seem to be supported by default which becomes risky when combined with the extreme power usage.

>>Nextgr+Gm
I use it on my Librem-15 v3. I can confirm that it's a PITA as far as performance. One "nice" thing is that if a process makes your VM unresponsive, it's just about always contained to that VM. You can kill it and restart it and not interrupt anything else.

The other problem is memory. I have to decide to between Signal Desktop and development sometimes.

But it's my main machine for what I care. I love the peace of mind running random things if the need comes up. For more intensive stuff, media games etc, I have a previous machine running Ubuntu.

>>orbliv+Ms
> if a process makes your VM unresponsive, it's just about always contained to that VM.

I still wonder why kernels can't just handle this properly.

I've seen it in both Windows and Linux systems, something takes all the CPU or I/O or RAM, and the UI is so starved that you can't kill it.

Shouldn't that already be handled by things like virtual memory, and the kernel scheduler? Why do modern OSes, that have to protect against such complicated attacks like Spectre, struggle to do what the very first multi-tasking kernels promised before I was born?

>>Reacti+Qu
Windows has a single official UI and a low level handling of a key press to bring up an element that must ideally remain responsive.

Linux has many and a set of low level responses to keybondings that must remain responsive that don't have a UI nor ability to kill individual applications.

To be fair in current systems Linux UIs normally remain responsive until memory exhaustion which is handled very badly. You will probably reboot before the oom killer assassinates the offender. The fix is a user space daemon like earlyoom which activates at a configurable level and targeting rather than absolute exhaustion when even killing the offender is challenging and usage has been hard for tens of minutes.

You or your environment can also set your UI process to a higher priority as far as processing and io.

If your UI doesn't remain responsive it's because your distro isn't using existing tools to achieve this.

>>michae+Ka1
If you are at the physiacl keyboard you can run the oom killer via the sysrq key. I would say that the kernel oom killer is quite usable since the last few years but is triggered too late - especially for applications like Firefox that handle malloc failures gracefully.