Linux needs real-time CPU priority and a universal, always-available escape sequence for DEs and their user interfaces.


For the everyday desktop user, to be clear.

Let's top out the CPU in Windows and macOS. What happens? In Windows, the UI is usually still completely usable, while macOS doesn't even blink. Other applications may or may not freeze up depending on the degree of IO consumption. In macOS, stopping a maxed-out or frozen process is a Force Quit away up in the top bar. In Windows, Ctrl+Alt+Del guarantees a system menu with a Task Manager option, such that you can kill any unyielding processes; it even has Shut Down and Restart options.

Not so in Linux. Frozen and/or high-utilization processes render the UI essentially unusable (in KDE and from what I remember in GNOME). And no, I don't believe switching tty's and issuing commands to kill a job is a good solution or even necessary. You shouldn't need to reset your video output and log in a second time just to kill a process, let alone remember the commands for these actions. You also shouldn't need to step away from your system entirely and await completion due to it being virtually unusable. The Year of the Linux Desktop means that Grandma should be able to kill a misbehaving application, with minimal or no help over the phone.

It could probably happen at the kernel level. Implement some flags for DE's to respect and hook into IF the distro or user decides they want to flip them: One for maximum real-time priority for the UI thread(s), such that core UI functionality remains active at good framerates; another for a universal, always-available escape sequence that could piggyback the high-prio UI thread or spin off a new thread with max priority, then, as each DE decides, display a set of options for rebooting the system or killing a job (such as launching KSysGuard with high prio). If the machine is a server, just disable these flags at runtime or compile time.

Just some thoughts after running into this issue multiple times over the past few years.

submitted by /u/netbioserror
[link] [comments]

Leave a Reply

Your email address will not be published. Required fields are marked *