On Tue, Jan 7, 2020 at 12:08 AM Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote: > > > > On Mon, 6 Jan 2020, 18:32 Kamil Paral, <kparal@xxxxxxxxxx> wrote: >> >> On Sun, Jan 5, 2020 at 12:43 PM Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote: >>> >>> I wonder, how I as a user going to be informed about the >>> earlyoom-event? I assume abrt will recognize the crash? Will it be >>> easily visible from the abrt report that it was the OOM? >>> >>> The concern is: if we enable such a service, will we get large amount >>> of vague bug reports from users who don't understand what has >>> happened. Can we make it somehow easier to debug? >> >> >> FWIW, the behavior on Android is very close to what is proposed here. If your application exceeds the amount of available memory, it simply closes right in front of your eyes. No explanation, nothing, it's just gone (might be different on latest Android versions). The same thing would happen with EarlyOOM - some application would disappear. >> >> I agree it would be nice to inform the user before or at least after. Windows can do it - they show a notification roughly saying "Your system is running out of memory and some application might get closed". (At least they used to in the old days, I haven't run out of memory for a long time, and I don't know whether Windows 10 behaves the same way). But I think it should not be a stopper for the proposal as it is. Even without the notification the user experience is improved over the default behavior. > > > I am not convinced that it is an improvement to be honest. > > UX before: system works, I run heavy application, system starts to hang, i understand that there is an issue, i can kill the app or reboot, which gives me clean and working system. > > UX after: system works, no visible problems. Suddenly random app disappears, no errors or crashes reported to me. It might be that my active app is killed, then I know that smth happened, but what if background process is killed? Maybe my messenger app? This comparison is not accurate. 1. In the UX before case, it's unfair you're comparing to user intervention to kill the app rather than oom-killer. 2. oom-killer reports to the journal. earlyoom reports to the journal. They're the same. 3. Quite a lot of errors and crashes are only ever reported to the journal. 4. UX after (i.e. with earlyoom running), the system starts to hang, you should understand there's an issue, recovery shouldn't take quite as long but you'll still wish the system hadn't become hung up in the first place 5. The app is quit with SIGTERM, not killed 6. kernel oom-killer can kill background processes too > I am going to keep working in my main app without noticing that I lost something, not knowing that I need to take action. And my system now runs in a weird state, and can stay there for days, which will lead to more weird and nonreproducible errors later. No different than with oom-killer, assuming you're willing to wait for it take action. If you force power off instead, there's some chance you're still going to do that with earlyoom because the responsivity problem has more to do with congestion as a result of heavy swapping. > The "hang" of a system was the feedback user got from the system that there is something wrong. Not ideal, but at least there was something. With this feature we don't solve the issue, we remove the "bad" feedback, and we don't provide any replacement for it making memory problem completely invisible. > > Is it really a good UX? Insofar as aggravation is definitely not good UX, I'd say for sure it's better to reduce user aggravation. They will still experience the hang. It just won't last quite as long, and yet it still will be too long. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
