• @systemglitch
      link
      83 months ago

      I feel like it’s easy enough to kill on windoes as well. Windows is down to about once every two years where it completely hangs.

      • Possibly linux
        link
        fedilink
        English
        113 months ago

        I haven’t had a issue with Windows in at least 8 years. Admittedly I primarily use Linux but still. It isn’t the unstable mess people here thing it is. It isn’t private in the least but that’s a different story.

    • @bitjunkie
      link
      23 months ago

      Too much typing. alias kill="kill -9"

  • @[email protected]
    link
    fedilink
    473 months ago

    Tbf, thanks to X11 Linux isn’t safe from stuff like that.

    When I use my VR glasses, Steam sometimes creates an uncloseable X window that isn’t attached to any process. I don’t think even killing XWayland gets rid of it.

  • Arthur Besse
    link
    fedilink
    English
    313 months ago

    I’m not sure what this comic is trying to say but in my recent experience a single misbehaving website can still consume all available swap at which point Linux will sometimes completely lock up for many minutes before the out-of-memory killer decides what to kill - and then sometimes it still kills the desktop environment instead of the browser.

    (I do know how to use oom_adj; I’m talking about the default configuration on popular desktop distros.)

    • @[email protected]
      link
      fedilink
      63 months ago

      Yeah, OOM not being aggressive enough (i.e. not triggering at all) is an age old issue. There’s earlyoom or nohang for this, further ressources in the description.

    • @[email protected]
      link
      fedilink
      23 months ago

      Real, happened too many times to me. What’s that about configuring the OOM, can you give it priorities?

    • @kolorafa
      link
      0
      edit-2
      3 months ago

      Linux is slow at killing apps when you run out of memory because it was designed to also run on low spec hardware even if very slowly (making the ui totally unrensposnive) due to swapping.

      This comic is about the kill command, how Linux kernel is handling force stopping apps vs (old?) Windows when if App frozed it was hard to close it. Now with modern apps and hardware you very rarely see that as most apps are designed to have asynchronous logic that is correctly handled, but it’s still more or less relevant.

  • Nailbar
    link
    fedilink
    183 months ago

    I recently had some processes lock up on Linux, and after searching what the “D” symbol in ps aux was (Uninterruptable sleep), i found this little line:

    The only non-sophisticated way to get rid of them is to reboot the system

  • @TunaCowboy
    link
    93 months ago

    $ kill -l

     1) SIGHUP	 2) SIGINT	 3) SIGQUIT	 4) SIGILL	 5) SIGTRAP
     6) SIGABRT	 7) SIGBUS	 8) SIGFPE	 9) SIGKILL	10) SIGUSR1
    11) SIGSEGV	12) SIGUSR2	13) SIGPIPE	14) SIGALRM	15) SIGTERM
    16) SIGSTKFLT	17) SIGCHLD	18) SIGCONT	19) SIGSTOP	20) SIGTSTP
    21) SIGTTIN	22) SIGTTOU	23) SIGURG	24) SIGXCPU	25) SIGXFSZ
    26) SIGVTALRM	27) SIGPROF	28) SIGWINCH	29) SIGIO	30) SIGPWR
    31) SIGSYS	34) SIGRTMIN	35) SIGRTMIN+1	36) SIGRTMIN+2	37) SIGRTMIN+3
    38) SIGRTMIN+4	39) SIGRTMIN+5	40) SIGRTMIN+6	41) SIGRTMIN+7	42) SIGRTMIN+8
    43) SIGRTMIN+9	44) SIGRTMIN+10	45) SIGRTMIN+11	46) SIGRTMIN+12	47) SIGRTMIN+13
    48) SIGRTMIN+14	49) SIGRTMIN+15	50) SIGRTMAX-14	51) SIGRTMAX-13	52) SIGRTMAX-12
    53) SIGRTMAX-11	54) SIGRTMAX-10	55) SIGRTMAX-9	56) SIGRTMAX-8	57) SIGRTMAX-7
    58) SIGRTMAX-6	59) SIGRTMAX-5	60) SIGRTMAX-4	61) SIGRTMAX-3	62) SIGRTMAX-2
    63) SIGRTMAX-1	64) SIGRTMAX
    
  • @mvirts
    link
    73 months ago

    Imho desktop Linux is usually set up where a single bad app can lock up the whole system. This is not every Linux system, but I run across it more than I would like. I believe part of this is an optimistic approach to memory management which makes the system run better overall most of the time.

    Windows seems slow as hell most of the time, but killing a process seems to work reliably (not clicking on the hung app takeover UI, using task kill or task manager)

    I don’t understand these memes about killing processes in Linux vs Windows.

    • @RoidingOldMan
      link
      43 months ago

      The killing process on Windows used to work better. Since about Windows 8 it’s not been quite the same.

  • @[email protected]
    link
    fedilink
    73 months ago

    Quite often double click on the close button will kill a hung app on Windows. Not Al the time, maybe 70%.

    • @pool_spray_098
      link
      23 months ago

      For real? Can’t believe I’ve never heard of this.

    • kn0wmad1c
      link
      fedilink
      English
      113 months ago

      There’s an old addage when working with any Microsoft product:

      “Wait longer”

      In other words, your first click was probably doing its thing. You just needed to wait a little longer to see it work.

      • @rtxnM
        link
        English
        3
        edit-2
        3 months ago

        The wonders of running everything synchronously in the UI event loop…

  • @[email protected]
    link
    fedilink
    43 months ago

    sudo xkill on mint, any cool sounding replacement for Wayland? as it seems like xkill is x11 olny.

  • @tomjuggler
    link
    13 months ago

    Good one! I’m literally dealing with this right now on a server. Turns out you’re expected to deal with long running processes that spawn too many threads yourself, or else…