zlacker

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+(OP)
> 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+42
Yeah, beats me.

>>Reacti+42
The task manager in Windows has a higher priority than everything else if I recall correctly. Its not pure ram or cpu usage that causes you to be unable to reach it but waiting for blocking sys calls I'd suspect.

>>Reacti+42
Isn't this what a microkernel is supposed to accomplish?

>>Reacti+42
this is what SysReq is for.

>The magic SysRq key is a key combination understood by the Linux kernel, which allows the user to perform various low-level commands regardless of the system's state. It is often used to recover from freezes, or to reboot a computer without corrupting the filesystem.[1] Its effect is similar to the computer's hardware reset button (or power switch) but with many more options and much more control.

https://wikipedia.org/wiki/Magic_SysRq_key?lang=en

>>seanw4+A7
Microkernel vs monolith has very little relation to resource (time and space) allocation, other than the fact that a microkernel is going to have an easier time with preventing runaway space usage of kernel services.

>>Reacti+42
It's levels of abstraction. The kernel does not know that swapping out X11/window-manager/gnome-terminal/whatever will make your system unusable.

There is mlockall() but it's a loaded footgun by default, and is rlimit-ed by default because it's not something you want users on a multiuser system to be able to do willy-nilly.

>>Reacti+42
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.

>>Showal+2a
Not really. The UI will still be unresponsive and the only thing you can do is reboot the system safely using Magic SysRq. What OP is asking about is why the UI is unresponsive in the first place.

>>michae+YH
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.

>>michae+YH
oomkiller wouldn't help if there's an I/O overload (good old friend Linux kernel bug #12309) since memory usage is fine, just your system can't read anything from network or storage.

>>codeth+501
When I ran memory-intense tests on low ram, I had the sysrq sequence for the oom-killer at my fingertips. When the system would start thrashing, it was a quick way back to safety.