• алсааас [she/they]@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    76
    ·
    edit-2
    8日前

    This is blatantly false, 99% of Gnu/Linux distros actually have systemd nicely asking the processes to terminate themselves, it just doesn’t take longer than ~10 seconds usually.

    This meme would imply a sigkill.

    Edit: the distros that don’t use systemd likely don’t do any such thing either, I just don’t know about them.

  • FiveMacs@lemmy.ca
    link
    fedilink
    arrow-up
    64
    ·
    8日前

    *clicks shut down on windows

    *goes to boot computer up into the morning… sees message ‘attempting to close programs’

    fu microsoft

    • 0ops@piefed.zip
      link
      fedilink
      English
      arrow-up
      6
      ·
      8日前

      *clicks sleep on windows

      *computer turns itself on in the middle of the night and starts playing YouTube

      fuck you ms

      • AnyOldName3@lemmy.world
        link
        fedilink
        arrow-up
        4
        arrow-down
        2
        ·
        8日前

        That’s almost certainly because you’ve got wake on LAN enabled in your BIOS settings and something else on your network wants to have a late-night chat with your computer.

        • vrighter@discuss.tchncs.de
          link
          fedilink
          arrow-up
          5
          ·
          7日前

          yeah wake on lan is pretty hard to accidentally trigger.

          Why would random software be sending packets with 0xFFFFFFFFFFFF + mac*16?

          • AnyOldName3@lemmy.world
            link
            fedilink
            arrow-up
            3
            ·
            7日前

            The MAC-specific magic packet is an optional mode for wake on LAN, not a mandatory one. Plenty of network adapters forward packets to the OS if wake on LAN is enabled and let the OS decide whether it only wants to respond to magic packets, and by default when wake on LAN is enabled, there are other kinds of packet Windows responds to, e.g. Address Resolution Protocol, which lots of routers use to check whether devices are still connected. It’s not supposed to wake the machine, especially if S0 sleep is enabled, but it can, especially if it’s done excessively.

            • vrighter@discuss.tchncs.de
              link
              fedilink
              arrow-up
              3
              ·
              7日前

              A magic packet is any packet using any protocol with that string in it. And the os cannot respond to a wake-on-lan packet, because the os is not running at the time; the computer is powered off. The os is later informed, via acpi, of the reason it was woken up, should it bother to check. If you don’t want a magic packet, then any packet will wake the system up. I am not aware of any alternatives. Extensions, yes. But not alternatives

              • AnyOldName3@lemmy.world
                link
                fedilink
                arrow-up
                2
                ·
                7日前

                It’s not any packet that’s waking up machines configured to wake on LAN without restricting it to magic packets, it’s any packet addressed to the machine’s MAC. Just like a regular packet when the machine’s fully awake, it’s specific to the network adapter with that MAC, and gets handled by that network adapter. Once it wakes the machine (either to fully on or a sleeping-but-still-doing-things state like S0), the OS starts/resumes and is told why it was started and can choose to access the packet and respond to it. From the perspective of the device on the other end of the wire, it sent a packet to a machine and got the response it expected. It doesn’t have to know whether the machine was fully powered on or whether it woke up to deal with the request before going back to sleep again.

                By default, for most network traffic that partially wakes Windows when the machine has wake on LAN enabled in the UEFI settings, Windows sees it’s been woken by LAN activity, checks the packet, decides it doesn’t care, and goes back to sleep before anyone notices (or remains in S0 sleep if it was in S0 sleep as it wouldn’t need to wake up to deal with the packet). For a few other kinds of LAN activity, it opts to respond to the packet. If you’ve got your UEFI settings set to only wake on magic packets, these won’t make it that far, though. There’s also a Windows setting to force it not to respond to regular non-magic packets and immediately go back to sleep if it’s woken by them.

                • vrighter@discuss.tchncs.de
                  link
                  fedilink
                  arrow-up
                  2
                  ·
                  edit-2
                  7日前

                  I thought the “addressed to it” part was implied. you seem to keep saying that windows handles things. The computer is shut down, not in sleep mode. There is no windows to handle things. Windows is not loaded. It has not gone through the boot process. WoL still works if you rip out all the storage. WoL is handled by the network adapter hardware

                  You’re describing what windows does after a computer is woken/turned on. That’s irrelevant, by that point the WoL is long over. After the pc is turned on and booted then windows is free to do whatever, including putting the system back to sleep. Whether it does this fast enough for you to notice is irrelevant, that is not WoL functionality.

                  And no, systems are not constantly waking up and then re-sleeping. Again, if the pc was shut down it’d have to go through the whole boot process before windows can put the system back to sleep. And you would find a sleeping pc when you left a shutdown one. Not what happens. And if instead of sleeping it shut itself down that’d look like a boot loop. definitely noticable.

                  tldr: after the pc is turned on and the os has been loaded, the os is free to do anything

          • AnyOldName3@lemmy.world
            link
            fedilink
            arrow-up
            2
            ·
            7日前

            When Windows wakes itself up to do things like that, it wakes itself to a different sleep level where it can still do things but the machine isn’t visibly on. That’s the whole point of S0 sleep. If it’s fully waking itself up to do things, then either S0 sleep is disabled or there’s a firmware bug affecting the motherboard that means certain actions during S0 sleep will exit sleep (which is more common than it should be).

  • There are apps that don’t close gracefully when asked by systemd in my experience. I’ve often forgotten to close one and been stuck waiting 90s for a watchdog to timeout so the app gets killed.

    This is not a problem unique to windows.

  • dubyakay@lemmy.ca
    link
    fedilink
    arrow-up
    5
    ·
    8日前

    I don’t see an article linked for the relevant headline, but when I first installed linux (I use Arch btw) on my desktop, it didn’t come with swap auto-configured by the install helper ArchInstaller, but did come with oomkiller and also with 4/16GB of zram preconfigured. With three displays and three different kind of browsers open I ran out of memory when launching a game fairly quickly, and of course oomkiller went to town. Not only that, but because of stupid zram it also seemed to be stuck on an endless loop of not being able to kill something.

  • Bluewing@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    7日前

    I can attest to that. I’ve been trying to figure out why my Kinonite install is killing KDE repeatedly without mercy…