10 Feb 2023, 10:53 by [email protected]:
> On Friday, 10 February 2023 07:46:36 CET Borden wrote: > >> which may be more productive. >> > > What would be even more productive is the following: > - log in remotely before doing another test and open a screen/tmux session > (or > open several distinct remote logins) and start: > - htop > - tail -f ~/.xsession-errors > - journalctl --user -b -f > - any other program which may be useful IYO > > Then start okular from Konsole, but give it a lower priority with `nice` (and > `ionice`). Possibly useful to `tee` the Konsole output to a file too. > If it behaves so bad again, you should be able to kill okular (f.e.). > > And then file a bug report with a sample PDF as Alex suggested and provide > any > info you obtained which may help to solve this issue. > > You didn't specify which Debian and Okular version you had this issue with. > In case of Testing or Sid, the "/topic" from #debian-next comes to mind: > "testing → bookworm | you may need to debug sometimes | ..." > Sorry for the delayed response, and thank you for the suggestions. Unfortunately, I couldn't file a bug report because the PDF in question had very sensitive information, so I ended up just working around the problem in Windows. I think the point of my complaint got lost. It's not so much that Okular had a major, semi-reproducable bug. It's that, in 2023, userland software still cripples systems. I would hope that, by now, a kernel can determine whether an application is being too greedy and stop marshalling resources to it to the point of a total lock-up. It's analogous to how the Ford Pinto could explode if it got rear-ended. Yes, I'm sure someone nursing second-degree burns after a collision would benefit from better adjusted mirrors and regular circle checks while driving. However, the real issue is that no car should catch fire in a fender-bender. And that's what I want to know: how do I stop Linux and KDE from exploding during an otherwise minor mishap?
